You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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