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

WIP: MSC3588: Encrypted Stories As Rooms #3588

Closed
wants to merge 4 commits into from
Closed

WIP: MSC3588: Encrypted Stories As Rooms #3588

wants to merge 4 commits into from

Conversation

krille-chan
Copy link

Rendered

Signed-off-by: Christian Pauly [email protected]


## 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 way we can do this, is to manage this on both sides:
Copy link
Contributor

@Cadair Cadair Dec 23, 2021

Choose a reason for hiding this comment

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

An alternative idea, would be to have a single "stories space" per user, where you can invite your contacts, and your contacts can join or leave to opt out of access to your stories, and then you can make each new story as a new room in that space using restricted join rules for access control.

From my very brief thinking about it it would mean you could kick everyone from the room after 24hours to "expire" the story, and then you can use m.space.child events in the "story space" as a way for people to be notified about a new story and decide if they want to see that specific story.

Copy link
Author

Choose a reason for hiding this comment

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

Not sure. That would be huge overhead and needs a lot of time to join all the rooms. If I want to see the 20 Posts of a story from a user I need to join 20 rooms then?

Copy link
Contributor

Choose a reason for hiding this comment

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

From my very brief thinking about it it would mean you could kick everyone from the room after 24hours to "expire" the story

That doesn't really work because users can view the contents of rooms that they have left or been kicked from. (Historical rooms has been broken in Element for many years but it is part of Matrix)

Copy link
Member

@uhoreg uhoreg left a comment

Choose a reason for hiding this comment

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

Since this is marked as "WIP", I'm going to convert this to a draft PR. Feel free to switch it back to non-draft when you think it's ready.

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

Choose a reason for hiding this comment

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

Please wrap your lines

@uhoreg uhoreg marked this pull request as draft December 23, 2021 15:26
@uhoreg uhoreg added client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal labels Dec 23, 2021
* 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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".

Copy link
Author

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

The 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...
There has to be another way...

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...)
But when the user look in the space he see it and perhaps when you click on the user there is a stories tab.


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.

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

Choose a reason for hiding this comment

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

Why have an additional Blocklist if the room is already invite only?

Copy link
Author

Choose a reason for hiding this comment

The 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}.

}
```

#### Example of the block list account data object:
Copy link
Contributor

Choose a reason for hiding this comment

The 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")?

Copy link
Author

Choose a reason for hiding this comment

The 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".

Profiles as rooms can be used to post content to a wider audiance.


## Security considerations
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

Good idea :-)

Copy link
Contributor

Choose a reason for hiding this comment

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


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.

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.

Choose a reason for hiding this comment

The 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?

Copy link
Author

Choose a reason for hiding this comment

The 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:

  1. User A wants to publish a new story but has no story room yet
  2. Client creates a new story room and displays a list of contacts
  3. User A selects User B to invite
  4. User B declined the invitation
  5. User A wants to publish another story
  6. Client displays a list of contacts, which are not in the story room but also not in the blocklist, so only User B
  7. User A can select User B to try to invite them again or just not select them so User B comes to the blocklist as well
  8. In case of User A invites User B again, user B might contact User A with: "Eyy! I dont want to see your stupid story!! Stop inviting me over and over again!"
  9. In the other case, everything is fine

}
```

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

Choose a reason for hiding this comment

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


## 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 way we can do this, is to manage this on both sides:

This comment was marked as resolved.

@Mikaela

This comment has been minimized.

@MTRNord

This comment has been minimized.

@richvdh
Copy link
Member

richvdh commented Jan 17, 2022

folks, please remember:

  • be civil in your discussions. Take a deep breath before replying to a comment that makes you angry, and then explain politely why you disagree.
  • Use comments on the on the diff rather than the PR, so that related discussions are threaded together.

Since the last three comments have been made on the PR rather than the diff, I'm going to hide them.


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

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

The 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 ?

proposals/3588: mention m.room.retention
Mikaela added a commit to Mikaela/matrix-spec-proposals that referenced this pull request Feb 9, 2022
Mikaela added a commit to Mikaela/matrix-spec-proposals that referenced this pull request Feb 13, 2022
@tezlm
Copy link

tezlm commented Feb 22, 2022

Adding even more features seems like a great way to break client compatibility.

I get that other clients could simply not implement stories and have them show up as rooms, but there is no easy way to "opt out" of getting sent invites from people who use clients who support them.

I'm not against using matrix for non-instant messaging applications, but there is not really a good way to separate use cases currently. Even if different sets of required/optional/don't use MSCs were made for different use cases, syncing would result in extra garbage data for someone who doesn't want to see what amounts to a microblogging feature that belongs in a more social-media oriented app.

Maybe you don't want to have to use a separate app to look at people's stories. In that case, clients will slowly succumb to feature creep and code complexity, becoming more prone to bugs and harder to maintain. Plus extra ui that users have to deal with. And like the first sentence in this comment, people simply can't really ignore features without things breaking. (e2ee is supposedly optional for all clients according to the spec, but it really isnt due to how much stuff relies on encryption. Yeah, I know not supporting this pr won't break things as spectacularly, but it's simply the pr I chose to leave this comment on)

tl;dr: Matrix needs a better way to separate use cases before the number of added MSCs get out of hand.

@@ -0,0 +1,107 @@
# MSC3588: Stories As Rooms
Copy link
Contributor

Choose a reason for hiding this comment

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

(reply to @tezlm)

syncing would result in extra garbage data for someone who doesn't want to see what amounts to a microblogging feature that belongs in a more social-media oriented app.

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.

In that case, clients will slowly succumb to feature creep and code complexity, becoming more prone to bugs and harder to maintain.

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.

Copy link

Choose a reason for hiding this comment

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

If a user doesn't want it, he should just not join the room.

...and how would I opt out of getting story room invites altogether?

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.

I didn't realize this existed, but it sounds very nice.

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.

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.

please use threads.

Sorry, didn't realize they were a thing.

@krille-chan krille-chan changed the title WIP: MSC3588: Stories As Rooms WIP: MSC3588: Encrypted Stories As Rooms Aug 11, 2022
@krille-chan
Copy link
Author

This has been implemented in minesTrix and FluffyChat and will soon be part of the Matrix Dart SDK so we can remove the "needs implementation" label

@uhoreg
Copy link
Member

uhoreg commented Aug 11, 2022

Can you link to the implementations (preferably a PR or MR link) in the top comment of this PR so that someone can validate that the implementation matches the proposal? Also, this MSC is still marked as a WIP -- I don't know if it makes sense to drop the "needs implementation" label from something that is still a WIP and may change in the future. It may depend an what part of the MSC is still a WIP.

@krille-chan krille-chan closed this by deleting the head repository May 23, 2023
@turt2live turt2live added the abandoned A proposal where the author/shepherd is not responsive label May 23, 2023
@mewtrino
Copy link

Why is this marked as abandoned when two clients implement it?

@uhoreg
Copy link
Member

uhoreg commented Mar 12, 2024

Why is this marked as abandoned when two clients implement it?

The author has closed it. Anyone is free to re-propose it, but for now, nobody is doing the work to get it into the spec.

@vanyasem
Copy link

@mewtrino the support for stories has been removed from FluffyChat as of 1.17.0

Stories were replaced with presence status messages in this pull request: krille-chan/fluffychat#736

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned A proposal where the author/shepherd is not responsive client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.