XSF Discussion - 2024-08-23

singpolyma, would be very interesting to switch easily from xmpp client, eg from iphone/android, or macos/linux/win/bsd etc...

lm2lm2: wait, same account? You already can, that's a core part of XMPP

You can use multiple different clients at the same time even and all your contacts/messages/etc will be on all of them

moparisthebest: simultaneously yes, but switch (and keep eg message history, keys, etc) no

Yes, as long as you aren't using OMEMO

If your server has infinite mam you mean?

there are server's without infinite MAM ? 😱

Most of them, unfortunately

to suddenly change topics... does anyone know of any implementations of https://xmpp.org/extensions/xep-0451.html (mux) ?

I can't find evidence that prosody ( https://prosody.im/doc/xeplist / https://modules.prosody.im/ ) or ejabberd ( https://www.process-one.net/en/ejabberd/protocols/ ) do, but that doesn't mean much

it strikes me as odd that the initiating entitity is the one to generate the secret, feels backwards, any thoughts ?

now that I think about it, is the key needed at all ?

if your verified connection to rooms.capulet.example says you can send it messages over your connection to capulet.example instead, and your verified connenction to capulet.example has already told you it can handle stanzas for rooms.capulet.example, why is there any handshake/secret needed at all ?

> wishes to send stanzas to another server that was listed in the original servers post-auth <mux/> stream feature I think I meant this to be for when the server didn't list all its domains and the new server lists the one you already have a connection with. The quoted bit is just incorrect. The first sentence in this section seems to contradict it, anyways. But I don't really remember.

I suppose the server could generate the secret too, it would just require a tiny bit of extra work because the client would have to send the host, then the new server would have to send the secret back

I was going to propose the (recieving) server generating the secret but now I'm thinking there is no need for a secret at all ✏

If only one server lists its hosts you'd need it, otherwise you're right. But we could probably just get rid of support for the pre-auth thing that doesn't list hosts too

Although I have a vague feeling that was for an actual use case, but I can't think what that could have been now.

Need someone to implement it so we can find out 🙂

I'd prefer to implement it without the secret unless there's a good reason for it

I guess if there aren't current implementations there'd be no downside to bumping to a :1

lastly I don't see it explicitly say but if capulet.example says: <mux xmlns='urn:xmpp:mux:0'> <host>capulet.example</host> <host>montague.example</host> <host>chat.montague.example</host> <host>rooms.capulet.example</host> </mux> and it's cert is valid for rooms.capulet.example... you can just start sending stanzas right? no need to tell it you want to first ? ✏

lastly I don't see it explicitly say but if capulet.example says: <mux xmlns='urn:xmpp:mux:0'> <host>capulet.example</host> <host>montague.example</host> <host>chat.montague.example</host> <host>rooms.capulet.example</host> </mux> and it's cert is valid for rooms.capulet.example... you can just start sending stanzas for rooms.capulet.example right? no need to tell it you want to first ? ✏

Oh, wait, the empty list means it's in a valid cert. Yah, I have no idea why the key thing was included.

Yah, after the session is established you can just use "from" and send for anything that was valid

Sam, what do you think about me creating an PR bumping it to :1 and removing all secret stuff, just spelling out how to do it in both cases of cert-is-valid-for-all and need-to-connect-to-new-destination-to-make-sure-mux-host-allowed ?

Sounds good to me. I wish I remembered why it was in there first, but it may have just been a dumb mistake. I'll think about it more in the morning.

I'm not going to make it tonight anyway so let me know if you can think of one...

I wonder if it was for the sake of hosting providers. Ie. conversations.im probably doesn't want to reveal a list of every single domain it hosts so if you connect to conversations.im it might just want to list muc.conversations.im or what not but not list samscustomdomain.example.com. But then you connect to samscustomdomain later, it advertises conversations.im and isnce you already have an existing connection there you could do the secret flow.

ah interesting, yea I gotta think about this

ok so, off the top of my head: scenario 1: you connect+authenticate+validate to conversations.im, it sends: <mux xmlns='urn:xmpp:mux:0'> <host>muc.conversations.im</host> </mux> 1. it's cert is valid for both conversations.im & muc.conversations.im, so you just immediately start sending stanzas destined to either over this connection without further connections/negotiation/validation 2. it's cert is valid for only conversations.im and not muc.conversations.im, you only send stanzas destined for conversations.im over this ignoring the muc.conversations.im like it doesn't exist scenario 2: you connect+authenticate+validate to alice.com, it sends: <mux xmlns='urn:xmpp:mux:0'> <host>conversations.im</host> <host>muc.conversations.im</host> </mux> 1. you see you already have a valid connection to 1 of these and decide to re-use it (you could iterate over them until you get a successful response to 2) 2. you send an iq to your existing connection to conversations.im that says "hey alice.com said I could send stanzas for it to you instead is that cool?" and conversations.im responds either "sure that's fine" in which case you start sending them and close alice.com connection, or "wtf no" in which case you (iterate over the rest you have a connection to or) just stay connected to alice.com and send them stanzas directly which still doesn't require a secret imho, but does require the "is it ok to send you stanzas for alice.com" IQ, does this sound right ?

