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.
[#]
Tue Dec 10 2024 18:45:10 UTC
from
IGnatius T Foobar
Subject: Notes from the 'console_rework' git branch of the text client
This was a really long git commit message, and it contains some good notes
for those of you interested in the text client. So I'm re-posting it here in
case anyone wants to read them.
--- snip ---
There is a lot of very old code in here, some of it as much as 37 years old.
To understand why it is as messy as it is in places, one must understand that
the text client is actually the remnant of the old monolithic Citadel BBS
program after the back end code was moved to a dedicated server. Most of it
was left in its existing form for decades because it was working fine and it
contained no interesting problems to solve.
Currently, there are people who are finding the text client to be an attractive
place to tinker. This seems to be a combination of interest in retro style
interaction and an increase in the deployment of Citadel on high latency links
such as darknets and digital radio modes.
Because of this interest, my current
whim is to clean up the text client and make it an easier platform to hack.
The current commit mostly focuses on making the textclient.h header file more
sensible to navigate. It began as a concatenation of multiple header files but
makes more sense this way. Those following the commit log will have noticed that
there was much duplication of effort in externs and function prototypes appearing
redundantly all over the system. This has been cleaned up quite a bit.
My coding style in 1987 was quite atrocious and overused the 'goto' statement,
which is considered poor form in C language. Although this practice has been
corrected throughout most of the system, there are still a few sections remaining
in which the use of 'goto' is heavily entrenched. These have either been recently
corrected or are in the process of being replaced.
Another regrettable anti-pattern in the client is the overuse of temporary files.
These seemed to make sense at the time, particularly for anything that held a
message being composed or quoted. This may have been excusable on a small system
in 1987 but it no longer makes sense in the modern era when there is both ample
system memory and a universe of documentation on how to perform these functions
using in-memory buffers. In particular, we are refactoring the code in
preparation for a complete rewrite of the message composition editor (which,
coincidentally, now has the largest remaining density of 'goto' statements).
Finally, there is the classic Citadel behavior of formatting all messages to the
reader's screen width. This behavior was mostly implemented in the message
output routines and in the message editor. Inspired
by a recent read through
of Jeff Prothero's 1981 Citadel CP/M code, I have extended the scr_printf() and
its companion functions written by Michael Hampton in the early 2000's to
handle soft word wrapping at that layer. He originally wrote scr_printf() and
the rest of screen.c to implement an ncurses-based output mode, which we later
abandoned in favor of just-plain-ANSI because there are no longer any non-ANSI
terminals in use. Owing to the fact that ALL client output now goes through this
layer, we are able to handle soft word wrap in a single location, eliminating the
need for other functions to handle it and making all code more simple and
understandable.
This is all taking place in the 'console_rework' git branch, which will be merged
back to git master once it has achieved feature parity. For those of you who
want to tinker with it: happy hacking.
for those of you interested in the text client. So I'm re-posting it here in
case anyone wants to read them.
--- snip ---
There is a lot of very old code in here, some of it as much as 37 years old.
To understand why it is as messy as it is in places, one must understand that
the text client is actually the remnant of the old monolithic Citadel BBS
program after the back end code was moved to a dedicated server. Most of it
was left in its existing form for decades because it was working fine and it
contained no interesting problems to solve.
Currently, there are people who are finding the text client to be an attractive
place to tinker. This seems to be a combination of interest in retro style
interaction and an increase in the deployment of Citadel on high latency links
such as darknets and digital radio modes.
Because of this interest, my current
whim is to clean up the text client and make it an easier platform to hack.
The current commit mostly focuses on making the textclient.h header file more
sensible to navigate. It began as a concatenation of multiple header files but
makes more sense this way. Those following the commit log will have noticed that
there was much duplication of effort in externs and function prototypes appearing
redundantly all over the system. This has been cleaned up quite a bit.
My coding style in 1987 was quite atrocious and overused the 'goto' statement,
which is considered poor form in C language. Although this practice has been
corrected throughout most of the system, there are still a few sections remaining
in which the use of 'goto' is heavily entrenched. These have either been recently
corrected or are in the process of being replaced.
Another regrettable anti-pattern in the client is the overuse of temporary files.
These seemed to make sense at the time, particularly for anything that held a
message being composed or quoted. This may have been excusable on a small system
in 1987 but it no longer makes sense in the modern era when there is both ample
system memory and a universe of documentation on how to perform these functions
using in-memory buffers. In particular, we are refactoring the code in
preparation for a complete rewrite of the message composition editor (which,
coincidentally, now has the largest remaining density of 'goto' statements).
Finally, there is the classic Citadel behavior of formatting all messages to the
reader's screen width. This behavior was mostly implemented in the message
output routines and in the message editor. Inspired
by a recent read through
of Jeff Prothero's 1981 Citadel CP/M code, I have extended the scr_printf() and
its companion functions written by Michael Hampton in the early 2000's to
handle soft word wrapping at that layer. He originally wrote scr_printf() and
the rest of screen.c to implement an ncurses-based output mode, which we later
abandoned in favor of just-plain-ANSI because there are no longer any non-ANSI
terminals in use. Owing to the fact that ALL client output now goes through this
layer, we are able to handle soft word wrap in a single location, eliminating the
need for other functions to handle it and making all code more simple and
understandable.
This is all taking place in the 'console_rework' git branch, which will be merged
back to git master once it has achieved feature parity. For those of you who
want to tinker with it: happy hacking.
This also seems to have fixed the problem of having dead telnetd
processes hanging around on my system.
Actually it turned out that it didn't, but I've FINALLY figured out that problem and fixed it. I had been assuming that it had something to do with the new terminal enquiry/response routine that detects the terminal's capabilities, but it actually had more to do with how I am launching telnetd.
In the past we've all run inetd and later xinetd, but on a modern system there's little incentive to run a superserver when the only thing it's ever going to launch is the occasional telnetd. So I've been running it directly, from a socket listener. This has been bugging me for months, I just couldn't figure out how to make those stray telnetd processes and citadel clients time out and go away.
Today I figured it out: telnetd was being run in a way that made it ignore SIGPIPE and therefore each session would remain active if it was disconnected without the user exiting the client. Just like the good old days when a BBS operator might have the modem configured wrong and it fails to log out the user if the call is disconnected :)
Anyway, I found the "IgnoreSIGPIPE=no" option and now it's working perfectly.
[ https://www.citadel.org/how_do_i_get_citadel.html ]
Hello, I have started using the text client through I2P. Very Cool!
Quick question: What the best source for citadel documentation? I run my own citadel instance and would like to be able to understand the admin functionality better. Is
Quick question: What the best source for citadel documentation? I run my own citadel instance and would like to be able to understand the admin functionality better. Is
The web site [http://www.citadel.org] is the best available documentation.
As you might have noticed we occasionally find things that are out of date.
Whenever this happens just holler and we'll make sure it gets taken care of.