Generic pubsub over Matrix - room participant privacy?

[jfrederickson]

I was thinking about using Matrix as a generic pubsub mechanism, and I realized that the only required change would be the ability for rooms to not publish their participants in the room state. After doing so, users could "subscribe" to such a room by simply joining it.

So for example, users of an RSS-like application over Matrix could join a room for each blog, and their reader would receive updates as new posts are made and published to any of those Matrix rooms.

I haven't yet thought about what this would actually look like in the spec in much detail, but what do you guys think?

[t3chguy]

how would it work in regards to federation and access control?

[jfrederickson]

Yeah, that's tricky - for a server to know who's allowed to change room state, it has to know which users have which power levels... hmm.

In the case of a room with hidden participants, would it make sense to have an "unknown users" option in the room permissions? So for example:

"Unknown users have power level: <dropdown, default=-1>"

-1 seems like a sane default here for spam reasons; you can't proactively ban people if you don't know where they're coming from. But essentially, most users in the room would be hidden, but you'd be able to see users with higher power levels so homeservers can handle permissions properly.

[NotAFile]

Is this not implemented yet with the "guests" feature? I guess that's pull though, not push.

[jfrederickson]

Guests are treated as normal users - while it's possible to join a room as a guest, all those users are still visible in the room. This suggestion is sort of the opposite, i.e. you could join the room with your normal user account, just most users in the room wouldn't be visible.

[t3chguy]

So peeking
But it doesn't work over federation
And then there's no access control

[NotAFile]

Well, I think it's fine to not have access control for many of the use cases. The question is rather how the hs can push updates to other hs if it doesn't know who is subscribing.

[non-Jedi]

#119 is related I think. Also https://github.com/matrix-org/matrix-doc/issues/597 when combined with peeking.

[turt2live]

also related (if implemented at the spec level): https://github.com/vector-im/riot-web/issues/6417

[vibl]

This feature has been mentioned in several issues and discussions:

• Ability to hide users below a given power level in the membership list #367
• support broadcast rooms which let you configure the audience to be hidden in the memberlist element-hq/element-meta#490
• Add Semi-Anonymous Rooms (SPEC-260) #119

It seems to interest quite a few people, according to the "thumbs up" on these threads.

Is there any way it could be included in the roadmap?

FWIW, it's implemented in Rocket.Chat (they call it "broadcast channels"): https://docs.rocket.chat/guides/user-guides/rooms/channels/create-a-new-channel

[shukon]

Couldn't the federation be handled in a way that all users allowed to write in the channel (e.g. mods / admins / whatever bot is used for pubsub) share the room over federation with a full membership list (to know where to send the messages)?
All other users cannot send events, but simply read them and therefore don't need the membership list. There is no need to send the membership-list to participating servers with only read-only participants and no need to send it to the clients of read-only participants.
The easiest way might be to send a truncated membership-list to read-only participants with only the mods/admins (those with the full room state) and themselves. Whenever a read-only participant is promoted, they can be filled in with the rest of the room state.

[MurzNN]

We already have a guest access feature to rooms in Matrix, maybe we can just use this feature to make such rooms? So, we can view the contents of a public room anonymously, like in view.matrix.org - https://view.matrix.org/room/!OGEhHVWSdvArJzumhm:matrix.org/ and even via Element - https://app.element.io/#/room/#matrix:matrix.org

So, all that we need is to "pin" this guest room to the list of rooms on the client side (via storing it in User Data, maybe even encrypted), and periodically "ping" the room for updates. What do you think about this idea?

[t3chguy]

@MurzNN that's matrix-org/matrix-spec-proposals#2753 - though keep in mind peeking (like view.matrix.org does) cannot be used for the pub part of pubsub