Guus, is there a reason https://github.com/xsf/xeps/pull/1358 is marked as draft?

the draft label is why I haven’t brought this to council yet

and I simply forgot #1370

> Guus, is there a reason https://github.com/xsf/xeps/pull/1358 is marked as draft? That is because I still need to check if the changes are 'complete'. There may be similar changes needed in other parts of the XEP.

ok

I wonder if https://github.com/xsf/xeps/pull/1376 can be simply editorial. I’d be surprised if anyone ever interpreted the xep differently

i mean i don’t mind adding the note; but i think it was clear enough before

> this prevents the client from being unable to use stream management at all Isn't there one negation too many?

i don’t think so. if the server were to respond with failed the client would be unable to use stream managment. this prevents this

could this be worded better? maybe. but i don’t have a suggestion

personally, I'd rather go with an example of an enable without resumptionability.

ukko: thanks, I'll fix that soon

Wording suggestion: > [..] As a client can only make at most one attempt to enable stream management, this allows the client to use the Acks subset of the stream management features.

sounds good. both that wording and adding an example

also it looks like §3 and §5 are sharing a bunch of examples and have similar but not identical wording?

I already wondered why the enable part is documented under §5 Resumption.

Probably because resumption was considered an addon

So the entire section was added

But yes like I said I don't think this was ever really unclear

It may be unclear if you only read the resumption part

example 3 actually contains enabling SM without resumption.

yeah.

But not if you read the full spec and consider it an addon

Maybe the duplication should be removed from §5 then?

I'd rather not do major changes to the spec

upon reading it again i don’t think an example is necessary at this point

but a note that basically acts as a reminder that we are in fact negotiating an optional feature doesn’t hurt

yeah, that's probably the least invasive way to handle that.

I do think it's a bit unclear in the original text (hence my suggestion to modify it). Particularly asking for something, and getting a positive response that doesn't grant you everything that had been asked for is a bit of an outlier. Additional text there is helpful in my opinion.

MattJ: for https://xmpp.org/extensions/inbox/xep-client-access-management.html I have two questions: 1) Why not use a well-known adhoc command (as we do for eg invites), I suppose primarily because we don't currently have a good way for lists to include structured data and/or to allow a user to choose from a table so it would be a bit annoying to use with a generic client until one of those is solved? 2) What is the logic on attributes vs children here? connected=true and even an empty element <permission status="unrestricted"/> but otherwise seems to be using children for data?

1) yes, exactly. Ad-hoc was of course considered, but as you can see this is deeply structured and I think there is benefit to using traditional syntax and extensibility rules here

2) in the case of permissions, the child content is defined to contain details of the permissions themselves, while the attribute is a high-level version of the content that clients can understand if they don't understand anything else

are there any such details specced here? it looks like it is left empty basically for extension?

In the case of session@connected I'm open to moving it elsewhere

But don't see a strong need to

Yes, not currently specified. I had some in-progress stuff related to that but it's not ready for publication

Like letting you see what OAuth scopes were granted

I mean, certainly not a *strong* need to but I'm just not sure why connected is materially different from the other data included in children (unlike eg id and type which are metadata about the data in the children and thus make sense in attributes to me)

https://xmpp.org/extensions/inbox/xep-oauth-client-login.html scope xmpp:client:normal may be restricted from some sensitive operations. Would it be sane to define a xmpp:client:full or you think it would be better to define special scopes for any particular sensitive operations as they come up? What is the goal of xmpp:account:read ? It can read rsoter, pep nodes, and "profile information" (I guess still that's pep nodes) but not mam?

I observe that our prototype implementation uses a scope `xmpp` that means whatever the user currently has access to.

To get to OIDC from here what is actually required extra? Support the OIDC discovery endpoint (as an alias to the oauth endpoint), support the openid scope, support the "who am I" OIDC question. That's is, yeah?

I understand that's out of scope, just thinking about it

singpolyma, yes (and our prototype implements that)

I get the impression that our prototype is probably the most complete OAuth2 implementation in existence :)

But then not many things support OIDC/OAuth2 discovery, or especially not the dynamic client registration. Usually you manually register a client with endpoints in some admin web interface.

Zash: looke like the prototype lacks an OIDC discovery alias, but otherwise cool

Yeah, it follows RFCs more closely than OIDC ✏

I guess you could trivially add an alias of sorts.

Right, an alias would be needed for OIDC compatibility

of couse one couse do that in their reverse proxy or whatever as well I guess

But then it's missing other mandatory OIDC things that seems overkill, like putting JWTs everywhere

hello

hello... with email client, it could happen that thund/outlook add the IP of the sender ; i just wonder : with xmpp, does a direct PM permits to discover the source IP or only the server knows it?

lm2lm2: only the sender's server knows

Which may or may not be the same as your server

ok. so if i use jabber.org, only the jabber server can know what is my ip, not other's jabber.org users

Yes

There is an exception, certain file sharing methods and audio/video calling will tell your contact your IP

(You need to accept or initiate the audio/video call for them to get the IP. Not sure what happens when someone tries sending you a file with jingle)

i understand..

it was for being sure