matrix-spec-proposals icon indicating copy to clipboard operation
matrix-spec-proposals copied to clipboard

MSC2677: Annotations and reactions

Open uhoreg opened this issue 5 years ago • 13 comments
trafficstars

Rendered

Replaces matrix-org/matrix-spec-proposals#1849 along with matrix-org/matrix-spec-proposals#2674, matrix-org/matrix-spec-proposals#2675, and matrix-org/matrix-spec-proposals#2676

uhoreg avatar Jul 07 '20 20:07 uhoreg

Is this the Matrix spec proposal that is currently implemented by Element (and Synapse?) for their reactions? Did they actually implement it already without reactions being standardized, or is there some other message type I'm missing?

chc4 avatar Jan 17 '21 06:01 chc4

Yes. Proposals have to be proven to work with an implementation before they can be accepted, otherwise we'd end up with lots of fancy specs with no idea if they're going to work in the real world.

This proposal is a bit old (the original version, matrix-org/matrix-spec-proposals#1849, is from early 2019), which is why the event type is m.reaction instead of using an unstable prefix like org.matrix.msc1849.reaction. PoC implementations of newer proposals will use unstable prefixes as per matrix-org/matrix-spec-proposals#2324.

tulir avatar Jan 17 '21 10:01 tulir

Huh, ok. I understand the reasoning, but having the reference client and reference server implement non-standardized parts of the Matrix spec is a pretty bad look.

chc4 avatar Jan 17 '21 22:01 chc4

That's why matrix-org/matrix-spec-proposals#2324 was agreed upon so there is a clear line between the spec and implementations being ahead of the released spec. All projects like this grow organically, sometimes you just need to learn from your missteps.

Cadair avatar Jan 18 '21 10:01 Cadair

was brought up again in a matrix room, how is it that this MSC isn't FCPd yet? what things are remaining before this can become part of the normal spec?

ShadowJonathan avatar Feb 22 '21 16:02 ShadowJonathan

Apologies if this is the wrong place for this:

It would be helpful if guidance were given to client developers about how to guide users in sending reactions. For example, in Element, there's a button to click to select an emoji, and users can also input them by typing certain strings wrapped in :, like :heart:.

But in my client, what choices should I offer users? Is there a list of acceptable keys? Is any string allowed? Is there a standard mapping between emojis and their :-wrapped aliases? Is each client developer expected to research this and reimplement the functionality? Are there any interoperability concerns between clients?

Thanks.

alphapapa avatar Jul 30 '21 05:07 alphapapa

@alphapapa I believe such questions are better answered in #matrix-dev:matrix.org

ShadowJonathan avatar Aug 01 '21 19:08 ShadowJonathan

@ShadowJonathan It would be helpful if these questions were answered by the spec for client devs to refer to, like the guidance the spec gives regarding other client issues. That is the purpose of the spec, no?

alphapapa avatar Aug 01 '21 21:08 alphapapa

@alphapapa this is off-topic to the MSC at hand, please open an issue or talk in that room, #matrix-spec:matrix.org is also relevant.

ShadowJonathan avatar Aug 01 '21 21:08 ShadowJonathan

@ShadowJonathan I don't understand. I'm commenting on this proposed change to the spec, to ask that it include answers to certain questions for client developers, which it currently doesn't. How is that off-topic?

alphapapa avatar Aug 03 '21 06:08 alphapapa

@alphapapa it is off-topic to this current MSC, which is only related to the protocol-technical aspect of replies, reactions, and anything else this might empower (wrt inter-message relations). Please file a separate issue for what you're suggesting.

ShadowJonathan avatar Aug 03 '21 11:08 ShadowJonathan

@alphapapa please add comments on the document (which allows threading), rather than comments here, as it's easier to follow. But the quick answers to your questions are that any string is allowed as the key, and mapping human-readable names to emoji is out of scope for this MSC.

uhoreg avatar Aug 03 '21 18:08 uhoreg

The CS API should not allow to send a relation targetting a m.annotation event, as discussed at https://github.com/matrix-org/matrix-doc/pull/2675#discussion_r757010873

bwindels avatar Nov 30 '21 10:11 bwindels

I think this MSC now matches reality and is substantially clarified. Review would be appreciated.

richvdh avatar Feb 14 '23 23:02 richvdh

@mscbot fcp merge

turt2live avatar Feb 22 '23 06:02 turt2live

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

  • [x] @dbkr
  • [x] @uhoreg
  • [x] @turt2live
  • [ ] @ara4n
  • [x] @anoadragon453
  • [x] @richvdh
  • [x] @erikjohnston
  • [ ] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

mscbot avatar Feb 22 '23 06:02 mscbot

:bell: This is now entering its final comment period, as per the review above. :bell:

mscbot avatar Mar 21 '23 14:03 mscbot

The final comment period, with a disposition to merge, as per the review above, is now complete.

mscbot avatar Mar 26 '23 14:03 mscbot

Spec PR: https://github.com/matrix-org/matrix-spec/pull/1475

turt2live avatar Mar 28 '23 15:03 turt2live

Merged 🎉

turt2live avatar Apr 25 '23 18:04 turt2live