Fix violation of privacy

[MTRNord]

This is not only not really obvious to newcomers imho but also is a horrible default. It not only violates the privacy but also can easily leak information to the public.

Also it seems like a bad idea to change defaults as a middleman for a repo that itself wants to be used as a generalized server deployment tool.

[TheArcaneBrony]

+1, especially from the viewpoint of upstream disabling this by default for user safety.

[spantaleev]

Setting up a Matrix server and making it federated.. Creating public rooms.. Allowing any Matrix server to join said rooms directly, without any access control.. Publishing these rooms to the "Room Directory".. And then complaining about the very minor part that "other Matrix servers can find my public rooms" seems like a minor problem.

Matrix is a federated network. You have many ways to keep your rooms private:

• disable federation and run a fully private server
• or.. stop creating public rooms
• or.. should you create public rooms, prevent them from being joinable over federation (there's the m.federate /createRoom option and a nice UI for doing this)
• or.. should you ignore all of the above, at least avoid publishing said public rooms to the Rooms Directory

You're deciding to ignore all these options and are making your rooms fully public and federateable.. Then you're complaining that other Matrix servers can discover your rooms.

It doesn't make any sense to have Matrix be a federated network, but not-quite-federating. I don't think it's a violation of privacy to expose the list of public rooms for servers that are fully federating and that allow said rooms to be freely joined by anyone. You have all of the above options, including changing playbook defaults which are well-announced in the CHANGELOG and in the Matrix room for the playbook.

Next, people may complain that this playbook turns on Federation by default and may wish that we change matrix_synapse_federation_enabled to false. You're joining a federated network and the defaults match that - your public rooms are federated across the network.

There seems to be a vocal minority of possibly 3 users (out of thousands) who are complaining about this. You have options and are free to exercise them. I don't see a reason why we should all collectively continue to cripple Matrix federation and room discovery because a few users are unhappy with these defaults.

---

The playbook, as all installation tools (and software distributions) is opinionated in various ways. While, this playbook tends to stick to upstream defaults in most cases, this is not a guarantee.

Just like various Linux distributions are free to package (and patch and adjust) software as they see fit, so do we. If this is to be compared to a Linux distribution, it would probably be closest to Arch Linux in that:

• it tries to educate people in its huge documentation, so that they know how things work (to a reasonable extent)
• it tries to stick to upstream defaults, but.. may patch this or that when it makes sense to do it. I'm actually hoping that the Matrix-federation-regression introduced in Synapse v1.7.0 will be reverted upstream and we won't be deviating anymore. Perhaps this change (and its announcement in TWIM) will provoke discussion and progress around this.

[real-joshua]

Also it seems like a bad idea to change defaults as a middleman for a repo that itself wants to be used as a generalized server deployment tool.

Important point, I'd expect this to be as secure and safe as the default. :D

[derhagen]

I agree, with @spantaleev insofar as making a publicly joinable room non-discoverable, while still allowing everyone that knows the room handle to join, is pretty much worthless from a security perspective, maybe even contributes to make a security concern less visible.

What I'm personally missing is a middle ground between

• 'prevent them from being joinable over federation' as in 'Block anyone not part of <your-server> from ever joining this room.'
• and a publicly joinable room

as in 'open for your organization, invite-only via federation'. My solution is a private space for my organization where new server users are auto-joined, and a bunch of rooms that are discoverable and joinable for everyone inside that space. However, such a server-wide default space needs to be hard-coded by the server admin.

The Element UI could certainly present the options in a more fine-grained manner by adding an Access Option and renaming one:

• Private (invite-only)
• Space members
• Open to your server (globally invite-only) [new]
• [Globally] Public

Any idea whether this requires a spec change, or would just be a feature request to Element? Any thoughts on my idea?

[hanthor]

This is a UX issue for Synapse+Element. An current solution is to make "public-for-only-my-server" rooms would be to make them joinable by members of a space and then make that space an auto-join room for new users.

[github-actions]

This PR is stale because it has not been provided with required information or its conflicts have not been fixed over a year. Remove stale label or this will be closed in 30 days. To exempt the PR from being marked as stale again due to inactivity, add "confirmed" label.