s2s protocol / linking (or 'federation') #26
Comments
Don't restrict MOTD lines to 80 chars
|
Investigating this with https://github.com/DanielOaks/dcmi/ |
|
As a bit of an update, no progress on this as of yet. This is something that's likely to happen a fair while down the road as I really wanna explore alternate methods of linking servers together. If someone wants to experiment and try some stuff out, that's awesome! But something sorta pluggable along the lines of Insp's pluggable linking methods would be good for experimentation. |
|
I was wondering if a mesh network could be used to peform the linking of servers together I did spot this http://meshbird.com/ |
|
Came across another peer2peer type network this is a library though https://github.com/weaveworks/mesh I think it's an interesting idea to build on top of a fault tolerent network which can handle the routing of the messages. |
|
Yeah, I have some rough thoughts about it around here. I'd like something meshy, but I'm not sure anything existing is appropriate for the sorta CAP availability I'm looking to have (the sort that IRC has always had). This blog post is a good one for reference of the issues with traditional systems as applied directly to IRC, and what I'm looking to avoid. |
|
I know this is probably not what you have in mind, but s2s multi user chat in XMPP is actually quite similar to IRC and is a well proven and stable method. Maybe enable Oragono to act as an XMPP server component (there is a stable API for it. That is for example how the excelled Biboumi XMPP to IRC gateway works: https://biboumi.louiz.org/ ) or include a cut-down s2s federation version of a xmpp server ( look here for a WIP Golang one: https://github.com/ortuman/jackal )? That way IRC could be quite easily federated without reinventing the wheel :p |
|
I think XMPP federation and IRC federation solve somewhat different problems. As I understand it, XMPP is like e-mail: each user is associated with a particular server, so there's never any question about how to relay a message, it always goes to that user's authoritative server. (So, much like e-mail, the protocol itself doesn't address how to provide high availability.) In contrast, with IRC, users are associated with the network as a whole. So high availability is built into the concept of federation (if your server goes down, you expect to be able to connect transparently to a different server), but the server-to-server protocol and its implementations have to know more about the distributed state of the system. |
S2S linking can be useful, and working out a decent S2S protocol to do it is the best way to do things. Look at TS6/Insp and other suggestions to work something out, timestamping is good and I'd likely use that in any S2S proto we use.
The text was updated successfully, but these errors were encountered: