Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Enable/document disabling federation by default on room creation #9230

Open
tadzik opened this issue Jan 26, 2021 · 2 comments
Open

Enable/document disabling federation by default on room creation #9230

tadzik opened this issue Jan 26, 2021 · 2 comments
Labels
P5 (OBSOLETE: use S- labels.) Dubious backlog: will not schedule, but may consider patches T-Other Questions, user support, anything else.

Comments

@tadzik
Copy link
Contributor

tadzik commented Jan 26, 2021

The background:

A common support request for Synapse (easy to observe on Matrix HQ), is users coming in asking how to disable the federation on their homeserver. This is often identified as an XY problem with alternative solutions being proposed, though these solutions usually boil down to evangelism explaining why you shouldn't do that. I do, however, believe, that there are valid usecases for a “walled off” Matrix server, and the current settings/docs fail to fill that niche, resulting in “disable the federation” being the most attractive option.

The problem:

Say you have a Matrix server where you really don't want any conversations to leak out to other HSes, including the metadata (so e2ee doesn't currently solve this problem). What are your options?

You could make sure that each time you create a room (in Element), you remember to click the Advanced button and check the “Block users on other matrix homeservers from joining this room” option. Even if you remember to do it every time, and educate your users to do the same, expecting them (and yourself) to actually remember to do that each time is optimistic at least, and horrible security at worst. Understandably not acceptable for some.

The only other (seemingly?) available option is disabling federation globally in the Synapse config. Easy to do and foolproof, so no wonder people opt for it. It's something we'd rather avoid though, since a completely walled of Matrix server is kind of missing the point of it all :)

So to have the cake and eat it too:

The solution?:

Provide a way to make rooms non-federated by default, configurable as easily (or easier) than disabling federation is now. Document its behaviour (and the difference between that option and disabling federation completely), so that users looking for extra security are less tempted to go for the nuclear option.

In practice, setting that option would set you up with a homeserver that can communicate with others, but no one's allowed to join the rooms created on that homeserver – making you, essentially, a “leech” on the broader Matrix ecosystem. This may be seen as a downside, but since the only (seemingly?) current solution is cutting your ties entirely, it does seem like a preferable outcome anyway.

@anoadragon453 anoadragon453 added T-Other Questions, user support, anything else. X-Needs-Discussion labels Jan 26, 2021
@aperezdc
Copy link
Contributor

aperezdc commented Feb 3, 2021

There was an earlier attempt at implementing something like this in PR #2199 (plus matrix-org/matrix-react-sdk#868 and element-hq/element-web#3849 for the user interface part), so one option could be to bring those PRs up to date and continue from there 🤔

@callahad
Copy link
Contributor

callahad commented Feb 3, 2021

One challenge is that rooms cannot transition from unfederated to federated after creation, so there are some significant UX challenges around this feature. Including coordinating with how clients would present the option.

We'd be happy to consider pull requests, but suspect this may turn into a bit of a deceptively thorny issue.

@callahad callahad added P5 (OBSOLETE: use S- labels.) Dubious backlog: will not schedule, but may consider patches and removed X-Needs-Discussion labels Feb 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P5 (OBSOLETE: use S- labels.) Dubious backlog: will not schedule, but may consider patches T-Other Questions, user support, anything else.
Projects
None yet
Development

No branches or pull requests

4 participants