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