Re: [Standards] MUC Mention Notifications

[Dave Cridland]

On Wed, 30 Dec 2020, 16:33 JC Brand,  wrote:

>
>
> On 18.12.20 19:10, Dave Cridland wrote:
> > On Fri, 18 Dec 2020 at 17:01, JC Brand  > > wrote:
> >
> > Hi all
> >
> > I've submitted a PR for a new protoXEP: MUC Mention Notifictions
> >
> > https://github.com/xsf/xeps/pull/1022
> > 
> >
> >
> > Thanks, this looks like a solid start and I will be voting to accept it.
>
> Thanks, your cheque is in the mail.
>

For the avoidance of doubt, I would never accept a cheque for a vote. Who
on earth accepts cheques these days?


> > Comments:
> >
> > 1) I think it would benefit from an example of the mention itself,
> > though I assume it to be the message shown as forwarded in §3.2
>
> Yeah, it would just be a copy paste of the inner . I've added
> some clarifying text to the bottom of the example.
>

Thanks.


> > 2) Section 3.2 shows a message being forwarded to a full jid for the
> > mentioned user - is this intentional?
>
> Nope, fixed thanks.
>

Thanks.


> > 3) The message forwarded doesn't contain, and is not accompanied by, a
> > MAM stanza-id, which might be useful to locate it in the MUC archive.
> > Can we include this if the room is archived?
>
> Ok, I added it.
>
> I was wondering whether I should include the stanza-id or not and
> originally decided not to in order to keep the stanza clear and to the
> point of this particular XEP.
>

If I get a mention in a room I'm in, it's useful to immediately scroll to
find the context. Otherwise, a "I don't know, ask dwd" isn't very useful.

A MAM id would let me do this, or at least enable that UX, so I think it's
important to include, and indeed mandate.



> Thanks
> JC
>
> ___
> 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
___

Re: [Standards] MUC Mention Notifications

[Andrzej Wojcik]

> Wiadomość napisana przez JC Brand  w dniu 30.12.2020, o 
> godz. 17:28:
> 
>> In the proposed protoXEP  element contains real bare JID of the 
>> user affiliated with the room, which is available, if I'm correct, only in 
>> non-anonymous rooms. In semi-anonymous it may not be available. Due to that 
>> it restricts usage of the protoXEP only to the cases in which bare jids of 
>> users in the room are known to the occupants.
> 
> You could still reference the person by MUC JID and nickname, as long as the 
> nickname is registered (i.e. exclusive to one user) in the MUC.

Yes, with use of full JID of the occupant in the MUC room. That should work.

