> 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.
> 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
This is not true. The identity server is an optional feature, which users can use if they want to try to discover a user's matrix ID based on their email address. Matrix itself operates using matrix IDs to federate and establish conversations.
A good analogy is using LDAP as an address book in an email client. LDAP addressbook lookups are very clearly optional, not relevant to all people, and don't stop email itself working.
> 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.
Because the identity server is an optional feature for users (just like a user, not a sysadmin, would configure LDAP lookups in Thunderbird), the GDPR terms of use are shown to users if they try to use an identity server to make sure they understand what they're doing.
Well then I'm glad that the blog post linked above was written, because obviously this situation was confusing when I set up Synapse a couple years back. I might not be a genius but I'm not stupid, either, and I'm obsessed with chat systems (I trialed every available self-hostable chat server at the time), so I guarantee if this confused me, it confused plenty of perfectly intelligent individuals.
I hope the team has clarified this in the documentation.
> 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.