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 <notify jid="ha...@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.
I don't find it that weird. It's more implicit than adding a <notify>
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 <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).
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 <notify> element
might make the sender-intended behaviour less clear.
Doesn't the absence of a <notify> 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 <notify> element is meaningless
for users who are currently present in the MUC, which seems semantically
confusing to me, as if the <notify> 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
_______________________________________________
