I have my doubts about this. So many IM systems have got this wrong before that there's no reason to give anyone the benefit of the doubt.
I, too, have looked at matrix at some point. I setup a server, created a user, joined a couple low traffic rooms in their main server, and found major practical issues on their protocol's behaviour.
It had problems with signatures when messages contained a certain field, so some messages appeared and others were missing. This seemed very unorthogonal (why is the payload not just a field of its own? Why do messages have so many fields? Why is the signature code different on both ends?) and left a bad impression. To top it off, the server was making me hit my ISPs (pretty bad ISP) connections per second limit. It was opening connections to hundreds of servers, constantly, which seems like seriously bad for scaling, considering I had only joined two low traffic rooms.
So, I fear this is going to be the same Jabber/XMPP bullshit all over again.
Apparently, development focus isn't on making the basic protocol perfect, but on UX nonsense and adding features (think "reaction animations" and other such crap) to try and attract the riffraff. No better than your average commercial IM "app".
I do strongly hope I'm wrong, but I'll stay in the sidelines for now; I did shut my server down because of the connections per second problem. I might give it another go in the future, once their golang server implementation gets there.
Did you file a bug on this? We're not aware of any signature problems whatsoever in Synapse (or Matrix).
> Why do messages have so many fields?
So looking at a message like this:
"body": "Yep, almost a year ago.",
* `origin_server_ts`: the absolute TS the sending server claims
* `sender`: the matrix ID of the sender
* `event_it`: the UID of the event
* `unsigned.age`: a relative TS for receipt on your local server (added by your local server, hence being unsigned)
* `type`: the namespaced type of the event. In this instance, `m.room.message` is the general purpose Instant Message event type.
* `content`: arbitrary JSON to describe the contents of this type of event. In this instance, it's a plain text message with a given body.
* `room_id`: the room the event's been sent in.
This doesn't seem unreasonable? (but I may be biased thanks to working on it).
> To top it off, the server was making me hit my ISPs (pretty bad ISP) connections per second limit.
Oops. This might have been a while ago before we improved the connection pooling for federation traffic? What's the limit?
> Apparently, development focus isn't on making the basic protocol perfect, but on UX nonsense and adding features
We're trying to do both. A perfect protocol is useless if it doesn't have flagship apps which make it usable by normal people. Right now the protocol is relatively good; the Python/Twisted impl is very heavyweight (but getting better); Riot (as a flagship app) also has perf problems but it hopefully headed in the right direction.
Dendrite should be an enormous improvement on the serverside when it gets there however!
To be clear, it got solved, and it happened several months ago.
> the Python/Twisted impl is very heavyweight (but getting better)
Constantly near-saturating rpi2 cpu while doing effectively nothing last time I turned it on. (70%+ cpu time). This is why I'm thinking I'll wait for golang until I try again.
>Right now the protocol is relatively good
- If I delete my server database, start anew, and join a room I used to be in, will I end up in a bad state, or are things more robust these days? I remember reading about it somewhere.
- Does the server _still_ solve a bunch of names and open hundreds of connections / server event interval or whatever it was called?
It should end up (eventually) in a consistent state, but it can take a while to sync up again.
> Does the server _still_ solve a bunch of names and open hundreds of connections / server event interval or whatever it was called?
It's still full mesh, so whenever you send a message in a room, your server has to make a HTTPS hit to every other server which is participating in that room. In a massive room like Matrix HQ, this could mean 800 hits or so. It shouldn't do DNS every time, and it shouldn't open a new connection every time, but haven't checked the connpooling recently; hopefully it hasn't regressed.
Just to be clear, I saw this behavior without sending anything to any room. Just by being in the room.
If the server interval setting was 5 seconds, it'd literally do hundreds of connections every 5 seconds.
# The federation window size in milliseconds
That's how high it needs to be set, apparently.