curious to know if matrix ever resolved their "federated" authentication problem. Can I finally host my own node completely separate from the matrix? this always made portability somewhat of a dicey situation.
The only thing I can think that you're referring to is the question of how you track the keys used by servers to sign the events they send. If the server is offline, and you've never heard of it before, you still need a way to check their key. We don't currently use CAs for this, but instead you grab a cached copy of the key from a trusted server: https://github.com/matrix-org/synapse/blob/a743bf46949e851c9.... This is a bit of an edge case, as in general servers whose events you care about will typically still be online - or you'll know their signing key back from when they were on line.
The longer term solution for this is https://github.com/matrix-org/matrix-doc/blob/rav/proposal/r... which includes the sender's public key in the event (by making it the sender's identity) - and we're working on this as part of P2P Matrix currently.
I think he refers to state reset issues in the currently used room versions.
If you just want to have your own homeserver, and users there to be identified as @whoever:example.com, then this just works, is fully federated, and has been like this since forever.
The only unfederated part is, from what I know, the Identity Server, which is run by Vector.im to allow discovering Matrix identities by phone number or email addresses.
You best make a separate ID for mapping your users to Matrix. And don’t show it to the user nor use it for anything else, also stay unfederated.
Say you're running Matrix for any kind of official or business purpose. You still want privacy, security, and ownership of your data. But you also actively DON'T want anonymity, instead you want publicly-verifiable user identities, linked to public information like company email addresses and company phone numbers.
Same goes for the push service for the iOS app, but that isn't really their fault as Apple makes it impossible for federated systems to do push without each homeserver having their own app. All notifications for a single app need to come from one centralized push certificate holder.
We have a separate bug to defer the server validation check until the user actually tries to talk to the identity (or home) server, but it hasn't got to the top of the todo list yet; patches welcome!
Edit: To clarify: this behaviour only occurs with Element Web (rather than Matrix clients or servers in general)
I don't use Matrix because I have not seen anything that suggests that you or the dev team are interested in building software that maintains end user privacy.
All of it phones home by default.
Everyone I have seen try to set up a selfhosted homeserver ends up with a config that has users phoning home back to Vector. At some point the "you can configure it however you want!" line to dodge this issue doesn't hold up.
Defaults matter. Your ignoring this means that the software is, in my view, insecure out of the box.
Matrix uses SRV records and .well-known for discovering the homeserver for a domain.
https://matrix.org/docs/spec/server_server/latest#resolving-...
[0] https://matrix-org.github.io/synapse/latest/federate.html
[1] https://matrix-org.github.io/synapse/latest/delegate.html
More details here: https://matrix-org.github.io/synapse/latest/reverse_proxy.ht...
Either add an DNS SRV record to example.com pointing matrix to matrix.example.com, or server a single JSON under .well-known pointing matrix to matrix.example.com.
https://matrix.org/docs/spec/server_server/latest#resolving-...
In my instance, my root domain is served from CloudFront, so in this instance I could add an A record to a homeserver VPS and use a SRV/.well-known to point to it :)