Please wait...
Just fixed it tonight (in upstream).I am on the latest textclient from git now... and it just wErks - have not
patched anything :)
Thanks
and you end up with the text of the terminal's answerback on the usernamedunno, never happened to me. Maybe because i am with remember_passwods=1
prompt.
+ no color...
Soon. Especially since I just made another improvement. We now send the
terminal enquiry AFTER connecting to Citadel Server. I don't know why, but
it fixes the problem where telnetd skips the delay between the enquiry and
the answerback, so instead of the answerback appearing on the username prompt,
it actually works properly. And of course if your terminal supports color
you now get color.
And yes, you can contribute in a meaningful way: you can help spread the word and get others to join the party. Seriously, that's actually one of the best ways to help right now.
And yes, you can contribute in a meaningful way: you can help spread the word and get others to join the party. Seriously, that's actually one of the best ways to help right now.
Spread the word -- I'd love to see a lot more enthusiasts here.doing my best spreading the word :) too bad in my circles nobody wants to
touch terminal anymore :(
what i am facinated about is not the 'retro BBS' look...
it is the robustness - I am working on top of __awful__ connection (i2p) now.
yes, it freezes for a long time... disconnects sometimes (but I got it in the
loop in a script and it auto-reconnects), but it still works quite ok.
+ the C code is simple, possible to port on many systems...
i am still discovering more and more of it's features :)
Once it all falls apart and we are using LoRaWAN and packet radio to communicate, more people may appreciate it.
Spread the word -- I'd love to see a lot more enthusiasts here.doing my best spreading the word :) too bad in my circles nobody wants to
touch terminal anymore :(
Great to hear on that additional update! Terminal detection working smoothly will be so very nice!
Oof, and as soon as I posted that, now it's failing again. I suppose I could
make it "on/off/auto" again, but the setting I want for the public client
is "auto" so that wouldn't help me much.
And yes, the client is designed to be as simple as possible. Since all of the heavy lifting is done in the server, it makes sense that the client can be simple. I have to apologize for some of the rather old and sloppy code in certain parts of it though. Some of those main loops were written as far back as 37 years ago and my C kinda sucked at the time.
And yes, the client is designed to be as simple as possible. Since all of the heavy lifting is done in the server, it makes sense that the client can be simple. I have to apologize for some of the rather old and sloppy code in certain parts of it though. Some of those main loops were written as far back as 37 years ago and my C kinda sucked at the time.
Once it all falls apart and we are using LoRaWAN and packet radio to communicate, more people may appreciate it.hehe :)
Thumbs up! :)
I wanted to say the same thing, i was searching for words, but did not find the right wording :)
apologize for some of the rather old and sloppy code in certain parts of it though.don't :) You should see my code and will never apologize again :)
The fun thing about Citadel's client protocol is that it can be modified to run over just about anything.
There are people using it on packet radio networks for emergency services groups, things like that, it's pretty cool. But they haven't modified the protocol, they are just using telnet over AX.25 or something like that.
Right now, to use Citadel over a message-based network you still have to emulate TCP over it. I know we can do better than this, which is why all the client side commits made to the code in mid October centered around making sure we observe a strict decoupling between the user interface code and the client_ipc code. By doing so, we can add transports and swap them at will.
The transport I have in mind is SAMv3 in datagram mode. Or maybe it makes sense to start by developing for UDP (we own port 504/udp and are not currently using it) just to get the server working in a connectionless transport. Once that's done we would be able to make any message-based transport work pretty easily. So that would be UDP for the clearnet, SAMv3 for the I2P darknet, and any digital radio modes you can possibly hook up.
+ the C code is simple, possible to port on many systems...
i am still discovering more and more of it's features :)
You have inspired me to give the client some attention this weekend. `citadel.c` has finally had all of its 'goto' statements removed (as in, the C language goto, not 'goto next room' haha). The whole flow of getting a user logged in or creating a new user followed by entering the main command loop was one of the oldest bits of spaghetti code in the system, and it's finally been redone properly. No one will ever see it except for those who choose to hack on it, but it makes me happy.
I'd love to see a resurgence of interest in this. Most of my attention these days is going into the rewrite of the web user interface because that's what most mainstream users see. But the text client and the people who use it are the most fun.
So in looking at Citadel text client code updates I noticed some work done on what seems to be file downloads via the client. Am I correct in thinking this is something that may be being worked on, as that would be pretty neat.
Secondly, I'm aware that the text client apparently supported external programs (doors) at some point in time. Is there a chance of that returning in some capacity as an option?
I have a like a dozen more random questions but I'll leave it at that for now.
Just curious, not saying the above should take precedence but I'm at least showing some of where my interest as a Sysop lie.
Funny thing about file downloads ... back in the dialup days, the idea of rooms (forums boards etc) having file repositories was kind of a big deal, and you would use things like ZMODEM to upload and download. When the Internet came around it kind of got forgotten but it's been here the whole time. Now that Big Tech has put file libraries into collaboration tools again, people have started paying attention again.
Yes, you can upload and download files in "directory rooms" (an option you can set on any room as an admin) using the client. This is an option that needs to be enabled in your citadel.rc because obviously it doesn't make sense for a public access client. And of course you can upload and download using WebCit.
I don't see "doors" coming back any time soon because as much fun as those were, there's no easy way to expose that functionality to users who are running their own copy of the client, or who are logging in with a web browser, or who are connecting over a third party network, etc. etc. etc. Most site operators who want to do such things find that it's easier to stand up such programs alongside Citadel rather than inside it.
Ah, makes sense with how things work! Just thought there might be some kind of sorcery in the background to where I could make Syncterm pull a file via ZMODEM and it all just magically work.
As for doors, that too makes sense in the grand scheme -- indeed, my first idea was to just set them up via another method, and I may (should I even bother with doors as my BBS evolves) likely just go that route. ssh into games and you're off to the races.
Thanks. Gives me some more clarity on things.
Oof, and as soon as I posted that, now it's failing again. I suppose I
could make it "on/off/auto" again, but the setting I want for the
public client is "auto" so that wouldn't help me much.
I think I finally found the problem!
Sometimes, but not always -- dontcha love those race conditions -- telnetd is delivering a SIGWINCH to the client during the one second sleep in between when the terminal enquiry is sent and when the answerback is read in. I found it after changing the sleep() call to a nanosleep() call, and discovered that a signal was interrupting the system call. So I disabled SIGWINCH during the sleep, et voila, the problem went away completely. I connected in dozens of times and it worked correctly every time.
This also seems to have fixed the problem of having dead telnetd processes hanging around on my system.
During the investigative process I also learned that socat can substitute for inetd if you're only interested in running a single service. This means I can potentially provide a way to put a telnettable text client service in the docker container image. I'm not sure whether that's a great idea, since some people consider the mere presence of telnet at all to be a security hazard. We call these people "those who need to be stabbed in the face with a truck because they blindly follow rules instead of thinking for themselves" but nevertheless the decision exists.
Maybe a configurable option.