The first day of the Hackathon at #IETF124 in Montreal is coming to an end.
We implemented the relatively niche feature of XEP-0444: Message Reactions that allows channels or group chats to restrict the type and number of emoji reactions users can do.¹

This brings us a step closer to advancing and stabilizing the XEP. We didn’t want to do that before, since we aim to have complete implementations before requesting a Last Call.

¹: xmpp.org/extensions/xep-0444.h…

#XMPP #Jabber #Conversations_im

This entry was edited (1 month ago)
in reply to Daniel Gultsch

Oh cool, did you implement a "restricted emoji picker" in Conversations? I only implemented "1 emoji/message" in @gajim

For groupchats I followed the spec, but for 1:1 chats lovetox did not want to rely on anything resource-related (client disco features/caps). I added the restriction form at the "server" (=gateway component) level, by adding a `scope=domain` field. It may be worth an extra sentence in 2.2 of the spec?

dev.gajim.org/gajim/gajim/-/me…
codeberg.org/slidge/slidge/com…

Unknown parent

mastodon - Link to source

Marvin W

@nicoco @gajim I'm not sure we need to announce a scope, I would usually expect restrictions to apply to all "sub JIDs" (that is, it applies to full jid if disco'd on bare JIDs and on bare JIDs when disco'd on domains).

That said, the main issue with announcing it on the domain is that many clients don't disco their peer's domain (also typically not the bare JID) and it would be weird to disco all domains of all contacts just for the purpose of reaction restrictions.

in reply to Marvin W

@larma
> it would be weird to disco all domains of all contacts
I think the reasonable use-cases are MUCs and gateways. If you use a gateway, you probably have its disco cached somewhere. It makes sense to check for restrictions there specifically if one wants a client that integrates nicely with gateways. It should be "almost" free if it is already implemented for MUCs, I think?
in reply to Nicoco

@nicoco Can you elaborate why a client would typically disco the domain of a gateway service? Sure, if a service was disco'd before and I thus have the data available locally, I'd use it. For what I know, most client implementations only ever disco their local server, bare JIDs of MUCs and full JIDs for which they got a caps string in their presence.
This entry was edited (1 month ago)
Unknown parent

mastodon - Link to source

Nicoco

@larma
Not a requirement, but a convention that I took from spectrum. Some gateways don't rely on this at all (eg, biboumi).
In slidge it's better if the gateway is in your roster because:
- if you want to map your presences to the gateway'ed network, slidge relies on presences received on the bare domain (arguably, this could be changed)
- the gateway sends presence with status message and a "show" value, eg, "dnd" if something is wrong