-
Notifications
You must be signed in to change notification settings - Fork 383
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
WIP: MSC3588: Encrypted Stories As Rooms #3588
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,107 @@ | ||
# MSC3588: Stories As Rooms | ||
|
||
Stories are a feature mostly known from Instagram, WhatsApp, Facebook and SnapChat. They are a way to share text, images or videos with all of your friends at once while they have a limited lifetime of mostly 24 hours. In contrast to microblogging, stories are ephemeral and therefore users are motivated to speek freely. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please wrap your lines |
||
|
||
We have some requirements for this feature here: | ||
|
||
* Posts in a story should disappear after a certain lifetime | ||
* The user should be able to configure who can see their story | ||
* The user should be able to opt-out of receiving stories from specific users (without the need to fully ignore such users) | ||
* Posts in a story should be end-to-end encrypted (and therefore not be public) | ||
* Stories are **not** public. Users need to have some kind of relationship to see the each others stories | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From a user perspective, I actually would like to have the ability to have it shared to anyone who knows me. Though that is likely pretty impossible without profiles as rooms to have some kind of "hey, here is the user's story". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would be a different use case I think. These stories are very private and always e2ee. So it would make sense to only allow people to invite to the story room the user shares a DM room with in the GUI. Also e2ee rooms shouldn't be too large. I would say around 50 followers are a good limit. For what you say it sounds more like a "public story" like on Instagram. This could be solved in a follow-up MSC. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like that you have to invite people. I think this is obtrusive... Perhaps something like a user hava a own stories spaces and there the new story rooms are added without noticing the user. (I suppose for this many things have to be changed...) |
||
|
||
To have a channel where a user can broadcast messages to everyone who wants to follow them, it would be obvious to use the Profiles As Rooms feature. Unfortunately this doesn't seem to have much progress in the last months. Also Profiles As Rooms may be public rooms while we want to have private and encrypted rooms for this. So while Room Profiles may fit perfect for microblogging, we need another room for our stories. | ||
|
||
The solution in this document works fully client side and requires no changes on the server. It is intended to be an optional feature for Matrix clients who would like to implement this feature, while it stays compatible with all other clients as well. Stories rooms will just be displayed as normal read-only rooms for them. | ||
|
||
|
||
## Proposal | ||
|
||
The solution in this document works fully client side and requires no changes on the server. It is intended to be an optional feature for Matrix clients who would like to implement this feature, while it stays compatible with all other clients as well. Stories rooms will just be displayed as normal read-only rooms for them. | ||
|
||
### Stories Room | ||
|
||
Before a user posts their first story, they need to create a story room. This room should be marked with a creation type of `msc3588.stories.stories-room`. The stories room should not be created before the user actually wants to post their first story. | ||
|
||
The room should be private, encrypted and read only for all other users. While creating this room, the user should already invite all "contacts" they would like to share their story with. Apps should display a list of possible contacts to choose, which could be just a list of all users, the user shares a DM room with. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The limitation of already sharing a DM/private room with the user should be enforced by the protocol, I think. At least until we have contact lists and we can enforce it properly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wait, why ? why should i not be able to invite people i don't have marked as dms with ? |
||
|
||
If a user has less than 30 DM rooms, it should be fine that the client just preselects all of them but the user must be informed that they is going to invite those 30 people to a new room and that these people will be able to see each other's MXID which might not be wanted. All contacts which should **not** be invited to the room, should be added to a block list in a private account data object. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why have an additional Blocklist if the room is already invite only? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need this to know which contacts we do not want to have in the room for the moment. Every time we create a new story, the GUI should display a list of users we might want to invite which are {Users we share a DM room with} - {Users already follow the story} - {Users in the block list}. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I understand correctly, users are only added to the blocklist when the story sender doesn't want to include them in the story. Is there a mechanism in place for when story recipient doesn't want to receive stories? In particular, I'm imagining a scenario where one friend adds another friend each time they send a story, but the second friend keeps declining the invite. I think this is definitely plausible, if the sending friend doesn't remember adding the second friend the first time, or doesn't understand that them showing up in the invite list again means they've declined. Maybe the user shouldn't be prompted to invite people with m.leave memberships unless they knock again? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I already ran into this with the test implementation. Currently it looks like this:
|
||
|
||
#### Example of the /createRoom payload: | ||
|
||
```json | ||
{ | ||
"creation_content": { | ||
"type": "msc3588.stories.stories-room" | ||
}, | ||
"preset": "private_chat", | ||
"power_level_content_over": { | ||
"events_default": 100 | ||
}, | ||
"initial_state": [ | ||
{ | ||
"type": "m.room.encryption", | ||
"state_key": "", | ||
"content": { | ||
"algorithm": "m.megolm.v1.aes-sha2" | ||
} | ||
} | ||
], | ||
"invite": [ | ||
"@alice:example.com", | ||
"@bob:example.com" | ||
] | ||
} | ||
``` | ||
|
||
#### Example of the block list account data object: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, is it possible to use the existing blocklist format that also mjolnir uses (If my other blocklist question comes to the resolution of "yes, we really need it")? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe the wording blocklist is not perfect here. It has nothing to do with ban. It is just a "Not-invite-list". |
||
|
||
```json | ||
{ | ||
"type": "msc3588.stories.block-list", | ||
"content": { | ||
"users": [ | ||
"@charley:example.com" | ||
] | ||
} | ||
} | ||
``` | ||
|
||
Clients should display such rooms in a different manner. Every user should have only one stories room but can in theory have multiple of them. The user must never give admin permissions to another person and should be aware, that all users in this room in theory can see each other's MXID. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would say that multiple story rooms should be the expected state. I may want to share different stories with different people so I would need a room for each set. |
||
|
||
After creation, users might want to be able to invite or kick other users to their stories room. Clients should offer a UI for it. Every time the user posts a new story, the client should check if there are new contacts (users the user shares a DM room with and who are not on the block list). If there are, the UI should display another list view where the user can decide if they want to invite these contacts to the stories room **before** the new story is posted, or if they want to add some or all of the new contacts to the block list. | ||
|
||
In this way, we make sure that every invitation to a new stories room actually contains at least one new post. | ||
|
||
Invitations to a new story room could be displayed as a normal new story in the UI while there should be a way to decline such an invitation, for example with a long press context menu. | ||
|
||
A post in a story room can then just be a normal `m.room.message` event of any message type, which then would be end-to-end encrypted. | ||
|
||
## Potential issues | ||
|
||
All posts in a story should disappear after 24 hours. In the future it might be easy to implement this using "Self destructive messages" <https://github.com/matrix-org/matrix-doc/pull/2228> but at the moment the only ways we can do this are using both, `m.room.retention` and managing this on both sides: | ||
|
||
* Sending clients should be configured to automatically redact all messages in stories rooms, which are older than 24 hours | ||
* Receiving clients should ignore messages in stories rooms, which are older than 24 hours | ||
|
||
Therefore, it **will** be possible that stories are visible after 24 hours if one or both parts are not following these rules. However, it will always be possible to capture screenshots or to copy contents before they get redacted, regardless of what we try to prevent this. The automatic disappearing of stories is **not** a privacy feature. It just assumes that stories, older than a specific amount of time, are no longer relevant to the users. | ||
|
||
|
||
## Alternatives | ||
|
||
Profiles as rooms can be used to post content to a wider audiance. | ||
|
||
|
||
## Security considerations | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Probably worth adding that matrix does not protect against downloading media, and also it may at the end not be gone from the media repo (aka if you know the link you still can access it) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good idea :-) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
The GUI should make clear who can see the stories and should inform the user that all subscribers can potentially see each others Matrix IDs. | ||
|
||
## Unstable prefix | ||
|
||
`msc3588.stories.stories-room` | ||
|
||
`msc3588.stories.block-list` | ||
|
||
## Dependencies | ||
|
||
None. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(reply to @tezlm)
This probably can be solved using a sync filter if someone makes filters by room types possible. Likely this is already part of sliding sync. I would personally consider this a non-issue.
Also, this data doesn't randomly land in your account. You have to join the room. So I am not sure what your concern here is? If a user doesn't want it, he should just not join the room.
I believe this up to the client devs to decide if they implement it or not. I don't think it causes feature creep therefor.
Also, @tezlm please use threads. It is part of the spec progress and based on other MSCs you can clearly see that non thread comments are just ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and how would I opt out of getting story room invites altogether?
I didn't realize this existed, but it sounds very nice.
My comment doesn't apply to only this specific pr, but I chose to comment on this because it could have the most visible impact on people. A few of my friends and I were confused what stories were at first, and in the end it seems like it was client incompatibility - stories were just shown as and mixed into normal rooms, with not much information as to what they were for.
The main thing I'm worried about is the client devs deciding not to implement something. Matrix clients would end up like web browsers - only a few support every feature, and whenever someone uses a client that doesnt support certain features, their friends/family/peers tell them to switch to one that supports said feature.
Looking back at it now, this pr was probably not the best br to leave my comment on (eg. threads/polls would have even more of this problem) but I'll go with it for now.
Sorry, didn't realize they were a thing.