>> Additionally I'm not sure if affiliation of a user with a room is enough for 
>> sending notifications as nickname used to mention someone could be already 
>> taken by someone else (if affiliation will not block nickname from being 
>> reuse and AFAIR it does not).
> 
> I was under the assumption that all affiliated users have their nicknames 
> registered (i.e. the nicks can't be taken by anyone else). Is this wrong?

I'm not sure if affiliation has anything to do with nickname, ie. owner 
affiliation is set to owners JID but I do not recall that his nickname is 
somehow connect to the affiliation. I suppose that the same goes for admin 
affiliation. I also suppose that you can be invite to the room and join it then 
leave it and still be a member of this room while you could join with any 
nickname you want.

In my opinion, affiliation is not connected in any way to nickname 
registration, so you could register a nickname without having an affiliation 
and you could have an affiliation without registering a nickname,

> If this requirement is too lax, then I guess we'll have to update the XEP to 
> require nickname registration instead of (just) affiliation.

If I'm correct, I suppose that nickname registration would be required as well.

Regards,
Andrzej Wójcik

XMPP: andrzej.woj...@tigase.org
Email: andrzej.woj...@tigase.net

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[JC Brand]

On 25.12.20 13:38, Philipp Hörist wrote:

Hi,

Ok i think i get it, its a warmed up  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  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  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 >:


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  to every message? I see no downside for the sender

Client should only add the  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
 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  (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  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 
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:
>  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".

 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  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.  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
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
__

Re: [Standards] MUC Mention Notifications

[JC Brand]

On 25.12.20 12:46, Marvin W wrote:



On 24.12.20 16:25, Matthew Wild wrote:

 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".


You can specify type="mention" for the  (as in the example
in XEP-0372), to me that is semantic information.


 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  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 do see semantic overlap, hence the ambiguity I was mentioning in my
other reply to your first email in this thread.


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.  is about adding a properly
specified method to (in the long run) replace such unspecified behavior.


I'd say that very often the whole point of mentioning someone is so that
they get notified and not just for markup/display reasons.

It could be argued that adding type="mention" to a  is
asking for the user to get notified.

I'm not against the idea of using  but I'd like the ambiguities to
be cleared up first before updating the XEP to use it.

JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[JC Brand]

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  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.


I don't find it that weird. It's more implicit than adding a  
element,
but the XEP requires it to be configured in the MUC and it's not too 
crazy to

expect that when you mention someone, they'll be notified somehow.


Another advantage of the  element approach is that it also works
for server-side processing in e2ee message (without leaking relevant
message details) as long as the  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  element
might make the sender-intended behaviour less clear.

Doesn't the absence of a  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  element is meaningless
for users who are currently present in the MUC, which seems semantically
confusing to me, as if the  elements' purpose is not clear from
its name.

Maybe this can be resolve by calling the element "notify-absent" instead.

What do you think?

JC



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-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
___

Re: [Standards] MUC Mention Notifications

[JC Brand]

On 19.12.20 16:41, Andrzej Wojcik wrote:

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.


Our approach was designed to solve MUC issue on the iOS based device 
where XMPP connection cannot be kept alive while in the background.


The idea was to enable MUC room to send groupchat messages (any 
message, not just mentions) to the user even if he is offline.
Additionally with nickname registration, we were able to present 
offline users but subscribed with offline notifications as away in the 
rooms.
That also allowed us to block nickname from being used in this room by 
anyone else and did not require any modification on the senders client 
side as the room was forwarding all messages and thanks to the logic 
on users local server push notifications to the users client were 
generated.


In the proposed protoXEP  element contains real bare JID 
of the user affiliated with the room, which is available, if I'm 
correct, only in non-anonymous rooms. In semi-anonymous it may not be 
available. Due to that it restricts usage of the protoXEP only to the 
cases in which bare jids of users in the room are known to the occupants.


You could still reference the person by MUC JID and nickname, as long as 
the nickname is registered (i.e. exclusive to one user) in the MUC.


Additionally I'm not sure if affiliation of a user with a room is 
enough for sending notifications as nickname used to mention someone 
could be already taken by someone else (if affiliation will not block 
nickname from being reuse and AFAIR it does not).


I was under the assumption that all affiliated users have their 
nicknames registered (i.e. the nicks can't be taken by anyone else). Is 
this wrong?


If this requirement is too lax, then I guess we'll have to update the 
XEP to require nickname registration instead of (just) affiliation.




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[JC Brand]

On 18.12.20 19:10, Dave Cridland wrote:
On Fri, 18 Dec 2020 at 17:01, JC Brand > wrote:


Hi all

I've submitted a PR for a new protoXEP: MUC Mention Notifictions

https://github.com/xsf/xeps/pull/1022



Thanks, this looks like a solid start and I will be voting to accept it.


Thanks, your cheque is in the mail.


Comments:

1) I think it would benefit from an example of the mention itself, 
though I assume it to be the message shown as forwarded in §3.2


Yeah, it would just be a copy paste of the inner . I've added 
some clarifying text to the bottom of the example.


2) Section 3.2 shows a message being forwarded to a full jid for the 
mentioned user - is this intentional?


Nope, fixed thanks.

3) The message forwarded doesn't contain, and is not accompanied by, a 
MAM stanza-id, which might be useful to locate it in the MUC archive. 
Can we include this if the room is archived?


Ok, I added it.

