| Fwiw, this is pretty much entirely untrue. > Matrix identity server, which is required to have federation, The identity server is not required to have federation to work. All it does is let you optionally discover users on Matrix by their email address or phone number. > 3rd party identity server operated by the Matrix organization retains a list of your usernames. Not sure what this means, but the identity service does not retain a "list of your usernames". All it does is keep track of email->matrix ID mappings for users who have published them. When you look up an email address (or phone number), a hashed representation is sent to the service, and even then, they're not retained. > They don't tell you up front about this We do; to use the identity service you have to click through a very explicit GDPR terms of use which explains precisely how it works. You only get prompted with this when you actually use the identity service though (i.e. when inviting someone by email address) which might be why you've never seen it, however. > You have to really pay attention during setup to realize that the federation technology relies on a bastion operated by matrix.org. Again, Matrix federation does not depend on identity servers (and I kinda wish we'd never even implemented the feature, given how confused and upset people get about them). https://matrix.org/blog/2019/09/27/privacy-improvements-in-s... goes into this all in much more detail. |
> All it does is keep track of email->matrix ID mappings for users who have published them
This is what I mean by "it leaks the userlist." Matrix (the organization) stores the email addresses of my users, along with some mapping that could allow Matrix the organization to correlate email addresses with my server. To me, as a server operator, this is a deal-breaker, even if it was just email addresses with no mapping. I see this as a privacy violation against my users who trust me to hold their information privately and securely. My understanding is that you cannot join another Matrix homeserver server with an identity established on a homeserver disconnected from the vector.im identity server, which effectively forces the homeserver operator to use the vector.im centralized identity server if you want, as an end user, to actually take advantage of federation. I do not know how a user is supposed to take their login from one homeserver to log into another one if the first homeserver is not connected to vector.im.
Please correct me if the above is wrong.
Additionally, when I set up Synapse I was not presented with any kind of GDPR info, and it wouldn't make sense that I would be, because the GPDR is for end users, not site operators. Maybe this is presented to new users who connect to the public reference Synapse instance using Riot.im or something, but I'm not talking about this issue from the perspective of an end user, I'm talking about it from the perspective of a homeserver operator. I got about halfway through the homeserver setup before I realized that vector.im was necessary for identity lookup and I realized it only by carefully following the docs. This was long before the 9/27/2019 blog post was published, so I guess maybe this has been addressed somewhat. I have been following Matrix now for the better part of a decade.
If federation is possible without identity mapping done on a central server, then I too wish that identity mapping was never implemented.