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 <x...@larma.de
<mailto: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
<https://mail.jabber.org/mailman/listinfo/standards>
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
_______________________________________________
_______________________________________________
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
_______________________________________________
