Do we want to build a snowman?

Post Reply
User avatar
Michcioperz
Site Admin
Posts: 17
Joined: 04 May 2019, 15:06
Location: Warsaw, Poland
Contact:

Do we want to build a snowman?

Post by Michcioperz » 10 May 2019, 10:07

Alexandria suggested in the other thread that maybe we should make some project together, and I think that's a cool idea, I just don't know what would be a good fit at the moment.

I think Wolf had some project he wanted to do that sounds a little too big for one person?

User avatar
Wolf480pl
Posts: 11
Joined: 04 May 2019, 16:08
Location: Poland
Contact:

Re: Do we want to build a snowman?

Post by Wolf480pl » 10 May 2019, 10:24

I wanted to design a chat protocol, somewhat in the spirit of ye olde IETF protocols (simple, telnetable), but better matching todays requirements.
I have a rough idea for what the protocol would look like, may describe it later if you want.
The plan is to:
- Understand the existing protocols (IRC, XMPP, Matrix) and learn from their failures. (I already understand IRC and XMPP pretty well, I'm yet to see Matrix spec though).
- Aim for a simple and stable spec with at least two independent implementations, of which at least one is in C (or asm if you prefer :P)
- From the very beginning, the spec should evolve together with implementations. It shouldn't be retroactive (like the IRC RFCs which nobody honors), but it also shouldn't be designed in void.

And while I probably could make a spec and single implementation if I had enough time, it's better to have multiple people, because:
- The spec ends up being better if many people with different viewpoints voice their criticism and come to a consensus.
- Multiple implementations naturally lend themselves to being written by multiple people. This is also a good test of whether different people understand the spec in the same way, and if the spec is precise enough.

What do you think of this idea?

User avatar
alexandria
Posts: 14
Joined: 04 May 2019, 23:42

Re: Do we want to build a snowman?

Post by alexandria » 11 May 2019, 09:35

I've been mulling over implementing a simple server for a protocol that you can use telnet with. There's something kind of beautiful about being able to crack open telnet (or ssh or whatever) and just type the commands that the server expects? FWIW I also absolutely adore SDF's com system. It's secure in that nobody can really take advantage of it, and nobody outside the system can read the messages posted to it.

The 'old unix'y feel of these systems is really sweet and comfy, idk.
trans gal
assembler monster will eat your code

Image
Image

User avatar
Wolf480pl
Posts: 11
Joined: 04 May 2019, 16:08
Location: Poland
Contact:

Re: Do we want to build a snowman?

Post by Wolf480pl » 11 May 2019, 10:02

alexandria wrote:
11 May 2019, 09:35
There's something kind of beautiful about being able to crack open telnet (or ssh or whatever) and just type the commands that the server expects?
[...]
The 'old unix'y feel of these systems is really sweet and comfy, idk.
Yes, so much this.

But that's not the main reason I want my protocol to be usable with telnet.
The main reason is that it helps a lot with debugging, troubleshooting, and with understanding the protocol.
It also makes it easier to test edge cases, and to experiment with new potential features.
alexandria wrote:
11 May 2019, 09:35
FWIW I also absolutely adore SDF's com system.
Haven't heard about this one. Got any links?

User avatar
alexandria
Posts: 14
Joined: 04 May 2019, 23:42

Re: Do we want to build a snowman?

Post by alexandria » 13 May 2019, 22:34

Wolf480pl wrote:
11 May 2019, 10:02
Yes, so much this.

But that's not the main reason I want my protocol to be usable with telnet.
The main reason is that it helps a lot with debugging, troubleshooting, and with understanding the protocol.
It also makes it easier to test edge cases, and to experiment with new potential features.
Oh indeed! I also think that encryption as a concept should be separate from the format itself, unless the format is designed for error correction, in that case it should probably be wrapped by the format, ig.
Wolf480pl wrote:
11 May 2019, 10:02
Haven't heard about this one. Got any links?
There are some on sdf.org but really the best way is to get an account there and try it out.
It might take you a second to find the currently-used room, and it's worth turning on overstrike so that it updates properly.
https://sdf.org/?tutorials/comnotirc
trans gal
assembler monster will eat your code

Image
Image

User avatar
alexandria
Posts: 14
Joined: 04 May 2019, 23:42

Re: Do we want to build a snowman?

Post by alexandria » 17 May 2019, 01:59

Wolf, do you have any preliminary ideas of what you want from the chat protocol or are you still mulling it over and doing research?
trans gal
assembler monster will eat your code

Image
Image

User avatar
Wolf480pl
Posts: 11
Joined: 04 May 2019, 16:08
Location: Poland
Contact:

Re: Do we want to build a snowman?

Post by Wolf480pl » 18 May 2019, 13:12

I wrote some of them in a thread on Fedi (I know, a bad way of writing things down):
https://niu.moe/@Wolf480pl/102011474655604975

But then after talking with RX14, I changed/refined some of those ideas.
I should really write them down properly, but here's a summary:
  • Simple, telnetable, line-based.
  • Regular language.
  • Easy to implement in C
  • Easy to write servers and bots for
  • From the server's POV, a message body is a string of bytes, not containing some reserved bytes. It's up to the client to come up with some internal structure for the message body (formatting, images, mentions, threads, etc.) and to escape reserved characters. The server will never parse or escape/unescape the message body.
  • Mechanisms for authentication, permissions, etc. provided by the server should be expressive enough that people don't make another ChanServ
  • Authentication, permissions, and other channel state is Consistent Partition-tolerant, i.e. you can't give or take ops during netsplit (so that people don't make another ChanServ). Initially, each channel will have one authoritative server, responsible for those things.
  • Messages are Available Partition-Tolerant, so that you can still talk on a channel during netsplit through non-authoritative servers (unlike on Slack)
  • Federated
  • Assume clients are on poor links with high latency, packet loss, frequent disconnects, changing IPs, behind NAT, etc.
  • Decouple channel membership from having alive connection.
  • Users' homeservers can offer to store more history than the channel's server[s]
  • Scalable/Efficient
    • heard it needs to work ok with 100 000 users in a single channel, if we want to compete with Discord
    • if some users are on the same homeserver, don't send the same message multiple times
  • Limited extensibility (we don't want a mess like XMPP extensions, aim for sth more like IRCv3's capabilities)

Post Reply