Maranda: Du musst dich klarer ausdrücken und am besten auf englisch. sonst geh mal hier hin:
emus
xmpp:xmpp-de@conference.conversations.im?join
Danielhas joined
andyhas joined
Jeybehas joined
bearhas joined
mukt2has joined
emushas left
Syndace
what xD
emushas joined
Syndace
Yeah Maranda, stop speaking such unclear german!!!
lovetoxhas joined
mukt2has left
j.rhas left
j.rhas joined
!XSF_Martin
emus: afaik he is Italian so he'll probably not understand you, when you talk german.
bearhas left
LNJhas joined
emus
Was 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
😂
Daniel
Was are you taking about?
!XSF_Martin
Das should be clear now!
Jeybehas left
Jeybehas joined
LNJhas left
Zashhas left
Zashhas joined
LNJhas joined
Danielhas left
Danielhas joined
flow
Die Bart, Die
emus
Daniel: 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’
https://xmpp.org/extensions/xep-0191.html#disco
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?
Daniel
Yes
jonas’
alright, drafting a PR
Daniel
And/or offering on the server could maybe mean something different if you are the admin of that server
jonas’
the yaks, they need shaving
Zash
Like the hack I wrote where if a service admin blocks a bare host JID, s2s to/from that server is blocked?
Daniel
For example
Zash
I wouldn't mind 191 in MUCs (and MIX?) either.
Zash
Where's the XEP that descibes versioned namespaces?
Zash
Surely it's not just a ProtoXEP in Inbox? https://xmpp.org/extensions/inbox/nsver.html
Zash
Can'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
Zash
Lots of old things only advertise on the host JID
Daniel
I think in general it should be announced on the jid you'll end up talking to
Zash
Agree. Historical things tho.
jonas’
neat, prosody only advertises it on the domain
Zash
What's that, Prosody follows the specification? Oh no!
jonas’
no wait
jonas’
that’s me not having it loaded in my e2etest prosody
Daniel
For 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.
Zash
jonas’: 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
Zash
Write a 3 line module for it :P
jonas’
Zash, that doesn’t solve the actual issue (broken XEP-0191)
Zash
Fun
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
Maranda
I'm not sure what I do either...
Maranda
(for xep-0191)
Maranda
host 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
flow
Zash> Lots of old things only advertise on the host JID
which is often the way to go IMHO
Zash
Advertising on the JID you talk to seems the sensible thing.
flow
Zash, makes it harder to get a survey which features are actually implemented, and I don't see an advantage
Zash
OTOH, 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 ;)
flow
I also think that the semantic of a feature annoucement is "this implementation does implement this feature", not "this feature is provided to your account"
flow
jonas’, I do not think that this is true
Maranda
and the use case of not providing blocking command to certain accounts is...?✎
Maranda
and the advantage of not providing blocking command to certain accounts is...? ✏
flow
Maranda, I do not think that it is sensible to discuss specific extensions at this stage
Maranda
flow, but the whole discussion was about blocking command in the first place
andrey.ghas joined
pdurbinhas left
flow
Maranda, right, but it is something we should discuss in general
and the discussion where to announce features also appears every 2-3 years ✏
kevinhas joined
kevinhas left
Zash
Let's schedule a 2-day discussion of it at Summit 2022 then!
Zash
The Final Discussion
Maranda
well 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
flow
Maranda, 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
Maranda
flow, I don't think there's any misunderstanding tbh, just explaining why my comment wasn't completely... "unsensible", imho.
kevinhas joined
flow
Maranda, 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✎
flow
Maranda, 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
flow
but since I don't think that disco#info features are there to tell you if you are allowed to use a certain feature…
Maranda
ditto
lovetox
flow but then you have terible discovery of what you are allowed to use
lovetox
and thats what clients need everyday, compared to survey bots that look what server implement these days
lovetox
and thats about the only usecase i see for announcing anything on the host
lovetox
so in light that there is no perfect solution, lets go with what is needed by most people
flow
lovetox, 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
flow
but, annoucing a feature of muc#room_creation_allowed on the MUC jid is probably a terrible idea
flow
especially if it is returned depending on the entity which queries
APachhas left
APachhas joined
flow
disco#info results should not differ depending on the entity which issued the request
lovetox
why?
flow
well caps for one
lovetox
thats all? because that does not seem like such a big problem
lovetox
1. we have no caps for host anyway
flow
I think it is in general a bad pattern
lovetox
2. for muc service also not
flow
plus if you do it there, people will think it is a good idea to do the same with entities that broadcast caps
lovetox
yeah i agree flow, but in the absence of something better
lovetox
we have to use whats there
Zash
caps from the host can be in <stream:features>
flow
besides, 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
Zash
like, an authz error reply if you try isn't enough?
flow
lovetox, I'd argue we use the force of XMPPs extensibility to create something suitable
lovetox
flow we dont have caps for host and services, so on every new start of a client you have to query anyway
flow
Zash, it is in most cases I think
jubalhhas left
calvinhas left
lovetox
and services and host dont change account features on a daily basis
flow
Zash, 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
lovetox
so we can live with it
flow
that doesn't mean that something like that wouldn't be nice to have✎
flow
that doesn't mean that something like that wouldn't be nice to have though ✏
flow
lovetox, as Zash said, we do have caps on xmpp services
Zash
But no caps for your own account features. :/
adiaholic_has left
adiaholic_has joined
flow
Zash, right, but I really think this shouldn't be called features then, but instead maybe "capabilities" (or something)
bearhas joined
Zash
I mean as in disco#info
krauqhas joined
Maranda
Zash, but if you advertise only on stream features clients will have to cache caps? (not that possibly they don't do that already)
flow
Zash, 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
lovetox
i feel its really late to discover this now
Zash
flow: Makes sense.
lovetox
and there is no pressing issue to change what we currently do
lovetox
bad pattern is not a big motivation
Maranda
I'm not sure why presenting errors to users should be such a bad thing, beside most clients aren't using human readable conditions.✎
Maranda
I'm not sure why presenting errors to users should be such a bad thing, beside that most clients not using human readable conditions. ✏
flow
Maranda, irregardless, it would be nice if we could do better, no?
Maranda
And checking everytime to prevent errors being thrown, doesn't sound very good practice wise.
Maranda
flow, doing better is nice but I don't think this is the bit that should be modified tbh.
Maranda
That's all.
Maranda
or s/that should/that needs to/
Zash
Someone invent authzcaps
Zash
Related 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
Zash
pep.: Isn't that up to the editors?
pep.
the ns?
pep.
To update it?
Zash
Yeah. At least when a ProtoXEP is accepted as Experimental
eta
wait what's RAI
Zash
I 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
eta
pep.: 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
pep.
eta, https://github.com/xsf/xeps/pull/925/files
MattJ
pep.: 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
eta
what's its intended usecase?
MattJ
The intended use case is stated in the intro and repeated elsewhere in the document
MattJ
E.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
MattJ
Probably not
krauqhas joined
pep.
Can I also initiate rai when joined?
MattJ
Yes
pep.
What happens when I leave the room, does that also cancel rai?
MattJ
No
Zash
MUC service = bare host JID of the MUC?
MattJ
Yes
pep.
why?
MattJ
Why not?
pep.
because this has proved to cause weird issues in the past, and it works just fine addressing the room directly
MattJ
Which room?
pep.
a room
Zash
As 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?
MattJ
Read the requirements
pep.
What if I want rai for all rooms minus one
MattJ
There 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
Zash
That's required by XEP-0045
MattJ
There are many things that are addressed to the MUC service in XEP-0045
MattJ
Also ad-hoc, etc.
pep.
ad-hoc on MUC is a thing in some implementation?
pep.
Ah biboumi maybe
MattJ
Of 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
MattJ
Waiting? It can't be done now?
pep.
Anyway the unsubscribe thing is confusing
MattJ
I only added it at the last minute for completeness
MattJ
Anticipating that someone would say "but how do you unsubscribe?"
Zash
pep.: You'll have to wait for Prosodys ad-hoc to support commands on anything but host JIDs then.
MattJ
Now 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
MattJ
That 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
MattJ
No?
pep.
So 372 is mentioned for no reason?
MattJ
It's an example
pep.
ok so it's all implementation defined :/
MattJ
I 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
MattJ
XEP-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)
MattJ
But 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
MattJ
and 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
MattJ
Which "implementation detail" thing?
marchas left
paulhas left
marchas joined
pep.
"Implementation specifics are indeed not defined, that's fairly intentional"
MattJ
What would you define?
MattJ
Above 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
MattJ
So 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
Zash
Has <body>
There, done.
mukt2has joined
pep.
:)
MattJ
The Prosody implementation depends on MAM on the MUC room, and it's considered activity if it gets archived
Zash
which boils down to "has <body>"
MattJ
So 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
MattJ
But I don't want to do that, because I think that's a very rigid/brittle approach that would be too limiting
MattJ
I think anyone who implements and deploys this would be able to make the right choice here
MattJ
If they don't, their implementation is screwed up and they'll see that
MattJ
But still, no harm done otherwise
MattJ
Specs 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
Zash
Is 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
Zash
Someone™ 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
MattJ
Zash: nice list of mostly XEPs written by me :)
Zashhas left
MattJ
Because yes, I do believe in defining what's necessary for interop and no more - at least in the early stages
Zashhas joined
pdurbinhas joined
MattJ
Things can always be tightened up later based on implementation experience, or requirements for specific deployments
well I don't think they are, well-defined semantics here would be defining "relevant" I'd say
MattJ
I 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?
MattJ
No, this is a protocol for telling the client to tell the user that something happened in the room
pep.
Anything?
MattJ
If 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
MattJ
Then feel free to not deploy it, but I'm deploying this next week
MattJ
There 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
MattJ
I 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 :)