You might want to consider Matrix, where admittedly we do have phone-home stats, but you have to explicitly opt in to them during installation if you want to participate. (https://youtu.be/dDddKmdLEdg?t=605 in the video in the original post here)
If you use the Matrix identity server, which is required to have federation, the 3rd party identity server operated by the Matrix organization retains a list of your usernames. They don't tell you up front about this, either, and I think silently leaking a username list is pretty bad. You have to really pay attention during setup to realize that the federation technology relies on a bastion operated by matrix.org.
The identity server is optional and you can use your own, but you will lose the federation that Matrix is so proud of, and the instructions to set up the reference home server don't make it clear that this is necessary in order to avoid a leak of your users' identities.
> 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).
> 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.
I'd like to see this idea implemented at compile time. Don't opt-in and the code that does it doesn't even exist in the binary. That way there's no worry a logical error in the code could accidentally ignore the choice.
