[Standards] MUC Mention Notifications

Kevin Smith kevin.smith at isode.com
Wed Dec 23 15:28:43 UTC 2020

On 23 Dec 2020, at 15:16, Marvin W <xmpp at larma.de> wrote:
> Hi there,
> I actually was working on something with partially overlapping goals,
> that is
> a) being notified for relevant groupchat messages via push
> notifications. This is mostly relevant for iOS push notifications (at
> least as far as I understood during last summit).
> b) signal to recipient that a message is important to notify about (for
> example, when out of office, still notify for the really important
> things). This is a feature some of you may know from Slack.
> I was first thinking to base this around mentions as well, but that
> would mostly work for a, not b (at least not how b is realized in Slack).
> I thus was to suggest a much more generic approach, that is to add a new
> element <notify jid="hag66 at shakespeare.lit" /> to the message
> (completely independent of any use of mentions/references). Jid could be
> left out in direct chats, in MUCs can point to the real jid, member jid
> or room jid (equivalent to @channel mentioning), also there might be
> value in an optional priority="high" attribute to signal higher message
> priority.
> Your usecase of delivering messages to non-present MUC users seems to
> fit into this schema. Also, adding server-side meaning to something that
> is mostly formatting (mentions) seems a little bit weird to me.
> Another advantage of the <notify> element approach is that it also works
> for server-side processing in e2ee message (without leaking relevant
> message details) as long as the <notify> is not e2e encrypted (which it
> shouldn't be as it's also meant to be processed by servers).

I like this, I think this is a useful discussion to be having.

I think there’s merit in something combining these two approaches. I think the idea of being able to specify that it’s meant to generate a notification is useful (and I can see why Slack’s ‘also say I want to override notification silencing’ would be useful - although for that to work as in Slack the sender has to be able to discover that the recipient has disabled notifications, and I suggest that a ‘please notify even if notifications are turned off’ flag would be useful if we go that route, as this processing is going to be recipient-side). Also useful is everything-under-the-Sun’s ability to @everyone and @groups, which a notify mechanism nicely addresses. Also useful is referencing a particular bit of the message to be the markup, like in references(mentions). 


> Marvin
> On 18.12.20 18:00, JC Brand wrote:
>> Hi all
>> I've submitted a PR for a new protoXEP: MUC Mention Notifictions
>> https://github.com/xsf/xeps/pull/1022
>> The goal is to document how someone who's affiliated, but not currently
>> present in a MUC might receive notifications when he/she is mentioned
>> inside that MUC.
>> For the concept of "mentions", XEP-0372 references are used.
>> To enable this feature, I've opted for a configuration setting in the MUC.
>> Apparently Tigase already has a similar feature to this protoXEP and
>> relies on letting the user opt-in when registering a nickname with the MUC.
>> Maybe someone from Tigase can comment on the particulars of that. My
>> understanding is that this necessitates the ability to self-register in
>> a MUC, which IMO adds a hurdle to adoption of this feature.
>> Regards
>> JC
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list