-
Maranda
Hmm was WebSocket forgot on purpose? šØāš»š¤
-
emus
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
-
Syndace
what xD
-
Syndace
Yeah Maranda, stop speaking such unclear german!!!
-
!XSF_Martin
emus: afaik he is Italian so he'll probably not understand you, when you talk german.
-
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!
-
flow
Die Bart, Die
-
emus
Daniel: Misunderstanding, nevermind
-
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?
-
jonasā
there we go: https://github.com/xsf/xeps/pull/924
-
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 :(
-
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
-
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
-
Maranda
I'm not sure what I do either...
-
Maranda
(for xep-0191)
-
Maranda
host disco#info together with the deprecated privacy lists
-
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
-
flow
Maranda, right, but it is something we should discuss in general
-
flow
because it is *everywhere* in xmpp
-
flow
and the discussion also appears every 2-3 years✎ -
flow
and the discussion where to announce features also appears every 2-3 years ✏
-
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.
-
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)
-
Maranda
flow, I don't think there's any misunderstanding tbh, just explaining why my comment wasn't completely... "unsensible", imho.
-
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 ✏
-
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
-
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
-
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
-
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. :/
-
flow
Zash, right, but I really think this shouldn't be called features then, but instead maybe "capabilities" (or something)
-
Zash
I mean as in disco#info
-
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.
-
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
-
pep.
Also maybe the NS can be updated to something not xmpp:prosody.im
-
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
-
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
-
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?
-
MattJ
Probably not
-
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 :)
-
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?
-
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)
-
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?
-
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.
-
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
-
MattJ
Zash: nice list of mostly XEPs written by me :)
-
MattJ
Because yes, I do believe in defining what's necessary for interop and no more - at least in the early stages
-
MattJ
Things can always be tightened up later based on implementation experience, or requirements for specific deployments
-
MattJ
As long as the semantics are well definee✎ -
MattJ
As 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
-
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..
-
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
-
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.
-
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 :)
-
Zash
haha
-
pep.
:P