XSF Discussion - 2020-04-13

Hmm was WebSocket forgot on purpose? 👨‍💻🤔

Maranda: Du musst dich klarer ausdrücken und am besten auf englisch. sonst geh mal hier hin:

xmpp:xmpp-de@conference.conversations.im?join

what xD

Yeah Maranda, stop speaking such unclear german!!!

emus: afaik he is Italian so he'll probably not understand you, when you talk german.

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^^

. . .

😂

Was are you taking about?

Das should be clear now!

Die Bart, Die

Daniel: Misunderstanding, nevermind

fun

XEP-0191 says to discover support on the server, not on the account.

https://xmpp.org/extensions/xep-0191.html#disco

which is kind of meh if the feature isn’t offered on all accounts

it’s in Draft. do we want to fix this?

Yes

alright, drafting a PR

And/or offering on the server could maybe mean something different if you are the admin of that server

the yaks, they need shaving

Like the hack I wrote where if a service admin blocks a bare host JID, s2s to/from that server is blocked?

For example

I wouldn't mind 191 in MUCs (and MIX?) either.

Where's the XEP that descibes versioned namespaces?

Surely it's not just a ProtoXEP in Inbox? https://xmpp.org/extensions/inbox/nsver.html

Can't find anything with "namespace" or "version*" in the title tho

probably XEP-0001 or XEP-0143?

there we go: https://github.com/xsf/xeps/pull/924

Lots of old things only advertise on the host JID

I think in general it should be announced on the jid you'll end up talking to

Agree. Historical things tho.

neat, prosody only advertises it on the domain

What's that, Prosody follows the specification? Oh no!

no wait

that’s me not having it loaded in my e2etest prosody

For most things I just check both in Conversations 🤷‍♂️

