MSC4358: Out of room server discovery #4358
Conversation
Gnuxie
changed the title
| ### OPRF key in the create event | ||
|
|
||
| An OPRF[^oprf] key could be placed into the create event which is used | ||
| instead via `OPRF(room_key, server_name)`. However, it's unclear | ||
| if there are any situations where the `room_id` is known and not | ||
| the create event. | ||
|
|
||
| [^oprf]: https://datatracker.ietf.org/doc/rfc9497/ |
There was a problem hiding this comment.
Technically people sometimes share a link to a private room in a public room to share context with some people who are in both rooms (but not all people are in both of them)
| ### OPRF key in the create event | ||
|
|
||
| An OPRF[^oprf] key could be placed into the create event which is used | ||
| instead via `OPRF(room_key, server_name)`. However, it's unclear | ||
| if there are any situations where the `room_id` is known and not | ||
| the create event. | ||
|
|
||
| [^oprf]: https://datatracker.ietf.org/doc/rfc9497/ | ||
|
|
There was a problem hiding this comment.
You should mention explicitly that the information used in the tag has to be intrinsic to the room. So that the room creators can't erase it or misrepresent it in any possible branch of the room.
|
It appears this MSC is still a work in progress (or at least, doesn't explain how/when to use the new functionality), so I'm converting it to a draft instead of listing implementation requirements. |
turt2live
added
proposal
| ### Not clear when it is appropriate to query common rooms | ||
|
|
||
| How often should rooms check for unexpected results? | ||
|
|
||
| When joining a new room is a good start. But how frequently otherwise? |
There was a problem hiding this comment.
If epochs were going to be considered, then would be a good time too. It's not clear which servers you would select to try pry information...
| - The `recognised_tags` are any of the queried tags which the | ||
| requested server acknowledges. This property is an array of strings. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
The protocol doesn't scale and requires more data for more rooms. So a passive scan doesn't really work for a large homeserver.
There was a problem hiding this comment.
The way to make a passive mechanism that does scale is to incrementally collect tags from other servers and store them. And possibly even allow them to be passed on, but this does mean just storing random noise in most cases.
|
|
||
| [^oprf]: https://datatracker.ietf.org/doc/rfc9497/ | ||
|
|
||
| ## Security considerations |
There was a problem hiding this comment.
This proposal would allow HS1 to check whether HS2 is participating in a room, so long as HS1 knows HS2's server name and the room ID they want to check for. (The only benefit hash(server_name, room_id) brings is that HS1 needs to know the room IDs they want to check for ahead of time.) Thus, this proposal can leak an HS's participation in a room to HSs not participating in said room, which is not great.
Rendered
Signed-off-by: Gnuxie [email protected]