[Standards] MUC Mention Notifications
lists at opkode.com
Wed Dec 30 16:49:43 UTC 2020
On 23.12.20 16:16, Marvin W 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
> 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.
I don't find it that weird. It's more implicit than adding a <notify>
but the XEP requires it to be configured in the MUC and it's not too
expect that when you mention someone, they'll be notified somehow.
> 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).
That is indeed a significant advantage, and I like the idea of being
presented the option (like in Slack) on whether I'd like to notify
the person I'm mentioning or not.
I do see some ambiguity here though. My use-case specifically is
notifying someone who's not present in a MUC, but what about
someone who *is* present in a MUC.
I believe most clients currently will notify a user present in a MUC when
mentioned, but now the presence or absence of the <notify> element
might make the sender-intended behaviour less clear.
Doesn't the absence of a <notify> element mean that
that mentioned user shouldn't be notified at all, even when they're
present in the MUC?
And if it doesn't, then it implies that the <notify> element is meaningless
for users who are currently present in the MUC, which seems semantically
confusing to me, as if the <notify> elements' purpose is not clear from
Maybe this can be resolve by calling the element "notify-absent" instead.
What do you think?
> On 18.12.20 18:00, JC Brand wrote:
>> Hi all
>> I've submitted a PR for a new protoXEP: MUC Mention Notifictions
>> 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.
>> 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