Replies: 5 comments 23 replies
-
|
@faragher I've been crazy busy with work and away from the Reticulum scene for a while and just happened to pop on to the discussions page today. Obviously this topic is somewhat near and dear to my heart. I wanted to call out again what you already called out as an important point:
The "Reticulum Ace" BBS was actually the motivating force behind The BBS, however, was little more than a novelty. It was fun to relive my sysop days for a bit and to play minesweeper over Reticulum, but the idea of a central messaging hub is a little antithetical to Reticulum. This part really needs some thought, I think. LXMF and NomadNet were @markqvist's best answer for messaging over Reticulum, but there were some needs this just didn't meet. There were some cool NomadNet-based approaches to solving the problem, too. Some people were working on LXMF group-chat reflector bot systems, other folks on message boards, and other folks yet on Reticulum directories that catalogued announce data. I'm not sure how the scene has changed in the past year, I haven't been able to keep up with Reticulum developments due to my workload at the moment. But at the time, NomadNet itself, with its broadcast capability, really seemed like the closest thing to a BBS that also accommodated the full distributed and privacy-first values of Reticulum. Group messaging was I think the big thing it was missing, and that's a hard problem to solve. Wonder if anything short of a completely novel approach to what a bulletin board system is would end up looking like a BBS over Reticulum rather than a Reticulum BBS. 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
Noticed you'd been gone a while. Busy with work is one of the better reasons. :D Over the past year there have been some great under the hood improvements, still no multicast, and a great web-based messenger program Meshchat. I'm sure I'm forgetting some other moves, but outside of Meshchat it's been important incremental improvements (for example, non-link packets now have the option to use "ratcheting" which provides forward secrecy) that blend together in my head. I think it's worth digging into what a BBS is, and go from there. Probably do so in a separate post. |
Beta Was this translation helpful? Give feedback.
-
|
I've been out of the Reticulum loop for a little while now, but seeing this pop into my mailbox has piqued my interest. I kind of like the idea of a Reticulum BBS, since a BBS-over-Reticulum is simply just a tunnel. Not that a tunnel is a bad implementation, and it does provide access to those that don't use Reticulum, but I think the idea of a Reticulum native application more interesting 😁 Anyone already working on a Reticulum BBS? I'd be interested in giving it a go. |
Beta Was this translation helpful? Give feedback.
-
|
I always wanted to do it, but I kept coming back to how other BBSes didn't really work (Mystic is closed source, Citadel is too huge, etc.). I think it would be useful to specify what a BBS is/does and figure out the Reticulum way of doing things. |
Beta Was this translation helpful? Give feedback.
-
|
If you want to get a sense for how BBS software can be structured, check this out: https://github.com/virtadpt/ebbs A long time ago, I ran my board on eBBS and, while it didn't have the features of DOS-based software (like door games or QWK mail) it still might make a good reference for another project. |
Beta Was this translation helpful? Give feedback.
-
|
ran https://en.wikipedia.org/wiki/Maximus_(BBS) - it's on sourceforge and the bbs archive |
Beta Was this translation helpful? Give feedback.
-
|
So, I'm going to shamelessly steal a list of features from Wikipedia (and since it can be shared, license fulfilled. ;) ) and discuss my thoughts on each, along with some things I think they took for granted: AuthenticationUsing Reticulum's authentication system removes the risks posed by passwords. Since no passwords are stored, they can't be stolen in a data breach. Similarly, it allows an automated authenticated user creation. This isn't to say the sysop can't change levels or require human authorization for new users, but the user/pass system simply has no advantages except multiple-access (which can be done simply by using the identity on multiple machines; so long as it doesn't announce, this isn't a problem) User ProfilesSo, this is a big question. One would assume a friendly user name, but are there public profile pages? Do you use flags, security levels, or both to allow specific access to resources. Are these local or federated? Who's an authority? One would assume a profile could be signed and passed along, but it's a big question. Menu systemsIt's a rather obvious in theory, but in implementation it's complicated. Micron is pretty nice for pages, but the typical BBS system is terminal mode, and is more efficient for small changes. So, the question is if the super-low bandwidth VT100 or ANSI based systems are worth the extra effort, or if passing a screen at a time is okay. Does it respond to keypresses, or is it transactional where you need to type a command (even a single character) and press return. This has certain asynchronous advantages, such as not storing state, but rather passing more complicated commands like HTTP requests. This is a lot more overhead and is more a web server, but can potentially scale better since the server isn't storing a state for each user. Important questions. One or more message basesI won't call the Reticulum message boards a solved science, but there are multiple implementations, each with their own styles and advantages. Now, Reticulum authentication is basically a given, but are these local? Are these federated? Who is and isn't allowed to see it? Who can invite people to a board? Etc. Uploading and downloading of message packetsThis is just Distribution Nodes with extra steps. E2EE messages across a BBS aren't much more useful than the current Reticulum systems. Public messages are better served on a board. Direct messaging to a user would be insecure and a risk to the sysop, but would allow messaging without exposing an LXMF address. Basically, the only thing the user would see is the friendly name of the user (plus any public profile). Not sure this is really useful. Maybe the board could facilitate some kind of key exchange that it's unable to access, but I'm not about to propose crypto systems. File areasReticulum resources. Easy peasy. BUT in my opinion these should never be federated. While links to other systems hosting files is usually fine and dandy, actually hosting files can be legally actionable, and the sysop is personally responsible for everything uploaded. Since Reticulum can easily connect to files some distance away, there are few benefits. However, there are benefits. usually for the reasons BBSes did this originally: caching files for local hosting helps keep node to node traffic down, especially over low-speed links. It might be worth the ability to federate certain files, but maybe this is best manually selected, or even manually downloaded. Live viewing of all caller activity by the system operatorFrom a security standpoint, this makes sense, but it may also be against the spirit of Reticulum. Uncertain. Statistics on message posters, top uploaders / downloadersThis seems counter to Reticulum's goals, but people seem to like it. See file area on my opinions on people uploading files. (which isn't to say they can't locally host them on their own instance or file repo; not my system, not my problem) Online gamesWe need Reticulum games. Like the old Cyberpunk or LoRD or something. A doorway to third-party online gamesNomadNet kind of does this with its ability to display output, but it doesn't really have interactivity. It's worth considering some kind of hook to allow real time two-way systems, but this is an incredibly complex setup which may not be any better than using rnsh to get a shell. Usage auditing capabilitiesAgain, this is important at least in aggregate. Multi-user chat (only possible on multi-line BBSes)Insecure, but not terribly difficult. Of course, without multicast this is a data hog, but the number of people actively in a chat is likely to be fairly low. Questions about if there's any server logging and for how long. This is useful for people who just entered the chat to scroll up and see what's going on, but can be a security risk. Internet email (more common in later Internet-connected BBSes)I mean, basically LXMF. Any non-E2EE messages on the server are a risk to server and user, so I say ignore it. Just (optionally?) expose a user's LXMF address and send messages directly. A "yell for SysOp" page caller side menu item that sounded an audible alarm to the system operator. If chosen, the system operator could then initiate a text-to-text chat with the caller.I mean, just expose an LXMF address, Primitive social networking features, such as leaving messages on a user's profileMy knees hurt just looking at this sentence, but the questions are the same as generating a profile. What should be shown? How granular are the options? Anyway, that's my general thought of the minimum required parts of a BBS. Should it be its own application? A NomadNet page? A protocol? I don't know, but I'd love to see it happen. |
Beta Was this translation helpful? Give feedback.
-
|
Just a couple hours ago, I set up a synchronet server just so I could play LoRD. Ah, nostalgia. It's interesting to think about this, and keep it within scope of the spirit of Reticulum. A NomadNet page can be just a python script, and it solves a bunch of the UI issue already. Maybe I'll tinker with the idea of setting up something that can be 'browsed' through NomadNet via python scripts to start with. I might just be reiterating AutumnSpark1226's NomadForum though, so hm... I'd be interested in trying something using Go, but... that's just me. |
Beta Was this translation helpful? Give feedback.
-
|
The more I think about it, the more I think we should separate out the components. Like the file-server could be a stand alone application that simply has a BBS front end. The advantage to that is that so long as the components are all Reticulum compliant, it doesn't matter what it's programmed in. A NomadNet file server/indexer would be an interesting project in and of itself. There are some basic examples in the Reticulum repo, but a fully-formed system with metadata and folders would be very useful. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the writeup! ran
|
Beta Was this translation helpful? Give feedback.
-
|
That seems like a pretty reasonable set of features (not prioritized, obviously). |
Beta Was this translation helpful? Give feedback.
-
|
In regards to the Reticulum BBS idea (which I like more), you’re really just looking for something like nomadForum but with more things like message boards and games. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
scuttlebutt talks gossip 😸 |
Beta Was this translation helpful? Give feedback.
-
|
no news though. |
Beta Was this translation helpful? Give feedback.
-
|
Two thoughts on the federation bit: Maybe making use of an existing protocol like rsync to synchronize boards' message stores is an option. Or maybe UUCP could run over a wireless channel; it worked well when point-to-point dialup was the most common link. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/TheCommsChannel/TC2-BBS-mesh |
Beta Was this translation helpful? Give feedback.
-
|
I've still been tinkering with this. Writing a BBS program is easy, the 'difficult' part is AAA and message federation, if desired. Also been trying to see if there's any sense in just adding in a Reticulum transport in on an existing system, or rehashing something everyone's familiar with for Reticulum use exclusively. Just my two cents for now, but I'll keep playing. |
Beta Was this translation helpful? Give feedback.
-
|
While I'm blanking on AAA, sorry brain is not braining, let's talk through the federation. Without being full Reticulum, but Reticulum style, I'd suggest identifying each message as a hash based off time and content (and perhaps another field, such as system of origin, but this is generalized). So you can positively identify a message by hash. If a board stores a list of messages for federation (retained by date, public messages, etc.) then a requester can request a message or list of available messages. The requester could then walk through that list if they'd like, requesting what messages they'd like. This is a very Reticulum way of doing things, requesting data rather than pushing it, but it can also do a bulk digest, where the requester sends a list of messages it would like as a single block, or even all messages contained. These have their own data size and security issues, but they are options. A resource that allows retrieval of a message might also be useful. Huh. Hold up. We could repurpose POPR (https://github.com/faragher/POPR) as the message store. We'd have to re-do authentication mechanisms, but the UIDL command would absolutely work as written. We'd have to add granular rights to allow retrieval without deletion, but by and large it's a functioning system that could act as at least half of a federation system. If we treat each post as an LXMF message with files and metadata, and the like, we can use those for sorting and propagation rules. It would require some thought on how to deal with, say, a message with a file if the server rejects files. Does it download the message text but not send the file? Does it reject the message entirely? The devil is in the details. But I can spin POPR up in the new year if you think it would function as a BBS federation system. Note I thought of that would've disrupted the above:
|
Beta Was this translation helpful? Give feedback.
-
|
Authentication, authorization, and accounting. Sorry, my radius is showing. Personally I think having federation is one of those nice to have features, but not necessarily breaking if it's not in the first iteration of whatever is created for the whole BBS over Reticulum idea. I need to understand better the idea of how someone signs in and is authorized to do things, and I'm using a handful of other implementations to figure it out. I am really on board with using POPR. 'Tis better to use existing solutions for new problems 😁 Also been looking at x84 and 'porting' it up to Python 3. |
Beta Was this translation helpful? Give feedback.
-
|
Not to worry, as an amateur programmer from a different field, my terminology is strange and lacking. :D POPR is designed to my best understanding of a clear, concise, and secure way to authorize over Reticulum and is, happily, one of the best documented systems I've ever made. If you have any questions or need any additional fundamental features to be useful, let me know, but I think it's pretty concise and well explained (said every dev ever). x84 looks interesting. Since it points to Enigma, I'm pretty sure their goals were pretty aligned to my expectations, so it's a great place to start. That being said, Reticulum really lacks a dedicated VT100 compatible system, and usually just transports SSH over the network. This isn't a problem, it's probably the right way to handle SSH, but we'd need a Reticulum terminal, which at the very least is headache for cross-platform compatibility, if rnx and rnsh are any indicator. Anyway, out for the day. Thanks for keeping up on this; a bunch of us are really interested in getting a BBS up and running, and sometimes all it takes is multiple people getting excited for a project at once. |
Beta Was this translation helpful? Give feedback.
-
|
As an aside, we have an opportunity here to create something that is 'X over Reticulum' and define what we want, how we want, since by definition it (Reticulum) is a network stack. At least, that's my interpretation unless I'm wrong. It's a nice thing to have compatibility/interoperability with existing (nomadnet, LXMF, etc.) but those are applications on top of Reticulum, I think? |
Beta Was this translation helpful? Give feedback.
-
|
NomadNet, Sideband, and LMXRouter are all built on top of Reticulum but are separate applications, correct. LXMF is just a format that shares a common lineage and requirements. So any data transfer over RNS is fair game; the use of their cryptographic systems and authorizations are simply leveraging its greatest strengths. While user/pass can be used, and any data is arbitrary, in my mind the only real thing a Reticulum compatible system needs, apart from being on the network, is using the identity as an authorization system. It's a personal preference, but I find it the fundamental building block of Reticulum as a concept. |
Beta Was this translation helpful? Give feedback.
-
As someone who not just wants a BBS on Reticulum, but puts it as a primary interest, I'm happy to see more people become interested. So I figured I'd make a list of my thoughts.
The most fundamental question, and this is a major one, don't skip over it, is do you want a BBS over Reticulum, or a Reticulum BBS? For a BBS over Reticulum, you want to connect over SSH, tunneling through Reticulum. Acehoss already put one together, and it's a fantastic concept. #231
The thing this is missing is an ease of access, but that's a link, address book, or alias away. Not a real problem.
A Reticulum BBS doesn't just tunnel through Reticulum, it is integrated with the system, particularly the identities. A BBS that authenticates using Reticulum and uses LXMF instead of e-mail for its primary means of communication preserves everything that Reticulum does and doesn't simply act as another transport layer.
The big question here becomes, "what if I want to log in with a user/pass from multiple sources?" Then use SSH over Reticulum. Using multiple systems in addition to Reticulum eliminates most of the security benefits not present over SSH, and if you truly need multiple access, you can use your identity across multiple machines. This may mean timing or even forgoing announces, but that's something that needs a little more field testing.
Now, as far as how to actually implement a BBS, the first step is a client. It can be done in any language Reticulum supports, and is basically a Reticulum-based terminal emulator. RNSH and RNX are similar, but not the goal. This is a generally useful utility that needs to be made anyway.
The server should probably be a base implementation, but the authentication is the biggest hurdle. For something like LBBS you'd need a C implementation of the Reticulum cryptography, authentication, announce, and link systems. You wouldn't need to handle transport, so it wouldn't need to be a full implementation, but it still requires enough to physically interface with the network.
To go back to LBBS, the "nets" interfaces it uses would have to be able to interface with the stack in one way or another, which would require a C implementation, but it would also need substantial modification to the authorization mechanisms. I haven't dug into the mechanisms involved, but it would need to use the identity as a user name and use the Reticulum authentication to only allow identified users. It's straightforward on the Reticulum end but would be a non-trivial rewrite of the authentication system.
It's all straightforward work, but it once again hinges on language-specific implementations of at least the non-transport parts of the RNS.
Anyway, those were my thoughts, and I am out of time. I certainly hope this helps someone make a Reticulum BBS. It's a great idea that meshes so well.
Beta Was this translation helpful? Give feedback.
All reactions