On 23 Dec 2020, at 15:16, Marvin W <x...@larma.de> 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. > > 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).
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 _______________________________________________
