Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIPish] MSC1777: peeking over federation (via server pseudousers) #1777

Closed
wants to merge 5 commits into from

Conversation

ara4n
Copy link
Member

@ara4n ara4n commented Jan 6, 2019

@ara4n ara4n added the proposal A matrix spec change proposal label Jan 6, 2019
@ara4n ara4n mentioned this pull request Jan 6, 2019
proposals/1777-peeking-over-federation.md Outdated Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're bumping the room version, might as well enforce the user being effectively read-only at the same time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 anoadragon453 added proposal A matrix spec change proposal and removed proposal A matrix spec change proposal labels Jan 8, 2019
`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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Contributor

@Half-Shot Half-Shot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks largely fine and elegant aside from one edge case I'm concerned about 👍

Co-Authored-By: Travis Ralston <travpc@gmail.com>
@Half-Shot
Copy link
Contributor

Is this going to get looked into soon, quite a few things are blocked behind this feature?

@ara4n
Copy link
Member Author

ara4n commented Oct 19, 2019

So we did a deep dive into this last week, and conclusions were:

  • Having to join a user into a room in order to peek into it means writing to the DAG. Giving peeking is a read-only operation, it seems wrong to make peeking a write operation - forcing the peeking server to have to start federating with all the other servers participating in the room (discovering their signing keys; sending them the data; etc).
  • Instead, we should have a native federation API for peeking, which lets a given server subscribe to events in a given room without actually joining it. The peeking server could subscribe to as many servers participating in the room as it likes.
  • There was talk over whether this peeking API should look like the CS API /sync API (i.e. a long-polling API, so you wouldn't have to explicitly subscribe/unsubscribe) or whether it should be a push-based API (which would be consistent with the other SS APIs, but have additional fiddliness to track subscriptions).

The conversation was left with needing someone to propose a concrete API for it (and then rewrite this MSC).

@ara4n ara4n added the obsolete A proposal which has been overtaken by other proposals label Feb 24, 2020
@ara4n
Copy link
Member Author

ara4n commented Feb 24, 2020

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 ara4n changed the title [WIPish] MSC1777: peeking over federation [WIPish] MSC1777: peeking over federation (via server pseudousers) Feb 24, 2020
@turt2live turt2live added kind:feature MSC for not-core and not-maintenance stuff kind:core MSC which is critical to the protocol's success and removed kind:feature MSC for not-core and not-maintenance stuff labels Apr 20, 2020
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@turt2live
Copy link
Member

This MSC is obsoleted in favour of #2444 per above.

@turt2live turt2live closed this Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:core MSC which is critical to the protocol's success obsolete A proposal which has been overtaken by other proposals proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants