Glad to see you, All!

? The various message formats are archaic and ridiculous in a lot of ways. There should be a standard implementation that is accessible on all devices. My personal preference would be for SQLite due to it's ease of use and ubiquitous distribution (how many billions of android and iOS devices have it Pre-installed?)
? The display format! ANSI for crying out loud! Surely we can do better than that? Why about send SVG commands which are rendered on the device? Maybe using the Cairo graphics libraries or their equivalent? I know RIPTerm was an early. Semi-proprietary version of this. Maybe it's time to develop a new standard which is simple and easy to implement? It beggars belief that we are using software that is actually designed with VT100 terminals in mind.
? Having said this, nothing prevents us from separating the display layer from the transmission layer. If we design the protocol sufficiently well, then that could also be relatively agnostic, or at least provide fallback options. For example, negotiation with the client with "new RIP" preferred, falling back to in descending order, Rendered SVG, PNG, HTML, ANSI and ASCII.
? Telnet. Ask anyone under thirty who is not in IT to use telnet and you may as well have spoken in a foreign language.
? Composing messages. Make it something like Markdown so it's also agnostic and the formatting is deferred to the client.
? Images. There aren't any. This is probably the biggest reason for the poor uptake after the lack of clients for devices. I'd suggest though that rather than duplicate http for this, and find ourselves with a poor man's version of the web, we think very carefully about how to implement the display of images, possibly making them "out of band". Something like "progressive jpgs" which render independently of the message and maybe even a send them using UDP so that they aren't dependent on the message. Images and video etc are, of course, big attractions to users (just look at the growth of Instagram and TikTok) but they can kill everything else. They're also bandwidth hogs. I think this is where the "control by the user" needs to be rigorously built in, there is a simple and enforceable way to select where and how images are accepted.
? Spam. Spam kills message board and conferences if not killed instantly. That's why there must be some mechanism to deal with it. Maybe ...
? Reputation. While I believe that at least in some areas it's important to have anonymity, at the same time there are some things that need to be controlled/ prevented. These include things like adult content, spam etc. I think that it should be possible to generate some way of figuring this out. One possibility could be a sort of "reputation" setting. This could have many variations but for example, if you're reputation is low (or your *rank* is 'Noob'), there are only certain things you can do, or certain conferences you can join. The longer you are part of the system, the more you participate in certain activities etc, the more tour reputation/rank can change. If, for example, no messages are accepted from /noobs/, then the hit-and-run spammers who use images won't be able to generate new user IDs to post them. If there is an algorithm that sees a user posting the same content hundreds of times, or hundreds of messages from the same address, or other variations on the theme, then they can be flagged as potentially spammers and handled programmatically. I believe this is vital however, that it be programmed in and that the rules are enforced programmatically and not by people, as it's less prone to all sorts of nonsense we see on existing platforms. What's important is that if someone /wants/ all those adverts for penis enlargement by that "doctor" from Nigeria, then there's nothing to stop him ignoring the flags and accepting those messages, but also nothing stopping all the other nodes from both refusing to accept them as well as refusing to forward them on.

I have numerous other thoughts, but I hope this is enough to generate some debate.

All the best BoonDock

*** [Netmail-to-Telegram address: 474405162@2:460/256]

... Tag, you are IT!
--- tg BBS v0.6.4
* Origin: Fido by Telegram BBS from Stas Mishchenkov (2:460/256)