The first day of the Hackathon at #IETF124 in Montreal is coming to an end

[daniel@gultsch.social]

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.

¹: https://xmpp.org/extensions/xep-0444.html#disco-restricted

#XMPP #Jabber #Conversations_im

[nicoco@pouet.pas.la]

@daniel 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?

https://dev.gajim.org/gajim/gajim/-/merge_requests/1196
https://codeberg.org/slidge/slidge/commit/86066eb4b6daff4c2be7b26debe1099eeaa18ccd

[daniel@gultsch.social]

@nicoco @gajim Yes, I've implemented both the allow list and the max reactions per user.

Thus far I only support this in MUCs (We mainly wanted to proof that the XEP is feasible rather than create functionality that many users will use immediately.)

Announcing it on the domain (with 'scope') would probably solve a problem that @larma and I have been talking about too.

[larma@mastodon.social]

@daniel @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.

[nicoco@pouet.pas.la]

@larma @daniel
> 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?

[larma@mastodon.social]

@nicoco @daniel 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.

[nicoco@pouet.pas.la]

@larma @daniel
If you want to use a gateway, you likely need to disco it to look for registration mechanisms and adhoc commands you can use on it. I can't speak for all clients, but gajim disco JIDs in your roster, and if you have a slidge-based gateway that properly advertise its gateway type, it also uses that to add an icon to the avatar.

[daniel@gultsch.social]

@nicoco So I always have the domain of the transport in my roster? Is this a requirement (by Slidge) or merely a convention? @larma