MSC3302: Stories via To-Device-Messaging

[krille-chan]

rendered

[turt2live]

@ChristianPauly we'll need sign-off before this MSC is eligible for FCP. Easiest way to do this is to add the following to the PR description so it covers any future edits:

Signed-off-by: Your Name <email@example.org>

[Sorunome]

how about im.fluffychat.stories.* as unstable prefix? :3

[krille-chan]

I thought thats not allowed but would be nice. yes :)

[Sorunome]

yeah, any reverse-domain is allowed ^-^

[ara4n]

I am super confused about why you would use to-device msging for this. The building block for sharing conversations in Matrix is a room - so you then get all the infrastructure which comes with that, rather than inventing a new structure which looks mainly like a room but isn’t quite the same (eg the problem we had with Groups).

I assume the driver here is to avoid any serverside changes, and work around the fact that we don’t have federated peek in Synapse yet? (it exists in Dendrite using MSC2444). My instinct is very heavily that we should use this use case to push federated peeking and rooms-as-profiles asap, rather than complicating the spec with an entirely new concept for something which could be handled via rooms.

[ShadowJonathan]

An alternate solution would be to use room EDUs plus those profile rooms. I think it's to-device because then the user can somewhat control the outgoing content (as to whom it'd be going, and honestly, i think a friends/contacts system would be almost a prerequisite for this then.)

[Sorunome]

while profiles-as-rooms would be perfect for this, we want to implement stories asap. This MSC is largely intened to document how we are doing it until profiles-as-rooms is a thing.

[krille-chan]

I've thought about this too. If we start the app then we want to display a complete list of all stories from all contacts. If the account has 100 DM rooms (lets name these contact users) then it is not that practical to peek into 100 rooms I guess because this would mean 100 API calls if I'm not wrong. So it would first mean that the client has to autojoin all profile rooms to receive the stories via sync. I'm not sure if this is a problem.

Using room EDUs plus profile rooms sounds like the perfect solution. I wasnt aware of this :-)

[kevincox]

It sounds like we agree against to-device but I'm just going to highlight some more concerns.

1. If I log in with a new device I expect to see unexpired stories.
2. If I add a new "contact" they don't see my story.
3. If I have 300 "friends" I am sending a big object every time I want to send a story.

(In general I think the concept of "device" in Matrix was a mistake. I am a person and my devices are a private detail of my usage)

[krille-chan]

That is correct :-) I will wait then until the new features like profiles as rooms are implemented. However it was very interesting to write such a MSC by myself. Thank you all very much for the feedback :) I think I have learned a lot.