Jump to content

Text BBS concept


TomXP411
 Share

Recommended Posts

  • Super Administrators
On 1/11/2022 at 8:37 AM, ZeroByte said:

Sites like this offer features and functionality that just aren't possible / reasonable on sites like Facebook. Social media is all in the here and now. Sites like this have more permanence. If someone announces a game on the FB group, for instance, it will get focus for a little while and then fade into the past, whereas a thread about it is much more searchable and focused.

To me, the number 1 feature is the software area. Once a project is uploaded there, it remains visible and accessible where on FB it would quickly fade into the past as new posts push it out of view. I totally get why Dave et al would consider it an extra workload to have yet another inbox to check, and why they may not be interested in participating directly, but the site is very important to me and many others. Having team members who run the community is just as important as team members who crunch kernal code or test HW designs. In fact, this is the one job that will continue to exist once the HW and Kernal are finally done and "in production."

Speaking as a BBS junkie from the 80s and 90s, I agree. The only thing that would make this place better is if it had an actual text-based BBS attached. 

Which I'm considering trying to make happen...

  • Like 7
Link to comment
Share on other sites

  • Super Administrators
On 1/11/2022 at 12:09 PM, ZeroByte said:

BBS over SSH. Don't forget to have a Tradewars door game on it. 😉

That's the general idea, although it would be plain old Telnet - actually not even Telnet, but raw TCP, since that's what most serial terminal adapters (aka "WiFi modem") can understand. Many don't even implement proper Telnet clients, let alone encrypted SSH.

 

 

  • Like 3
Link to comment
Share on other sites

  • Super Administrators
On 1/11/2022 at 12:37 PM, Scott Robison said:

This sounds like a job for pi2iec!

I'm thinking Linux, Python, and accessing the forum database remotely (probably via an HTTPS webservice interface.)

  • Like 2
Link to comment
Share on other sites

  • Super Administrators
On 1/11/2022 at 3:09 PM, ZeroByte said:

And if your BBS interface works like WWIV, I'd be like :classic_love:

I still have the WWIV source code. I was planning on just compiling that in QBX and adding a socket layer to interface with the webservice... 

actually, I ran a WWIV board. I had to modify it to support threading, because non-threaded discussions were impossible to follow. If I was going to start over, thread support would be a big priority in the forum area.

On 1/11/2022 at 3:08 PM, ZeroByte said:

You'd want to make a big flashing red disclaimer that people's forum password should be one they have not used anywhere else if they plan on accessing an unencrypted interface.

This is true. We don't want people connecting via non-encrypted Telnet, then giving their password away. I'll have to come up with some sort of token system.

Actually, I have an idea: a local proxy that encrypts everything before passing it to the web. It would also HTTPify everything, so the interface would actually be a specialized theme running on top of the forum software. Regardless, I'm going to move these BBS topics off to a new thread, because this sounds like a fun project. 

 

  • Like 1
Link to comment
Share on other sites

Why not just put an openssh daemon in front of a TTY and lie to WWIV and tell it it's a serial connection? Make all the init strings blanks. I think the only thing that might need to be messed with is the whole "ring/answer" thing that the software would expect to have to do... It would save all that extra code hacking on the comm side of things. All that would remain would be either a mod or middleware to make it think the forums' DB are its own DB.

 

Link to comment
Share on other sites

On 1/11/2022 at 7:53 PM, ZeroByte said:

Why not just put an openssh daemon in front of a TTY and lie to WWIV and tell it it's a serial connection? Make all the init strings blanks. I think the only thing that might need to be messed with is the whole "ring/answer" thing that the software would expect to have to do... It would save all that extra code hacking on the comm side of things. All that would remain would be either a mod or middleware to make it think the forums' DB are its own DB.

Other than the WWIV part 😄 That sounds like a great project to attempt once we've gone through the process of securing (not security) all the assets of the forum, and decide what software to use for the forum longer term, as Invision is "not cheap" (to be charitable).

Link to comment
Share on other sites

  • Super Administrators
On 1/11/2022 at 6:53 PM, ZeroByte said:

Why not just put an openssh daemon in front of a TTY and lie to WWIV and tell it it's a serial connection? Make all the init strings blanks. I think the only thing that might need to be messed with is the whole "ring/answer" thing that the software would expect to have to do... It would save all that extra code hacking on the comm side of things. All that would remain would be either a mod or middleware to make it think the forums' DB are its own DB.

 

WWIV (and most DOS BBSs) are inherently single-tasking programs. Even if they're network aware, and so can run in a multiuser environment,  It's kind of silly to run a single-tasking application in the modern day. One thing you should really have in a modern BBS is the ability to spawn new nodes on demand, as a response to incoming connection requests. This requires a few things, including that the software natively handle Sockets.

The other thing you need to do with a modern BBS is connect to its storage medium through either a RESTful or SQL type of data connection. In the case of WWIV, Wildcat, or really any DOS based BBS, you'd be almost completely re-writing it to work with a modern database, because so much of the code is tied up in reading and writing to file-based data structures. The security model, data storage for forum data, and even the inter-node communication is all handled by writing files to disk and reading them back again. This is problematic when you're dealing with distributed systems or with systems running on limited-durability storage, like flash or SSD media.

So my thinking is really to start over, with a few basic ideas as guidelines: the BBS would be document based, rather than stream based, and the actual BBS software would be a front end to a webservice. 

  1. The board would actually be a web site. Each screen on a BBS would be an HTML template. 
  2. The front end (what you actually connect to with your modem/terminal) would be responsible for reading out the HTML and displaying it as an ANSI text document.
  3. The front end accepts input from the port and submits menu commands, form posts, or file uploads as a HTTP POST transaction.
    1. The entirety of a Message posts would be a single POST. So all of the editing happens in the front end.
    2. Menu commands are just anchor tags, with an additional property to tell the client what shortcut key to use. ie:
      <A href="messages.wml" shortcut="m">[M]essages</a>
  4. The front end would be multi-threaded, with a single monitor program dispatching nodes as needed. 
  5. The back end should be fully browser compatible, for troubleshooting and forward compatibility. So someone could connect with Firefox as easily as a Commodore 64.

In fact, I'm thinking WML is a close match to what I need, so I'd probably start with that and add features as needed. 

If you guys are interested, I can work up a mockup to show what I'm talking about. 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use