emusMaranda: Du musst dich klarer ausdrücken und am besten auf englisch. sonst geh mal hier hin:
emusxmpp:xmpp-de@conference.conversations.im?join
Danielhas joined
andyhas joined
Jeybehas joined
bearhas joined
mukt2has joined
emushas left
Syndacewhat xD
emushas joined
SyndaceYeah Maranda, stop speaking such unclear german!!!
lovetoxhas joined
mukt2has left
j.rhas left
j.rhas joined
!XSF_Martinemus: afaik he is Italian so he'll probably not understand you, when you talk german.
bearhas left
LNJhas joined
emusWas early, somehow I took it for German, and the rest if it as an English quote, like:
Hmm was? "WebSocket forgot on purpose?"
now its more clear^^
Maranda. . .
!XSF_Martin😂
DanielWas are you taking about?
!XSF_MartinDas should be clear now!
Jeybehas left
Jeybehas joined
LNJhas left
Zashhas left
Zashhas joined
LNJhas joined
Danielhas left
Danielhas joined
flowDie Bart, Die
emusDaniel: Misunderstanding, nevermind
debaclehas joined
debaclehas left
debaclehas joined
werdanhas joined
debaclehas left
bearhas joined
debaclehas joined
debaclehas left
mukt2has joined
debaclehas joined
debaclehas left
debaclehas joined
debaclehas left
Danielhas left
Danielhas joined
debaclehas joined
mukt2has left
debaclehas left
debaclehas joined
debaclehas left
serge90has joined
debaclehas joined
bearhas left
debaclehas left
debaclehas joined
Danielhas left
Danielhas joined
Steve Killehas left
Danielhas left
Danielhas joined
Steve Killehas joined
Danielhas left
Danielhas joined
xsfhas left
goffihas joined
Jeybehas left
werdanhas left
lovetoxhas left
Jeybehas joined
sonnyhas left
lovetoxhas joined
j.rhas left
!XSF_Martinhas left
j.rhas joined
!XSF_Martinhas joined
bearhas joined
sonnyhas joined
j.rhas left
j.rhas joined
bearhas left
andrey.ghas left
andrey.ghas joined
neshtaxmpphas joined
pdurbinhas left
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
werdanhas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
goffihas left
goffihas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
bearhas joined
toystoryhas joined
mukt2has joined
serge90has left
serge90has joined
toystoryhas left
j.rhas left
j.rhas joined
mukt2has left
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
moparisthebesthas joined
bearhas left
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
Danielhas left
Danielhas joined
calvinhas joined
Danielhas left
Danielhas joined
Shellhas joined
krauqhas left
krauqhas joined
Shellhas left
Shellhas joined
bearhas joined
mukt2has joined
adiaholic_has left
mukt2has left
bearhas left
rionhas left
rionhas joined
pdurbinhas joined
pdurbinhas left
serge90has left
serge90has joined
waqashas joined
waqashas left
lovetoxhas left
lovetoxhas joined
bearhas joined
bearhas left
adiaholic_has joined
Maxhas left
Maxhas joined
jonas’fun
jonas’XEP-0191 says to discover support on the server, not on the account.
jonas’which is kind of meh if the feature isn’t offered on all accounts
jonas’it’s in Draft. do we want to fix this?
DanielYes
jonas’alright, drafting a PR
DanielAnd/or offering on the server could maybe mean something different if you are the admin of that server
jonas’the yaks, they need shaving
ZashLike the hack I wrote where if a service admin blocks a bare host JID, s2s to/from that server is blocked?
DanielFor example
ZashI wouldn't mind 191 in MUCs (and MIX?) either.
ZashWhere's the XEP that descibes versioned namespaces?
ZashSurely it's not just a ProtoXEP in Inbox? https://xmpp.org/extensions/inbox/nsver.html
ZashCan't find anything with "namespace" or "version*" in the title tho
jonas’probably XEP-0001 or XEP-0143?
LNJhas left
jonas’there we go: https://github.com/xsf/xeps/pull/924
LNJhas joined
ZashLots of old things only advertise on the host JID
DanielI think in general it should be announced on the jid you'll end up talking to
ZashAgree. Historical things tho.
jonas’neat, prosody only advertises it on the domain
ZashWhat's that, Prosody follows the specification? Oh no!
jonas’no wait
jonas’that’s me not having it loaded in my e2etest prosody
DanielFor most things I just check both in Conversations 🤷♂️
jonas’still not offered on the account though :(
paulhas left
jonas’Daniel, fun fact, in openfire you may end up with a situation where the feature is advertised on the domain, but you can’t use it because it’s not enabled for your account.
Zashjonas’: Prosody does what the current version of the XEP says, and it says to advertise on the host but you talk to the no-to/own account JID
adiaholic_has left
adiaholic_has joined
jonas’Zash, not complaining
jonas’just unhappy that I can’t resolve the issue I’m facing in any way right now
ZashWrite a 3 line module for it :P
jonas’Zash, that doesn’t solve the actual issue (broken XEP-0191)
ZashFun
Shellhas left
Shellhas joined
paulhas joined
bearhas joined
adiaholic_has left
adiaholic_has joined
Marandahas left
davidhas left
Shellhas left
Shellhas joined
bearhas left
Guushas left
Guushas joined
pdurbinhas joined
Wojtekhas joined
Nekithas left
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
pdurbinhas left
Marandahas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
calvinhas left
calvinhas joined
davidhas joined
Shellhas left
Shellhas joined
werdanhas left
mukt2has joined
bearhas joined
lorddavidiiihas left
lorddavidiiihas joined
mukt2has left
Danielhas joined
bearhas left
paulhas left
paulhas joined
paulhas left
marchas left
paulhas joined
etahas left
etahas joined
Wojtekhas left
Shellhas left
Shellhas joined
Wojtekhas joined
Shellhas left
Shellhas joined
Nekithas joined
Wojtekhas left
Wojtekhas joined
Wojtekhas left
archas joined
MarandaI'm not sure what I do either...
Maranda(for xep-0191)
Marandahost disco#info together with the deprecated privacy lists
mukt2has joined
andrey.ghas left
bearhas joined
marchas joined
Danielhas left
Danielhas joined
mukt2has left
Sevehas left
Yagizahas left
Sevehas joined
bearhas left
pdurbinhas joined
calvinhas left
calvinhas joined
Danielhas left
Danielhas joined
Wojtekhas joined
Danielhas left
Danielhas joined
flowZash> Lots of old things only advertise on the host JID
which is often the way to go IMHO
ZashAdvertising on the JID you talk to seems the sensible thing.
flowZash, makes it harder to get a survey which features are actually implemented, and I don't see an advantage
ZashOTOH, the caps has you can send in stream:features doesn't cover features on your account.
jonas’flow, the advantage is that a feature can be offered on a per-account basis
jonas’without having to do terrible things to your disco#info handlers ;)
flowI also think that the semantic of a feature annoucement is "this implementation does implement this feature", not "this feature is provided to your account"
flowjonas’, I do not think that this is true
Marandaand the use case of not providing blocking command to certain accounts is...?
Marandaand the advantage of not providing blocking command to certain accounts is...?
flowMaranda, I do not think that it is sensible to discuss specific extensions at this stage
Marandaflow, but the whole discussion was about blocking command in the first place
andrey.ghas joined
pdurbinhas left
flowMaranda, right, but it is something we should discuss in general
flowbecause it is *everywhere* in xmpp
flowand the discussion also appears every 2-3 years
flowand the discussion where to announce features also appears every 2-3 years
kevinhas joined
kevinhas left
ZashLet's schedule a 2-day discussion of it at Summit 2022 then!
ZashThe Final Discussion
Marandawell flow while I see the benefit for other things, I think that extensions that sensibly shouldn't be offered on a per-account basis just should end with the features on the host.
krauqhas left
goffihas left
goffihas joined
flowMaranda, I think there is some misunderstanding? I am also arguing in favor of annoucing features on the host (but for a different reason)
archas left
archas joined
archas left
archas joined
werdanhas joined
Marandaflow, I don't think there's any misunderstanding tbh, just explaining why my comment wasn't completely... "unsensible", imho.
kevinhas joined
flowMaranda, from PoV it is unsensible because I don't think that you can ever be 100% sure that a given feature will *always* provided to *all* users
flowMaranda, from my PoV it is unsensible because I don't think that you can ever be 100% sure that a given feature will *always* provided to *all* users
kevinhas left
flowbut since I don't think that disco#info features are there to tell you if you are allowed to use a certain feature…
Marandaditto
lovetoxflow but then you have terible discovery of what you are allowed to use
lovetoxand thats what clients need everyday, compared to survey bots that look what server implement these days
lovetoxand thats about the only usecase i see for announcing anything on the host
lovetoxso in light that there is no perfect solution, lets go with what is needed by most people
flowlovetox, yes I think we are really bad when it comes to discovering if one is allowed to perform action X. Just look at muc room creation for example
flowbut, annoucing a feature of muc#room_creation_allowed on the MUC jid is probably a terrible idea
flowespecially if it is returned depending on the entity which queries
APachhas left
APachhas joined
flowdisco#info results should not differ depending on the entity which issued the request
lovetoxwhy?
flowwell caps for one
lovetoxthats all? because that does not seem like such a big problem
lovetox1. we have no caps for host anyway
flowI think it is in general a bad pattern
lovetox2. for muc service also not
flowplus if you do it there, people will think it is a good idea to do the same with entities that broadcast caps
lovetoxyeah i agree flow, but in the absence of something better
lovetoxwe have to use whats there
Zashcaps from the host can be in <stream:features>
flowbesides, if we further assume that "you are allowed to perform action X" may change over time, one may want a push mechanism for that, to inform clients
andrey.ghas left
Zashlike, an authz error reply if you try isn't enough?
flowlovetox, I'd argue we use the force of XMPPs extensibility to create something suitable
lovetoxflow we dont have caps for host and services, so on every new start of a client you have to query anyway
flowZash, it is in most cases I think
jubalhhas left
calvinhas left
lovetoxand services and host dont change account features on a daily basis
flowZash, after all xep45 says not-allowed on room creation attempt, and I haven't heard someone asking for a feature to discover if an entity is allowed to create a room prior room creation
lovetoxso we can live with it
flowthat doesn't mean that something like that wouldn't be nice to have
flowthat doesn't mean that something like that wouldn't be nice to have though
flowlovetox, as Zash said, we do have caps on xmpp services
ZashBut no caps for your own account features. :/
adiaholic_has left
adiaholic_has joined
flowZash, right, but I really think this shouldn't be called features then, but instead maybe "capabilities" (or something)
bearhas joined
ZashI mean as in disco#info
krauqhas joined
MarandaZash, but if you advertise only on stream features clients will have to cache caps? (not that possibly they don't do that already)
flowZash, I know, and I mean that I think the mechanism to discover if you are allowed to perform action X should potentially not be build upon disco#info features
lovetoxi feel its really late to discover this now
Zashflow: Makes sense.
lovetoxand there is no pressing issue to change what we currently do
lovetoxbad pattern is not a big motivation
MarandaI'm not sure why presenting errors to users should be such a bad thing, beside most clients aren't using human readable conditions.
MarandaI'm not sure why presenting errors to users should be such a bad thing, beside that most clients not using human readable conditions.
flowMaranda, irregardless, it would be nice if we could do better, no?
MarandaAnd checking everytime to prevent errors being thrown, doesn't sound very good practice wise.
Marandaflow, doing better is nice but I don't think this is the bit that should be modified tbh.
MarandaThat's all.
Marandaor s/that should/that needs to/
ZashSomeone invent authzcaps
ZashRelated wishlist: Separate pure machine-readable features from strings like identity names that can be customized and vary per client or deployment.
sonnyhas left
andrey.ghas joined
waqashas joined
pep.MattJ, re RAI, to unsubscribe you must send an unavailable presence to the MUC service, so that's after the first unavailable presence to leave the MUC?
pep.Or can I just declare an interest to any MUC even if I've never joined them at all
alexishas left
pep.Also maybe the NS can be updated to something not xmpp:prosody.im
bearhas left
Zashpep.: Isn't that up to the editors?
pep.the ns?
pep.To update it?
ZashYeah. At least when a ProtoXEP is accepted as Experimental
etawait what's RAI
ZashI might be using a private ns for my half-done proposal things
pep.It's the first time during "editor career" that I come across a protoXEP that uses non-urn:xmpp ns
pep.eta, it's at the PR stage for now, future protoXEP
etapep.: link?
jonas’oh sexy, I should port my biboumi MR to that at some point
pep.Zash, but I think you're right in that you're not technically allowed to use urn:xmpp as long as it's not a XEP. But I find it silly to not allow this in protoXEPs
MattJpep.: I don't understand your question about unavailable presence
paulhas left
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
paulhas joined
etawhat's its intended usecase?
MattJThe intended use case is stated in the intro and repeated elsewhere in the document
MattJE.g. requirements
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?
krauqhas left
MattJProbably not
krauqhas joined
pep.Can I also initiate rai when joined?
MattJYes
pep.What happens when I leave the room, does that also cancel rai?
MattJNo
ZashMUC service = bare host JID of the MUC?
MattJYes
pep.why?
MattJWhy not?
pep.because this has proved to cause weird issues in the past, and it works just fine addressing the room directly
MattJWhich room?
pep.a room
ZashAs punishment for whoever decided that room@host could be a MUC service?
pep.any room
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 :)
Bronwenhas joined
Bronwenhas left
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
MattJNo?
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
pep.(proto, whatever)
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.I see
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?
marchas left
paulhas left
marchas joined
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)
bearhas joined
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?
adiaholic_has left
adiaholic_has joined
pep.Well it's already being done in implementations having to know what a "relevant" message is, I don't see why not
ZashHas <body>
There, done.
mukt2has joined
pep.:)
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
pep.has left
paulhas joined
mukt2has left
pep.has joined
werdanhas left
MattJZash: nice list of mostly XEPs written by me :)
Zashhas left
MattJBecause yes, I do believe in defining what's necessary for interop and no more - at least in the early stages
Zashhas joined
pdurbinhas joined
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..
lovetoxhas left
pep.carbons has some kind of rules right?
pep.CSI?
MattJNo, this is a protocol for telling the client to tell the user that something happened in the room
pep.Anything?
MattJIf the server thinks an affiliation change is important to that user, it should be allowed to send them a notification
Nekithas left
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.
pdurbinhas left
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 :)