I think the Matrix folks shoot themselves in the foot each time they mention identity servers and how they're "not decentralised yet" because it just leads to confusion and makes it sound like their architecture is half-baked. To their credit, they're being painfully honest but all the same I think it does more harm than good when explaining Matrix to technical people who aren't familiar with Matrix.

As others have mentioned, identity servers only exist to map third party identifiers like email addresses or phone numbers to MXIDs. Most people just use MXIDs to start chats (mine is @cyphar:cyphar.com -- it's no more complicated than an email address). It is a useful feature to have, but given that other chat systems don't even have such a system (you can't find someone's email address using just their phone number -- GMail might implement this but that's just as centralised as Matrix's identity servers) it seems pretty unreasonable to say that Matrix's claims of decentralisation are "bullshit".

People have been working to make this system decentralised but it's actually an unreasonably hard problem to prove to everyone else that you actually have verified someone else's email address or phone number. And to be honest, I'd prefer they'd spend their time polishing the actual chat UX instead of a feature most users won't even use (let alone redesigning it to provide guarantees that only a handful of users claim to care about).

I hate identity servers with a passion and wish we'd never created them in Matrix (and instead added an alternative later - e.g. per-room identity attestations), given the confusion and illfounded drama they cause. So frustrating.

For context, the identity service optionally maps email addresses and phone numbers to Matrix IDs. It is not an essential part of most Matrix workflows, and does not affect the protocol's fundamental decentralization. To wit, in several years of using Matrix -- personally, at Mozilla, and very recently as an Element employee -- I've not once interacted with the identity service.

It is very important for some workflows, and we certainly need to do work to meet your concerns, but it seems a bit much to call "bullshit" on the entire project for this particular optional case.

I see the only use of 3PIDs in a professional setting where people have to find co-workers using emails or internal phone numbers.

In my opinion, it is really useless for anyone else.

I've never used the feature on Matrix because as you say, it doesn't really apply. Matrix (or really Element here) doesn't require you to use an identity server at all, so I don't really think it invalidates the protocol in a meaningful way.

There actually has been work done on it, partially by me.

Unfortunately it's simply an unsolved problem to properly federate the 3pid mappings. The long and short of it is that you need to find some way to prove to other identity servers that you properly verified a 3pid. That's theoretically possible with e-mail and DKIM, except there are too many e-mail servers that don't implement it correctly.

For phone numbers it's even worse.

[edit] I forgot: There is a working implementation of federated identity servers for e-mail, but that requires you to run an identity server on the domain of the e-mail address that you're trying to add as 3pid. That means it works fine if you host your own e-mail but it doesn't work for the gmails and hotmails of this world.

You know that the identity server is not mandatory and is only useful in a professional setting right?

If you really want to, you can host it yourself.

without one clients will not be able to look up user IDs using 3PIDs, so its relatively important. hosting it yourself means having to email or message "us" in order to federate it.

So don't use a 3PID to add someone, use their MXID. It's a unique, global identifier and is similar enough to an email address.

There's also a Matrix URI specification in the works (https://github.com/matrix-org/matrix-doc/pull/2312). Once that lands, we should start seeing support for Matrix URIs in applications. This will allow applications to also start recognising MXIDs and converting them into working links, which will in turn help with people's recognition of the MXID.

I've been using Matrix for three years I believe and I can't remember a single time when I needed to use 3PIDs.

does matrix store anything in the server or is this really p2p? can this be a good replacement for say, telegram?

> Bullshit

That's quite a harsh statement.

Are you saying that just because there's a centralised optional service for mapping Matrix IDs to phone numbers means that Matrix itself is centralised?

does a client such element store anything in a server or it's really P2P?

Matrix isn't peer-to-peer, it's federated. Messages are stored on "homeservers", which is similar in concept to an email server except it's much easier to host your own Matrix homeserver. Only the homeservers which have involved in a chatroom ever see a copy of the message. For private chatrooms, everything is E2E encrypted by default so the homeservers don't have access to the plaintext of your messages.

Current implementation uses a server, though you can fairly easily host your own, or find another server to your liking.

There is significant work being done to get matrix working p2p too, though. There is a demo of it, but it's not production ready. See https://p2p.riot.im/

It's (currently) not P2P, it's federated.

That's right. And the community replies with a smug "you can set it up yourself".

And yet setting a full Matrix stack requires days of work and endless maintenance.

I'd rather use Briar or even Signal.

> And yet setting a full Matrix stack requires days of work and endless maintenance.

This is not true. People, don't let this FUD scare you.

My home server has been running for more than a year, was easy to setup (reading documentation took the most time) and takes little maintenance. Just apt update && apt upgrade.

Edit: and even if reading the documentation takes you 'days of work', you can follow a video of the server being setup in 30 minutes, including a jitsi instance for video conferencing: https://matrix.org/blog/2020/04/06/running-your-own-secure-c...

The last time I looked into it - it required:

- buy a VM

- buy a domain

- configure DNS

- apt-get install

- fiddle with SSL certificates

- debug out a memory leak bug

- ask upstream and be told to use an unstable alpha release

- implement a workaround

- start investigating bridges for IRC, Slack, Telegram

- give up

In 2020 we should expect something like Briar:

- install Briar on your ws / phone. There is are no servers. Done.

Well you must have has a real bad experience. That's unfortunate indeed and I understand your frustration.

It is not representative though. You do need a server and a domain name, but that isn't out of place when hosting internet based services like a chat server.

The technology to run a low bandwidth protocol over onion services has been around for 10+ years.

That avoids most of the need for domain, DNS configuration, SSL and SSL certificates.

A centralized chat server e.g. IRC runs on a raspberry.

Briar, as I said, runs without servers and provides also blogs and forums.