[Standards] MUC Mention Notifications

JC Brand lists at opkode.com
Wed Dec 30 17:10:46 UTC 2020

On 25.12.20 13:38, Philipp Hörist wrote:
> Hi,
> Ok i think i get it, its a warmed up <attention> XEP. Not a very 
> successful XEP btw.
> Anyway back to the original use case for sending messages to people 
> not joined the MUC
> i think Marvins approach is easier.
> But it does not replace the reference mention, because we still need 
> that to mark up the text correctly. And yes references might be 
> encrypted, depending on the uri attr and what i can reference in the 
> future, so i would say we should not expect servers to be able to read 
> references. And its a recipe for disaster to encrypt some references 
> and others not.
> I really see no way how we can use references for these server features.
> Seems like we duplicating here a bit of functionality between the XEPs 
> then, but i still think its the cleaner approach.

If you can't use references because they're encrypted, then how is the 
server supposed to know who is to be notified?

Should the <notify> element then also contain the JID of the person 
being notified?

That would mean some information leakage, although it's still better 
than references because the <notify> element
won't refer to parts of the text in the message body.

> Am Fr., 25. Dez. 2020 um 12:49 Uhr schrieb Marvin W <xmpp at larma.de 
> <mailto:xmpp at larma.de>>:
>     Hi,
>     On 23.12.20 17:47, Philipp Hörist wrote:
>     > 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
>     Client should only add the <notify> tag on user request (that is
>     because
>     they did a mention or otherwise signal they'd like to notify a user).
>     The priority="high" tag should be even more restricted, e.g. should be
>     confirmed by user explicitly. Client should not have an option to send
>     <notify> with every message.
>     The downside for the sender is that the recipient probably doesn't
>     like
>     it when used without good reason and will probably hate you for doing
>     it. Obviously, recipient clients would need to have certain limits for
>     when they accept <notify> (e.g. ignore them when in direct
>     messages from
>     strangers to not amplify the impact of spam or allow to disable
>     support
>     for it per-contact in case any of your important contacts just
>     uses this
>     feature too much).
>     In large communities I've already seen users making excessive or
>     unjustified use of @all or @channel, leading to their messages being
>     removed, them being warned and/or banned. There can also be a server
>     policy that only room members of a certain level are allowed to send
>     these messages (or in our case <notify> tags). Having a more dedicated
>     feature for notifications that is not directly related to the message
>     body helps servers to enforce such policy.
>     Misuse of high priority notification (be it by adding a <notify>
>     tag or
>     by mentioning) is a social issue that you can't tackle
>     meaningfully on a
>     protocol level alone.
>     On 24.12.20 16:25, Matthew Wild wrote:
>     > <notify> would be largely duplicating the semantics of XEP-0372
>     > mentions.
>     XEP-0372 (in its current version 0.4.0) does not specify any semantics
>     for mentions at all and (according to its introduction) only
>     "provides a
>     mechanism for marking up a section of a message body with information
>     about the target of the reference".
>     <notify> would only be about semantics and not about marking up in
>     message body at all. At least with the current specification, there
>     would be little to no overlap and definitely no duplication. Sure
>     enough
>     you could go without the <notify> element and create a XEP that adds
>     semantic meaning to a XEP-0372 mention (which is what the suggested
>     protoxep does). But I think splitting semantics and markup here
>     makes a
>     lot of sense.
>     I am aware that some implementations may use XEP-0372 as an
>     indicator to
>     notify users in MUCs, but those implementations probably would also do
>     this without XEP-0372 by matching body against the users nickname.
>     Both
>     is obviously unspecified behavior. <notify> is about adding a properly
>     specified method to (in the long run) replace such unspecified
>     behavior.
>     Marvin
>     _______________________________________________
>     Standards mailing list
>     Info: https://mail.jabber.org/mailman/listinfo/standards
>     <https://mail.jabber.org/mailman/listinfo/standards>
>     Unsubscribe: Standards-unsubscribe at xmpp.org
>     <mailto: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