-
-
Notifications
You must be signed in to change notification settings - Fork 103
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
Generic pubsub over Matrix - room participant privacy? #249
Comments
how would it work in regards to federation and access control? |
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. |
Is this not implemented yet with the "guests" feature? I guess that's pull though, not push. |
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. |
So peeking |
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. |
#119 is related I think. Also https://github.com/matrix-org/matrix-doc/issues/597 when combined with peeking. |
also related (if implemented at the spec level): https://github.com/vector-im/riot-web/issues/6417 |
This feature has been mentioned in several issues and discussions:
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 |
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)? |
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? |
@MurzNN that's matrix-org/matrix-spec-proposals#2753 - though keep in mind peeking (like view.matrix.org does) cannot be used for the |
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?
The text was updated successfully, but these errors were encountered: