element-hq / element-hq/synapse
peeking doesn't work over federation
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 600
- Avg merge
- 5d 22h
- Merged PRs (30d)
- 51
Description
This issue has been migrated from [#4236](https://github.com/matrix-org/synapse/issues/4236).
---
The specification states in [13.12](https://matrix.org/docs/spec/client_server/unstable.html#room-history-visibility)
> In all cases *except* `world_readable`, a user needs to join a room to view events in that room.
It goes on to say:
> ` world_readable` - All events while this is the m.room.history_visibility value may be shared by any participating homeserver with anyone, **regardless of whether they have ever joined the room**.
#### Exhibited Behavior
Synapse denies `world_readable` information by imposing a condition which checks if the requesting server has at least one user joined to the room. It responds with the error:
```
403 Forbidden
{"errcode":"M_FORBIDDEN","error":"Host not in room."}
```
This is not `world_readable` as specified. This check occurs on all relevant federation endpoints, making it impossible to access information about a room without joining at least one user. This exhibits a `shared` rather than `world_readable` visibility.
#### Proper Behavior
Synapse should not care whether a requesting server is joined to a room when it attempts to elicit information for events covered by a `world_readable` visibility state.
### Conclusion
As the **reference implementation** for the specification, this is a problem. Either this is an implementation error by synapse or this is an omission by the written specification. Should server implementations follow suit with synapse *de facto* or should they follow the specification *de jure* in contrast with it?
Furthermore, if this condition was implemented to mitigate a security vulnerability, spam or DoS vector, or even a performance problem: other implementations will surely fall victim to it, and the specification should not blindly lead them into doing so. In contrast, if a server developer believes the preceding statement *might* be true because this discrepancy merely exists, when it is not true, they will degrade the functionality of their server for no reason.
Contributor guide
Research direction
Start with Matrix specification section 13.12 and trace Synapse's federation endpoints that enforce the “Host not in room” check. Reproduce the reported 403 for a world_readable room when the requesting server has no joined user, then verify that peeking and event retrieval succeed without a joined user while other visibility states retain their restrictions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- distributed-systems, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100