I was wondering whether I should include the stanza-id or not and 
originally decided not to in order to keep the stanza clear and to the 
point of this particular XEP.


Thanks
JC

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[Philipp Hörist]

Hi,

Ok i think i get it, its a warmed up  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 :

> 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  to every message? I see no downside for the sender
>
> Client should only add the  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
>  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  (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  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  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:
> >  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".
>
>  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  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.  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
___

Re: [Standards] MUC Mention Notifications

[Marvin W]

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  to every message? I see no downside for the sender

Client should only add the  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
 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  (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  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  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:
>  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".

 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  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.  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
___

Re: [Standards] MUC Mention Notifications

[Matthew Wild]

On Wed, 23 Dec 2020 at 16:48, Philipp Hörist  wrote:

> 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  to every message? I see
> no downside for the sender
>

I agree that having it in control of the sender is a bit strange. Though I
understand the issue with e2ee, I am not sure if this it the best way to
solve it.  would be largely duplicating the semantics of XEP-0372
mentions.

I also agree with what was said earlier in the thread, that I think this
XEP solves a small part of a broader problem - i.e. how (and when) a MUC
should notify an absent participant about something they may be interested
in receiving. I think the 'how' and 'when' are fine to be separated.

This is all I have time to write up right now, but I am indeed glad we're
finally making progress on this :)

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[Philipp Hörist]

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  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.sm...@isode.com>:

> On 23 Dec 2020, at 15: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  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  element approach is that it also works
> > for server-side processing in e2ee message (without leaking relevant
> > message details) as long as the  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-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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[Kevin Smith]

On 23 Dec 2020, at 15: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  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  element approach is that it also works
> for server-side processing in e2ee message (without leaking relevant
> message details) as long as the  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-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
___

Re: [Standards] MUC Mention Notifications

[Marvin W]

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  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  element approach is that it also works
for server-side processing in e2ee message (without leaking relevant
message details) as long as the  is not e2e encrypted (which it
shouldn't be as it's also meant to be processed by servers).

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-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[Andrzej Wojcik]

Hi all,

> 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.

Our approach was designed to solve MUC issue on the iOS based device where XMPP 
connection cannot be kept alive while in the background.

The idea was to enable MUC room to send groupchat messages (any message, not 
just mentions) to the user even if he is offline. 
Additionally with nickname registration, we were able to present offline users 
but subscribed with offline notifications as away in the rooms.
That also allowed us to block nickname from being used in this room by anyone 
else and did not require any modification on the senders client side as the 
room was forwarding all messages and thanks to the logic on users local server 
push notifications to the users client were generated.

In the proposed protoXEP  element contains real bare JID of the 
user affiliated with the room, which is available, if I'm correct, only in 
non-anonymous rooms. In semi-anonymous it may not be available. Due to that it 
restricts usage of the protoXEP only to the cases in which bare jids of users 
in the room are known to the occupants.

Additionally I'm not sure if affiliation of a user with a room is enough for 
sending notifications as nickname used to mention someone could be already 
taken by someone else (if affiliation will not block nickname from being reuse 
and AFAIR it does not).

Regards,
Andrzej Wójcik

XMPP: andrzej.woj...@tigase.org
Email: andrzej.woj...@tigase.net

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[Dave Cridland]

On Fri, 18 Dec 2020 at 17:01, JC Brand  wrote:

> Hi all
>
> I've submitted a PR for a new protoXEP: MUC Mention Notifictions
>
> https://github.com/xsf/xeps/pull/1022


Thanks, this looks like a solid start and I will be voting to accept it.

Comments:

1) I think it would benefit from an example of the mention itself, though I
assume it to be the message shown as forwarded in §3.2

2) Section 3.2 shows a message being forwarded to a full jid for the
mentioned user - is this intentional?

3) The message forwarded doesn't contain, and is not accompanied by, a MAM
stanza-id, which might be useful to locate it in the MUC archive. Can we
include this if the room is archived?

Thanks!

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___