MattJpep.: I don't understand your question about unavailable presence
pep.I don't understand under what condition I can use RAI.
pep.(or not use it)
pep.And under what condition I can unset it
etawhat's its intended usecase?
MattJThe intended use case is stated in the intro and repeated elsewhere in the document
pep.MattJ, "A client may unsubscribe from activity indicators by sending an unavailable presence to the MUC service.", at this point the user is already not joined right?
pep.Can I also initiate rai when joined?
pep.What happens when I leave the room, does that also cancel rai?
ZashMUC service = bare host JID of the MUC?
pep.because this has proved to cause weird issues in the past, and it works just fine addressing the room directly
ZashAs punishment for whoever decided that room@host could be a MUC service?
pep.You want rai for multiple rooms just send that to multiple rooms?
MattJRead the requirements
pep.What if I want rai for all rooms minus one
MattJThere aren't many
pep.I kinda think it's meh to assume nowadays that bare host is a muc component
pep.Especially coming from prosody people :P
ZashThat's required by XEP-0045
MattJThere are many things that are addressed to the MUC service in XEP-0045
MattJAlso ad-hoc, etc.
pep.ad-hoc on MUC is a thing in some implementation?
pep.Ah biboumi maybe
MattJOf course, why not?
pep.I've been waiting for that in prosody. Actually that's wrong, I've been waiting for ad-hoc on rooms
MattJWaiting? It can't be done now?
pep.Anyway the unsubscribe thing is confusing
MattJI only added it at the last minute for completeness
MattJAnticipating that someone would say "but how do you unsubscribe?"
Zashpep.: You'll have to wait for Prosodys ad-hoc to support commands on anything but host JIDs then.
MattJNow it's confusing to be able to unsubscribe :)
pep.Also "activity" doesn't seem very much defined
MattJ"there are new messages in a room since the last time the user was joined there"
pep."A MUC may already send out-of-band notifications to users who are not currently joined if e.g. they are mentioned using &xep0372;" what's this then
MattJThat seems a fine definition to me. Implementation specifics are indeed not defined, that's fairly intentional
pep.I thought that was just another example of what it could be
pep.So 372 is mentioned for no reason?
MattJIt's an example
pep.ok so it's all implementation defined :/
MattJI really think you're missing the point of this
pep.I'm trying to understand why it's useful, even more so now that you're saying it's implementation defined
pep.Don't get me wrong it's not just this XEP
MattJXEP-0372 is used for pushing notifications from a MUC to a user, about messages the MUC thinks the user should be notified about
MattJBut there are messages where the user is not mentioned
pep.hmm, shortcuts? 372 is used to find out who to notify via some other mechanism
MattJand the user may still want to know whether there are any of those, or if the room has just been idle
pep.Makes a bit more sense
MattJ"A MUC may already send out-of-band notifications to users who are not currently joined if e.g. they are mentioned using &xep0372;."
MattJ"However a MUC typically won't forward other kinds of messages unless the user is joined."
MattJ^ Problem statement
pep.Yeah.. we're all good at language all the time every time..
pep.I'm still meh on the "implementation detail" thing, what is a "message" now :x
MattJWhich "implementation detail" thing?
pep."Implementation specifics are indeed not defined, that's fairly intentional"
MattJWhat would you define?
MattJAbove what is already defined
pep.what's a "message", or rather what's a "relevant" message, I guess would be more accurate here (something that other XEPs might be able to use)
pep.I guess you're not gonna send RIA for chatstates
MattJSo you want it to list every possible kind of message in the XEP? Every combination of payloads?
pep.Well it's already being done in implementations having to know what a "relevant" message is, I don't see why not
MattJThe Prosody implementation depends on MAM on the MUC room, and it's considered activity if it gets archived
Zashwhich boils down to "has <body>"
MattJSo I could add a dependency on MAM, and basically spec this implementation
pep.If there had to be such a XEP, I'd decouple it from MAM surely
MattJBut I don't want to do that, because I think that's a very rigid/brittle approach that would be too limiting
MattJI think anyone who implements and deploys this would be able to make the right choice here
MattJIf they don't, their implementation is screwed up and they'll see that
MattJBut still, no harm done otherwise
MattJSpecs matter for interoperability, this isn't an interop issue
pep.Yes I think it is. I can't use the same client and expect the same behaviour if I use two different server implementations. Or maybe that's not called interop but it's as bad
ZashIs this about to become another of those things like carbons, mam, csi etc where people disagree on how strict the rules should be?
pep.It works in closed environments where you're only gonna use one implementation anyway
pep.Zash, looks like the same problem to me
ZashSomeone™ should write down some guidance, either in xep-0226 or some new XEP.
pep.Anyway.. afk rebooting server
MattJZash: nice list of mostly XEPs written by me :)
MattJBecause yes, I do believe in defining what's necessary for interop and no more - at least in the early stages
MattJThings can always be tightened up later based on implementation experience, or requirements for specific deployments
MattJAs long as the semantics are well definee
MattJAs long as the semantics are well defined
pep.well I don't think they are, well-defined semantics here would be defining "relevant" I'd say
MattJI also like to believe that most developers do have common sense
pep.I don't recall off-hand if MAM provides guidelines at least? or carbons or..
pep.carbons has some kind of rules right?
MattJNo, this is a protocol for telling the client to tell the user that something happened in the room
MattJIf the server thinks an affiliation change is important to that user, it should be allowed to send them a notification
pep.fwiw, I firmly believe a user should be able to filter the kind of notification they get, so putting this in the hands of the server says this is already not for me
MattJThen feel free to not deploy it, but I'm deploying this next week
MattJThere are early-stage plugins for Prosody, Openfire and Converse.js. It fills a need. If it doesn't fill your need, feel free to spec and implement something more complex that allows clients to specify filter rules.
MattJI have a long list of XEPs that I intend to write and publish over the coming weeks... and this is by far the simplest and least controversial, so we're off to a good start :)