-
Notifications
You must be signed in to change notification settings - Fork 382
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
MSC3935: Cute Events against social distancing #3935
base: main
Are you sure you want to change the base?
MSC3935: Cute Events against social distancing #3935
Conversation
Signed-off-by: TheOneWithTheBraid <the-one@with-the-braid.cf>
Signed-off-by: TheOneWithTheBraid <the-one@with-the-braid.cf>
Hope this turn won't into cold "X send you a hug". |
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.
there's an amount of typos in this file
|
||
## Potential issues | ||
|
||
This MSC instroduces potential issues in regard of accessibility. They are |
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.
This MSC instroduces potential issues in regard of accessibility. They are | |
This MSC introduces potential issues in regard of accessibility. They are |
|
||
## Alternatives | ||
|
||
A conscidered alternative to Cute Events are MSC2545 - Image Packs |
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.
A conscidered alternative to Cute Events are MSC2545 - Image Packs | |
A considered alternative to Cute Events are MSC2545 - Image Packs |
|
||
## Dependencies | ||
|
||
This MSC dos not have any particular dependency. |
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.
This MSC dos not have any particular dependency. | |
This MSC does not have any particular dependency. |
|
||
This MSC targets this problem by introducing a new `msgtype` for | ||
`m.room.message` named `m.cute_event`. Cute events should provide fallback | ||
conent as Unicoe Emotes. Suppoted clients can render these events in a special, |
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.
conent as Unicoe Emotes. Suppoted clients can render these events in a special, | |
content as Unicode Emotes. Supported clients can render these events in a special, |
Reminds me of Elements |
## Potential issues | ||
|
||
This MSC instroduces potential issues in regard of accessibility. They are | ||
discussed below in the [Security](#Security considerations) section. |
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.
discussed below in the [Security](#Security considerations) section. | |
discussed below in the [Security](#security-considerations) section. |
To be honest, this feels like a strange thing to add to the spec, especially considering that not even confetti has been officially added to the spec. While things like confetti can be fun (and I added confetti to nheko recently), I think that it is easy to go overboard with effects like these, and some of these things are best implemented as an unofficial event type (like Maybe there should be an "unofficial spec" created that collects community-created event types that clients can then implement at their leisure instead of (potentially) feeling pressured to implement fancy effects like these that have been added to the spec. |
|
It looks like this MSC didn't get added to the tracking boards we use to avoid forgetting about MSCs, sorry. That said, I generally agree that this should wait until we have a formal "event registry" or similar. The first step towards that is #3587 (which needs to be migrated to the new repo 😇), then an MSC to describe how governance around random event types works. @mscbot fcp postpone |
Team member @turt2live has proposed to postpone this. The next step is review by the rest of the tagged people: 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. |
|
||
The specified type is contained in the event's content under the key `type`. | ||
|
||
The `body` MUST contain a fallback for unsupported clients as Unicode Emote. |
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.
Seems like this might get a different representation under Extensible Events. Maybe something like
{
"type": "m.cute_event",
"content": {
"m.cute_event": {
"type": "googly_eyes",
},
"m.text": [
{"body": "👀"}
]
}
}
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.
This really feels like a perfect use case for extensible events. Would it be too much to suggest building on that rather than having to implement it and then adapt it later? It also saves clarifying that this is an optional feature: with extensible events rendering the text fallback is always a perfectly acceptable option.
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.
yeah, while reading this MSC, i really thought that this is screaming out to be implemented extensible events.
I also think that 'cute events' are actually a useful feature in general - e.g. for bridging to iMessage, for recommending special effects to be applied to event presentation.
I don't think we should block this on an "event registry" though. Instead, I suspect the best way to proceed on this would be to:
a) turn it into extensible events (i.e. have an m.effect
mix-in)
b) specify some effects based on whatever fluffychat + element + imessage does already today:
- imessage (stolen from https://mobi.easeus.com/ios-tips/iphone-text-effects-and-tricks.html):
- fireworks
- firecrackers
- balloons
- confetti
- laser show
- slam
- loud
- gentle
- invisible ink
- echo
- Spotlight
- love
- celebration (same as firecrackers?)
- shooting star
- fluffychat
- googly eyes
- ...
- element
- space invaders
- snow
...and in future introduce a registry so people can rack up a common language for future effects.
|
||
## Potential issues | ||
|
||
This MSC instroduces potential issues in regard of accessibility. They are |
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.
I'm finding this section quite weird. If they're a11y issues, I'd put them here. If they're security issues, I'd just put 'None foreseen' or something here and put them in the security section?
|
||
## Dependencies | ||
|
||
This MSC dos not have any particular dependency. |
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.
What do you mean by 'particular' here? I think it just has no dependencies, full stop?
|
||
The specified type is contained in the event's content under the key `type`. | ||
|
||
The `body` MUST contain a fallback for unsupported clients as Unicode Emote. |
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.
This really feels like a perfect use case for extensible events. Would it be too much to suggest building on that rather than having to implement it and then adapt it later? It also saves clarifying that this is an optional feature: with extensible events rendering the text fallback is always a perfectly acceptable option.
The initial implementation is found in the | ||
[Matrix Dart SDK](https://gitlab.com/famedly/company/frontend/famedlysdk/-/merge_requests/1168), | ||
prefixed as: `im.fluffychat.cute_event`. An | ||
[open MR for FluffyChat](https://gitlab.com/famedly/fluffychat/-/merge_requests/1031) exists. |
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.
These links needs updating
social distance by sending Cute Events: Googly Eyes, Hugs and Cuddles.* | ||
|
||
This MSC targets this problem by introducing a new `msgtype` for | ||
`m.room.message` named `m.cute_event`. Cute events should provide fallback |
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.
Cute events are cute but this feels like it could probably have a wider scope and include stuff that isn't necessarily just... cute? I don't know what a better name would be though, possibly because I'm not quite imagining what might actually happen in the client other than an animated sticker or something (at which point we're into your alternative).
Btw, a gif of fluffychat rendering one of these events would feel useful and entirely appropriate to put in the MSC description, personally.
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.
Maybe something like "visual effect", "emote" or "emotion"? "Event" might be redundant since we already know it is inside an event.
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to postpone, as per the review above, is now complete. |
For clarity: this is postponed until Extensible Events progresses further, either with an event registry or a more complete base system is usable. The proposal will be re-evaluated at that point. |
rendered
Signed-off-by: TheOneWithTheBraid the-one@with-the-braid.cf
FCP-postpone tickyboxes