Hacker News Reader

Comment by q3k | Hacker News Reader

What do you mean by federated authentication?

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.

View on HN

Now why would anyone want to peg phone number or account number to Matrix ID?

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.

> 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.

Then keep them detached with the Matrix ID <-> Custom ID <-> Phone, in DB relationship parlance.

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.

Is there a way to run a homeserver on mydomain.com but also serve a website from that?

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].

[0] https://matrix-org.github.io/synapse/latest/federate.html

[1] https://matrix-org.github.io/synapse/latest/delegate.html

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.

More details here: https://matrix-org.github.io/synapse/latest/reverse_proxy.ht...

You don't even need to do that.

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-...

Ah, that is much better.

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 :)

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.

Yes.

Matrix uses SRV records and .well-known for discovering the homeserver for a domain.

https://matrix.org/docs/spec/server_server/latest#resolving-...

Reply on news.ycombinator.com