[WIPish] MSC1777: peeking over federation (via server pseudousers) #1777
Conversation
| to, the server should attempt to join the room using a pseudouser account which | ||
| represents the server itself. | ||
|
|
||
| This allows the server to participate in the room and peek the data being |
There was a problem hiding this comment.
Should the special user be allowed to post anything in the room? Because they'd be joined and hidden from the memberlist, it opens up a vector for abuse which is difficult to mitigate. Enforcing that the special case user is read only (with the exception of join and leave explicitly) would prevent most forms of abuse.
|
|
||
| This replaces the `world_readable` setting on `m.room.history_visibility`. | ||
|
|
||
| XXX: Presumably this requires a room version upgrade. |
There was a problem hiding this comment.
Most definitely. It might be worth the extra effort to split out this particular change into a dedicated proposal so it can make it in to v2, leaving the specifics of how peeking work to this proposal. Only real reason would be we're cutting rooms v2 at the end of the month, and it'd be a bit annoying to have a v3 very shortly after (particularly if the change is just peeking - that's not a lot of motivation to update rooms, particularly when compared to v2's changelog).
| which could be a DoS vector. If a user creates a peekable room, and invites a | ||
| remote user in, it's now possible for that server to join via their pseudouser | ||
| in order to (say) participate in E2E... even if the user themselves hasn't | ||
| acted on the invitation. Care must be taken in being lured into peekable rooms. |
There was a problem hiding this comment.
If we're bumping the room version, might as well enforce the user being effectively read-only at the same time.
There was a problem hiding this comment.
I assume this would break Pseudousers could potentially also act on behalf of ASes since that would requite the user to write into the room?
anoadragon453
added
proposal
| `m.room.join_rules` is extended with a new type: `peekable`, which describes | ||
| public-joinable rooms which may also be joined by `@:server` pseudousers. | ||
| Otherwise, server pseudousers must not be allowed to join the room, unless a | ||
| user from that server has already joined or been invited. |
There was a problem hiding this comment.
What happens to pseudousers if the join_rules become more restrictive after they have joined it. Does it work like current room semantics and keeps them joined, keeping the room peekable for servers who have peeked it once already?
(i.e I can see the situation where lots of servers peek your room, you downgrade from peekable and are surprised to learn it doesn't help you.)
Co-Authored-By: Travis Ralston <travpc@gmail.com>
|
Is this going to get looked into soon, quite a few things are blocked behind this feature? |
|
So we did a deep dive into this last week, and conclusions were:
The conversation was left with needing someone to propose a concrete API for it (and then rewrite this MSC). |
I've just tried to do this in #2444. This one should now be considered for historical value only. |
ara4n
changed the title
turt2live
added
kind:feature
| However, clients may choose to show the existence of the member in advanced | ||
| details about a given room. | ||
|
|
||
| `m.room.join_rules` is extended with a new type: `peekable`, which describes |
There was a problem hiding this comment.
How does this work with other join_rules? What if you want knock but not peak? But the other way round? What if you want to be able to peak some things in a private room? etc.
It feels like it might be time to make the join_rules contain a set of features instead?
|
This MSC is obsoleted in favour of #2444 per above. |
Rendered