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. Regards Philipp Am Fr., 25. Dez. 2020 um 12:49 Uhr schrieb Marvin W <x...@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 > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
