Is there a document of the MRC protocol somewhere? I'm considering adding support (to non-Mystic of course).
Is there a document of the MRC protocol somewhere? I'm considering adding support (to non-Mystic of course).
That would be cool. If we can find out how to interface with the MRChat server from other bbs software types we could then have a central chat system
for all araknet boards. :D
Not yet and this will very likely change as I've already started doing work on the server portion but will have a protocol document done for interoperability with other BBS platforms. I think it would be nice to have.
This. I wouldn't mind taking a look at it for a possible C-NET mod. Talk about the Amiga and PC/Linux BBS world finally coming together!
Hmmm, if there isn't already a solid protocol definition, I'd suggest a RFC style approach here.
Hmmm, if there isn't already a solid protocol definition, I'd suggest a RFC style approach here.
I don't think it should be that feature-full, super simple to implement.
Basic features like MRC right now with some small adjustments but not a lot more. Otherwise, there is no need to do something we can just use IRC and be done with it. I would add encryption however and some kind of authentication control for the BBSes.
I don't think it should be that feature-full, super simple to impleme
Agree -- ideally possible to implement on retro systems.
StackFault around Wednesday, February 6th...
Basic features like MRC right now with some small adjustments but not lot more. Otherwise, there is no need to do something we can just use and be done with it. I would add encryption however and some kind of authentication control for the BBSes.
General thoughts without much thinking:
- Encryption is a must
- Basic channel concept ('global' being the default / what most would probably use?)
- boardTag:userName type uniqueness
What kind of BBS auth you thinking?
Are there good reasons to not just build on top of e.g. Discord APIs? I suppose Discord could go away one day, but I don't see that in the any near future -- and people would probably dupe server APIs/support if
they did (assuming that hasn't yet already been done)
I don't think it should be that feature-full, super simple toimplement.
Agree -- ideally possible to implement on retro systems.
Authenticate the connection between the server and the board. Then everything flows in between.
Another thing I'd like to see implemented is
the concept of server clusters and load balancing to ensure high availability and connection distribution.
Well, there is many possibilities. I'd prefer a completely open standard however. Don't know specifically about Discord on the other hand.
Throw your ideas!
StackFault around Wednesday, February 6th...
Another thing I'd like to see implemented is
the concept of server clusters and load balancing to ensure high availability and connection distribution.
HA I agree with (see below), but I imagine a RPi3 can easily support a "large" chat server.
On Wednesday, February 6th StackFault said...
Well, there is many possibilities. I'd prefer a completely open stand however. Don't know specifically about Discord on the other hand.
I'd like open as well, but am weary of self hosted without entering the realm of mesh/distributed which drastically complicates things. I hate seeing servers (especially common in the case of BBSing) pop out of existence. Everyone says they'll keep a server up; no one ever does :D
On protocol basics:
- JSON is always a nice goto but /might/ be harder to implement in older languages/systems. I'd hate to restrict if no one ever does though.
- JWT is great for auth, but similar issues (well one being that it's
JSON based)
- Encryption as a must, yet this can be hard to implement on older
systems as well; Consider tring to calc even SHA-1 on older hardware;
I've seen it done, bit it takes ages. Yet, things that are easy to implement are weak.
On Wednesday, February 6th StackFault said...
Throw your ideas!
Thinking more RE retro systems and security: I think this may be impossible to *fully* implement, actully.
Consider a 6510 8-bit processor: Modern security is simply a no-go here. While you could technically compute, things would literally take days (weeks?) that take ns/ms on modern CPUs with e.g. SHA extentions.
Perhaps clients (e.g. boards connecting to the server) could be pre-determined as to if they require security or not + an opt-in system for channel(s) that are allowed to be broadcast to non-secure clients. Secure clients get all the beef; non-secure clients may have some.
or TL;DR: Channels have a security pref default to 'required'; If 'optional', non-secure clients can interact with them.
More protocol talk:
Perhaps the protocol should be binary such that it is easier / faster to parse on older systems. JSON is nice and all, but parsing it sucks, especially if you have to write a library and can't load full document into memory easily :)
Anachronist and I were talking about this project as I will be working to create a C-Net client so that C-Net users can join in the chat rooms.
Here are a few of my initial thoughts:
You might want to consider adding some form of version system for the packets. You don't need to change the packet structure as the client should only really support one particular version (the one it was coded with).
During the handshake the client can notify the server what version of packets it supports. That way the server can support multiple versions
of packets so you can maintain compatibility at the server level to various levels clients as you implement newer features in the server.
Also, I am not sure about other systems, but forcing a space in the
handle to be changed to an underscore "_" and back again may cause problems for any system that allows an underscore in the Handles. This
is not a problem for C-Net as it does not allow that, but could for
other platforms. You might want to consider a non-printable character code as this will be code controlled so the actual character does not matter. If not then you may want to consider some form of escape character to allow "_" in the handle.
I've also added the cross-platform transcoder I wanted to do if we go cross-platform. For now I thought of PIPE codes and Amiga ^Y, the way I
plan
I've just updated the protocol draft in DropBox with the changes I had
made
and also included the spaces placeholder you proposed for the handle (vert valid point, even for Mystic)
| Sysop: | Kurt Weiske |
|---|---|
| Location: | Aptos, CA |
| Users: | 133 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 234:35:53 |
| Calls: | 9,722 |
| Calls today: | 1 |
| Files: | 12,049 |
| U/L today: |
16 files (1K bytes) |
| D/L today: |
2 files (182K bytes) |
| Messages: | 124,189 |