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
Couple questions:
- 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
#federation_rc_window_size: 1000
federation_rc_window_size: 60000
That's how high it needs to be set, apparently.
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:
You get:* `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!