I am not sure if P2P is a step forward. P2P is okay when you have a stable connetion, but when it comes to mobile communication you want to have some sort of always-on service to store/buffer your messages.

From the technology perspective I am quite happy with modern XMPP. There are just too few good (up-to-date) clients :-/

For the most part I use 'conversations' and while it is quite a good client for messages, it has no support for calls.

> you want to have some sort of always-on service to store/buffer your messages.

An instance running on a NAS or similar device at home to provide that backlog capability should do the job, no? I don't know if ring supports that, but the concept is simple and at least as old as bouncers for IRC.

Well, buffering that kind of stuff, is one of the more complex parts of an XMPP server (XEP-0013, XEP-0160, XEP-0280, XEP-0313). AFAIK IRC bouncers tunnel all the traffic and are not mobile aware. So to reduce battery usage, XMPP has some functionality within the protocol (XEP-0198, XEP-0352). So after optimizing your bouncer approach you will probably come up with what XMPP does (more or less, maybe with a few minor exceptions).

XMPP also knows how to do P2P connections (that is what 'jingle' is actually about, not just calls), but I think that the problems of P2P are actually the reason why there are still so many problems with XMPP calls. I mean if you want to build P2P that 'just-works' you will need STUN/TURN servers and while XMPP servers like ejabberd bring them with a standard installation, TURN servers require a lot of ressources (bandwith). At the same time the others parts of a XMPP server are very lightweight so that the TURN server causes scaling issues.

For anyone interessted in the matter I highly recommend taking a look at the 'conversations' website (https://conversations.im/#optimizations).

> An instance running on a NAS or similar device at home to provide that backlog capability should do the job, no?

Do you really think 99% people care enough to do this?

Well, if we take the people who would install ring in the first place and have some tiny server at home that can actually install software I would say the chances go up significantly.

It could use some streamlining, e.g. get it into package managers for whatever distro is running on it, automatic pairing (multicast on the local network), maybe detection of compatible devices.

UX is basically a separate set of problems you have to solve on top of making it work technically.

You mean Ring is distributed. Matrix and XMPP are decentralized.

That's true, except for the fact that Matrix and XMPP are also distributed. What I really meant is that it uses a DHT for peer discovery and that the peers communicate directly, without using any central server. It is more distributed and more decentralized.

You are right, except:

- "Peer-to-peer" (Ring, Bleep/BittorentChat) and

- "Federated" (Email, Matrix, XMPP/Jabber)

...would be a better way to convey that distinction.

An image illustrating the different concepts: https://a.doko.moe/ubvuak.png

That link is giving me problems.

> Secure Connection Failed

> The connection to the server was reset while the page was loading.

> The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

I love P2P but I'm not sure it's the best approach for IM and this kind of application. In particular it makes difficult to sync message history/contacts, it needs more bandwidth than a client/server application and consequently impacts battery life for mobile devices.

It's not necessary to sync history and contacts between devices in a peer-to-peer way because there is no network externality for synchronizing data. You could use a centralized service to sync the encrypted data. If the centralized service ever does things you don't like, you can change to another centralized service or host your own, and, importantly, you can do so without being affected by what other people do.

Communication platforms provide more value when they have more users, while centralized synchronization services don't provide more value because they have more users. So it's fine for synchronization services to be centralized, while it's not fine for communication platforms to be centralized.

If I own two devices, logged in to a chat service on the same account, and they have different chat histories and contact lists because there's no account sync, I will throw that chat service in the trash can.

This has nothing to do with the synchronization service being peer-to-peer or not.

I think the best approach is to have a true P2P version for windows and other PC systems and make the mobile client treat your PC as the server, just like WhatsApp web uses your phone to avoid all the syncing.

Why would peer to peer require more bandwidth? More simultaneous connections?

Take just for example (if it's a feature, I don't know) setting yourself to an away state. In a client-server model you'd just tell the server you're away now with any metadata that goes along with it. Other clients will get that information from the server.

With a p2p model you have to tell every contact's client that you're away and provide any metadata that goes with that information to each individual contact.

To reiterate the away state is just an example off the top of my head, I don't know if this service supports status updates.

I'm not very familiar with Matrix and new to Ring, but can you explain how Ring is more decentralized than Matrix? I guess Matrix still requires the homeserver, making it somewhat centralized?

You answered the question yourself.

Most Matrix users use the matrix.org Synapse installation. If the people running matrix.org decided to stop working with other homeservers, the result would be much the same as what happened when Google and Facebook became less friendly to other XMPP servers and stopped interoperating with them. This is not an issue with Ring.

Matrix is slightly different to XMPP in this respect, as rooms are shared over all participating servers. So if the matrix.org homeserver went down (as it ocassionally does), all the users on other servers continue without impact. As such, it's more like email than XMPP.

Meanwhile we're also working on supporting decentralised accounts in Matrix, so users can pick which set of servers they can use as a homeserver. This then gives the best of both worlds: a simple thinclient protocol that anyone can implement, and knowledge of precisely which servers and devices host your data.

Basically, Ring and Matrix have totally different architectures, and which you use probably depends on what you are optimising for :)

Respectfully, I disagree slight...while yes most users using matrix DO USE the matrix.org instance, if it does go down, there's nothing stopping users from hosting their own ABCXYZ.org home server - in fact the matrix.org team encourage that. So, there isn't the hard dependency on the matrix.org instance that you might believe.

There would be nothing stopping users from hosting their own homeserver, but there would be something preventing them from communicating with all the users still on matrix.org. And all the users still on matrix.org would stay there because the matrix.org homeserver would provide more value to them, by having more users, than a homeserver that can't communicate with most Matrix users.

Yeah, i see your point...I guess once a popular hub like the matrix.org home server goes "offline", the curve to "re-discover" your colleagues on their own NEW home servers - assuming they even set themselves up on their own self hosted home servers - is a pretty steep curve. Though some users already use their own home servers (like owning their own domain name to use for their email address), plenty of people siomply leverage an account strictly on matrix.org...so yeah, lots of people would "go offline" from the matrix protocol. (I begrudgingly see your point :-)

How is XMPP not decentralized? If you call XMPP centralized, then email is centralized as well.

Perhaps OP doesn't consider federation the same as fully peer-to-peer? Still a weird choice of words though.

Is Ring the latter? The 'Discover' and 'FAQ' sections of the website don't seem to answer that question.

The name registration is done with a blockchain (ring-nameservice) and a DHT (OpenDHT). You can find the information on the wiki in their Tuleap instance.

Seems to be Ethereum... ouch. You'd've hoped people would've come up with a better way of solving Zooko's Triangle than forcing everybody to store an ever-increasing, unprunable amount of data on their devices - that also requires massive amounts of data to be downloaded, wherever you are, even over mobile networks.

In practice, even DNS-based aliases are a better idea, given the tradeoffs.

Ethereum might not have been the best choice, but there are ways they could migrate to another GNU Ring-specific blockchain (therefore a smaller blockchain; there are only so many people who are going to use Ring and they will only want to have so many separate identities) if the Ethereum blockchain really became unmanageably large.

Blockchains grow unmanageably large over time by definition, no matter how application-specific you make them, unfortunately. Ethereum isn't the problem - blockchains are.