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.
You've always been able to run a Matrix server completely separately from the wider federation, and there are loads of them out there (we estimate around 35,000). Unsure what "federated" authentication problem you're thinking of.
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.
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.
> Now why would anyone want to peg phone number or account number to Matrix ID?
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.
Matrix installations by default (even on your own server) have all users phoning back home to the Vector identity stuff.
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.
There's no "phoning home". What I think you're talking about is that Element Web's default config specifies the identity lookup server at vector.im: https://github.com/vector-im/element-web/blob/develop/config.... The identity server is optional, and just used for looking up matrix IDs based on email address or phone number. When Element Web launches is currently checks if your config is valid (i.e. do these URLs actually point to valid servers?). If you're running your own deployment with your own server, then you'd point the config to whatever identity server you wanted, or just remove it entirely - just as you'd point the config to default to your own homeserver.
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)
The Element Messenger in the iOS app store also has an appalling privacy label, considering it's a client for an ostensibly selfhostable service.
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.
Yes, this is what I do. You just set a DNS record on a subdomain, e.g. matrix.mydomain.com, and use that as your home server. Your username can still be @me:mydomain.com with this setup.
This is a good question, as historically different protocols used different ports to communicate, meaning you could have many services on the same domain/IP, but recently many new protocols run over HTTP port 443... And I think Matrix is one of them, so the answer is no, you cannot host both a website and a matrix server on the same domain name. Happy to be corrected if I'm wrong.
Actually, it uses port 8448 for federation [0], which is unlikely to conflict with other services. But, even if it does, there are ways to specify a different port or subdomain [1].
No, you can have both. All you need to do is proxy a few paths to the running instance of Matrix. Those paths are matrix-specific and won't interfere with anything else. I've been running on this configuration for some time now.
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.
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 :)
