[Standards] MUC Mention Notifications

Philipp Hörist philipp at hoerist.com
Wed Dec 23 16:47:12 UTC 2020


Hi

and when would a client add this notify tag? Should the client let the user
decide? (I dont like that)
Is there any reason why i would not add <notify> to every message? I see no
downside for the sender

best wishes
Philipp

Am Mi., 23. Dez. 2020 um 16:29 Uhr schrieb Kevin Smith <
kevin.smith at isode.com>:

> 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).
>
> /K
>
> > 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
> > _______________________________________________
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201223/89fd127f/attachment.html>


More information about the Standards mailing list