Hacker News Reader

Comment by jauco | Hacker News Reader

I might be mistaken, but from what I read the main addition is that all peers replicate the full state.

If you have a dominant xmpp server (like gmail was) that removes xmpp support, its users have the start using other clients to connect to it or start a new social structure from scratch. In essence this makes the xmpp server a dominant player with leverage.

If gmail had used matrix when it pulled the plug all interactions (who knows who, how to route traffic, chat history) would have been replicated at the peers so it would just have removed google’s servers from the equation. The people who had been using it would continue uninterrupted.

View on HN

You're both right and wrong.

In both cases, if users have an account on gmail and are using it, and gmail pulls the plug, then they can't use it anymore and can't migrate. The history is still there in the case of matrix, but they can't reuse the same account.

However if another user is homed on another server, they would still keep the knowledge and history on their side: gmail did pull the plug on xmpp, yet people are still using it. Their server still know who their contacts are, what room they're usually in, etc...

Matrix does have the advantage that the chat history is fully replicated on all homeservers so it makes history retrieval much saner, but that's it. Matrix doesn't route traffic (messages go from sender's homeserver to recipients' homeservers, that's it) and doesn't share client's information with the whole world.

Too bad. Well consider this a feature request then ;)

> The people who had been using it would continue uninterrupted.

I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally.

As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)

> I'm not sure about that. If the main matrix server disappeared today that'd be problematic

This ^^ Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.

To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle.

After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.

FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.

Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances.

I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.

This isn’t anything to do with the size of the matrix.org server; just that synapse needs to be more resource efficient and we need to limit the sizes of rooms small servers try to join. we are doing both.

for rooms which span servers, the history is already migrated by nature of the protocol being decentralised.

for everything else we’re working on decentralised accounts via MSC1228.

there are also migration scripts and tools to move you between accounts on different servers today (like email).

Reply on news.ycombinator.com