still not offered on the account though :(

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.

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

Zash, not complaining

just unhappy that I can’t resolve the issue I’m facing in any way right now

Write a 3 line module for it :P

Zash, that doesn’t solve the actual issue (broken XEP-0191)

Fun

I'm not sure what I do either...

(for xep-0191)

host disco#info together with the deprecated privacy lists

Zash> Lots of old things only advertise on the host JID which is often the way to go IMHO

Advertising on the JID you talk to seems the sensible thing.

Zash, makes it harder to get a survey which features are actually implemented, and I don't see an advantage

OTOH, the caps has you can send in stream:features doesn't cover features on your account.

flow, the advantage is that a feature can be offered on a per-account basis

without having to do terrible things to your disco#info handlers ;)

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"

jonas’, I do not think that this is true

and the advantage of not providing blocking command to certain accounts is...? ✏

Maranda, I do not think that it is sensible to discuss specific extensions at this stage

flow, but the whole discussion was about blocking command in the first place

Maranda, right, but it is something we should discuss in general

because it is *everywhere* in xmpp

and the discussion where to announce features also appears every 2-3 years ✏

Let's schedule a 2-day discussion of it at Summit 2022 then!

The Final Discussion

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.

Maranda, I think there is some misunderstanding? I am also arguing in favor of annoucing features on the host (but for a different reason)

flow, I don't think there's any misunderstanding tbh, just explaining why my comment wasn't completely... "unsensible", imho.

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 ✏

but since I don't think that disco#info features are there to tell you if you are allowed to use a certain feature…

ditto

flow but then you have terible discovery of what you are allowed to use

and thats what clients need everyday, compared to survey bots that look what server implement these days

and thats about the only usecase i see for announcing anything on the host

so in light that there is no perfect solution, lets go with what is needed by most people

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

but, annoucing a feature of muc#room_creation_allowed on the MUC jid is probably a terrible idea

especially if it is returned depending on the entity which queries

disco#info results should not differ depending on the entity which issued the request

why?

well caps for one

thats all? because that does not seem like such a big problem

1. we have no caps for host anyway

I think it is in general a bad pattern

2. for muc service also not

plus if you do it there, people will think it is a good idea to do the same with entities that broadcast caps

yeah i agree flow, but in the absence of something better

we have to use whats there

caps from the host can be in <stream:features>

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

like, an authz error reply if you try isn't enough?

lovetox, I'd argue we use the force of XMPPs extensibility to create something suitable

flow we dont have caps for host and services, so on every new start of a client you have to query anyway

Zash, it is in most cases I think

and services and host dont change account features on a daily basis

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

so we can live with it

that doesn't mean that something like that wouldn't be nice to have though ✏

lovetox, as Zash said, we do have caps on xmpp services

But no caps for your own account features. :/

Zash, right, but I really think this shouldn't be called features then, but instead maybe "capabilities" (or something)

I mean as in disco#info

Zash, but if you advertise only on stream features clients will have to cache caps? (not that possibly they don't do that already)

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

i feel its really late to discover this now

flow: Makes sense.

and there is no pressing issue to change what we currently do

bad pattern is not a big motivation

I'm not sure why presenting errors to users should be such a bad thing, beside that most clients not using human readable conditions. ✏

Maranda, irregardless, it would be nice if we could do better, no?

And checking everytime to prevent errors being thrown, doesn't sound very good practice wise.

flow, doing better is nice but I don't think this is the bit that should be modified tbh.

That's all.

or s/that should/that needs to/

Someone invent authzcaps

Related wishlist: Separate pure machine-readable features from strings like identity names that can be customized and vary per client or deployment.

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?

Or can I just declare an interest to any MUC even if I've never joined them at all

Also maybe the NS can be updated to something not xmpp:prosody.im

pep.: Isn't that up to the editors?

the ns?

To update it?

Yeah. At least when a ProtoXEP is accepted as Experimental

wait what's RAI

I might be using a private ns for my half-done proposal things

It's the first time during "editor career" that I come across a protoXEP that uses non-urn:xmpp ns

eta, it's at the PR stage for now, future protoXEP

pep.: link?

oh sexy, I should port my biboumi MR to that at some point

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

eta, https://github.com/xsf/xeps/pull/925/files

pep.: I don't understand your question about unavailable presence

I don't understand under what condition I can use RAI.

(or not use it)

And under what condition I can unset it

what's its intended usecase?

The intended use case is stated in the intro and repeated elsewhere in the document

E.g. requirements

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?

Probably not

Can I also initiate rai when joined?

Yes

What happens when I leave the room, does that also cancel rai?

No

MUC service = bare host JID of the MUC?

Yes

why?

Why not?

because this has proved to cause weird issues in the past, and it works just fine addressing the room directly

Which room?

a room

As punishment for whoever decided that room@host could be a MUC service?

any room

You want rai for multiple rooms just send that to multiple rooms?

Read the requirements

What if I want rai for all rooms minus one

There aren't many

I kinda think it's meh to assume nowadays that bare host is a muc component

Especially coming from prosody people :P

That's required by XEP-0045

There are many things that are addressed to the MUC service in XEP-0045

Also ad-hoc, etc.

ad-hoc on MUC is a thing in some implementation?

Ah biboumi maybe

Of course, why not?

I've been waiting for that in prosody. Actually that's wrong, I've been waiting for ad-hoc on rooms

Waiting? It can't be done now?

Anyway the unsubscribe thing is confusing

I only added it at the last minute for completeness

Anticipating that someone would say "but how do you unsubscribe?"

pep.: You'll have to wait for Prosodys ad-hoc to support commands on anything but host JIDs then.

Now it's confusing to be able to unsubscribe :)

Also "activity" doesn't seem very much defined

"there are new messages in a room since the last time the user was joined there"

"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

That seems a fine definition to me. Implementation specifics are indeed not defined, that's fairly intentional

I thought that was just another example of what it could be

No?

So 372 is mentioned for no reason?

It's an example

ok so it's all implementation defined :/

I really think you're missing the point of this

I'm trying to understand why it's useful, even more so now that you're saying it's implementation defined

Don't get me wrong it's not just this XEP

XEP-0372 is used for pushing notifications from a MUC to a user, about messages the MUC thinks the user should be notified about

(proto, whatever)

But there are messages where the user is not mentioned

hmm, shortcuts? 372 is used to find out who to notify via some other mechanism

and the user may still want to know whether there are any of those, or if the room has just been idle

I see

Makes a bit more sense

"A MUC may already send out-of-band notifications to users who are not currently joined if e.g. they are mentioned using &xep0372;."

"However a MUC typically won't forward other kinds of messages unless the user is joined."

^ Problem statement

Yeah.. we're all good at language all the time every time..

I'm still meh on the "implementation detail" thing, what is a "message" now :x

Which "implementation detail" thing?

"Implementation specifics are indeed not defined, that's fairly intentional"

What would you define?

Above what is already defined

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)

I guess you're not gonna send RIA for chatstates

So you want it to list every possible kind of message in the XEP? Every combination of payloads?

Well it's already being done in implementations having to know what a "relevant" message is, I don't see why not

Has <body> There, done.

:)

The Prosody implementation depends on MAM on the MUC room, and it's considered activity if it gets archived

which boils down to "has <body>"

So I could add a dependency on MAM, and basically spec this implementation

If there had to be such a XEP, I'd decouple it from MAM surely

But I don't want to do that, because I think that's a very rigid/brittle approach that would be too limiting

I think anyone who implements and deploys this would be able to make the right choice here

If they don't, their implementation is screwed up and they'll see that

But still, no harm done otherwise

Specs matter for interoperability, this isn't an interop issue

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

Is this about to become another of those things like carbons, mam, csi etc where people disagree on how strict the rules should be?

It works in closed environments where you're only gonna use one implementation anyway

Zash, looks like the same problem to me

Someone™ should write down some guidance, either in xep-0226 or some new XEP.

Anyway.. afk rebooting server

Zash: nice list of mostly XEPs written by me :)

Because yes, I do believe in defining what's necessary for interop and no more - at least in the early stages

Things can always be tightened up later based on implementation experience, or requirements for specific deployments

As long as the semantics are well defined ✏

well I don't think they are, well-defined semantics here would be defining "relevant" I'd say

I also like to believe that most developers do have common sense

I don't recall off-hand if MAM provides guidelines at least? or carbons or..

carbons has some kind of rules right?

CSI?

No, this is a protocol for telling the client to tell the user that something happened in the room

Anything?

If the server thinks an affiliation change is important to that user, it should be allowed to send them a notification

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

Then feel free to not deploy it, but I'm deploying this next week

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.

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 :)

haha

:P