XSF Discussion - 2023-11-08

Guys, for you, sip:tom@sip.domain.net and xmpp:joe@conversations.im , are DID, or URI ? Do you know examples of companies or organisations communicating with others ones, using them?

harold: Those are URIs, not DIDs. DIDs are of the form did:<method>:<method-specific-id>, where the method specific ID typically looks random (is a hash or public key) and not user friendly. XMPP and SIP (among others) use federated IDs, that typically have a user-friendly name and a domain name and some separators (e.g. name@domain, @name@domain or @name:domain). As those identifiers are protocol-specific, we need to prefix them with a protocol scheme to make them URIs, that's why we have xmpp:user@domain

Does the XSF have something like a resident cryptographer? I just heard about PQXDH and am wondering whether there's already plans to integrate it into OMEMO.

the question is why integrate into omemo instead of MLS?

imo of course

phryk: there's xmpp:e2ee@muc.xmpp.org?join, but people there would probably be around here too

MSavoritias fae.ve, hadn't heard about MLS before, but there doesn't seem to be an existing XEP for it – is that something that's being worked on?

Yes

afaik a xep for MLS is being worked on yes.

MLS is the encryption standard by IETF

Our mid-to-long term plan is to move to MLS

its a plan? i thought it was up in the air still?

not that i disagree

I mean plans can change obviously. But there seems to be a consensus to at least strongly explore a migration to MLS

MSavoritias fae.ve, it's as much a plan as I think you'll get at this point, it was generally agreed at the summit, I've seen no objections

nice. :D

It makes sense for a lot of reasons, at least for groups. I've seen suggestions that maybe we keep OMEMO for 1:1, but I think that's something that would be determined after implementation experience.

Is there an overview of MLS cryptographic properties? Like, the abstract already says it does some stuff around forward secrecy and post-compromise security, but especially metadata security and secrecy are things I'd like to see improved.

I guess it also depends a lot on how much adoption MLS sees outside xmpp. More adoption = more libraries = easier to adopt for us

yeah. probably not at the same time remove omemo

but i would definetily see why using MLS for everything would make it easier

assuming it has libraries

phryk, I think everything would be in the RFCs or linked from the working group page. There is some attention paid to metadata protection, but I don't know how much of that will carry over to XMPP.

Way I see it, it would be prudent to have some sort of post-quantum defense in XMPP in the next couple years and at least that long we'd still be primarily on OMEMO for E2EE. That sound about right?

Yes, nothing happens in the broader ecosystem within 2 years :)

That's about as long as a Debian release cycle

Well, sometimes there are surprises I get, but yeah, it's not just releasing a package, but a new standard after all. 🙂

So even if we implemented a change in all clients *today*, you're going to have people using yesterday's clients for years

true. but the thing is changing to PQXDH sounds like a backwards incompatible change

and we already have trouble getting clients to newer omemo

the MLS RFC is here btw https://datatracker.ietf.org/doc/rfc9420/

phryk, from my reading MLS does more about metadata protection than omemo

and it has post-compromise security

Mhh, I should probably at least start thinking about adding encryption scheme tiering with messages encouraging users to upgrade to newer/better schemes with a grace period to my fork of mod_e2e_policy…

the thing it doesnt have is deniability. but omemo doesnt have great deniability either

MSavoritias fae.ve, yeah, I have the spec open, but I was hoping for a more high-level overview of things because I'm lazy and my executive functions are kinda fucked. 😛

look at the RFCs the PQXDH you mentioned could be added on top. there is or was a key exchange one either way https://datatracker.ietf.org/doc/draft-mahy-mls-x25519kyber768draft00/

btw, am I reading my chicken bones right that the move to MLS would also foreshadow a normalization of E2EE'd MUCs?

(and then mentioned in the xep)

Oh, kyber is what PQXDH is based on, too.

phryk, yes

> btw, am I reading my chicken bones right that the move to MLS would also foreshadow a normalization of E2EE'd MUCs? not all of them. but the scaling issues yes

nice, that's a big thing for XMPP imo :3

MLS has much better scaling afaik

plus MLS can keep the people part of the group hidden. idk if that will actually happen in xmpp tho

Yeah, I still have to do a deep dive on OMEMO+MUC at some point. At least MUCs themselves already have surface-level pseudonymity, which is more than many other group chat things can say… :F

Someting akin to federated/distributed accounts would still be interesting, kind of the other end of what the metacontact XEP attempts. I hope I get properly back into working on my XMPP stuff, but it looks like I'm facing some more downtime there. 😕

you mean nomadic accounts? i would be interested in that too at some point

Yes, that would fall under that, too – but I'm more broadly interested. You could also have one account on multiple servers that automatically get shared as a metacontact so you have a failover. Or a limited form of the current in-band registration for temporary accounts. Those could also be distributed over multiple machines, possibly bound together by some unique permanently valid identifier (or not, for true anonymity).

Essentially, I'm looking at a possible future for XMPP that kinda blurs the line between a service-centered setup and true p2p.

i am exploring a client with gnunet. (aka true p2p) so a nomadic account in that setting would solve the "you lose your device/devices, you lose your data" problem

hence my interest in nomadic accounts

because service-centered coms are great for building communities, but for more security-dependent things like journalism and activism, the more ephemeral any metadata is, the better.

haven't looked into gnunet, it sounded like it shared some attributes with TOR but has a different mission?

its basically rearchitecturing the internet around identifiers instead of IPs. and a DHT to deliver messages. plus encrypted by default at the transport level

the nomadic identities i was thinking something inspired by zot for xmpp: https://hubzilla.org/help/en/developer/zot_protocol

but not sure how it would map exactly on top of it

weird… that redirects to https://hubzilla.org/help/about/about but going over a search engine has me arrive at the same url…

briar has another project like that called mailbox. in that case the "server" is just a dumb pipe for messages

ah no, different domain.

moving away of all stuff being on the server sounds good to me. but a bit unpopular inside xsf as i have seen

plus the whole problem of relisiency. you need nomadic accounts before moving stuff of the server

(i am saying nomadic accounts as a framework here. one part being moving accounts to a new device)

i think having 0 server-side metadata should only be one option and not the default. for the vast majority of people, service-based messaging is better. enables moderation and is generally more amenable to community-building.

nomadic accounts i absolutely agree on, tho i think for most people the main use would be migrating your identity when their xmpp sevice closes.

depends what model you are looking at. currently absolutely

and i agree we are missing a lot of architectural pieces to make it anywhere near viable

https://yewtu.be/watch?v=iCvhpeUp3vg "Nobody Said It Was Easy" 😛

Still XMPP is by far the best Free™ coms solution we have IMO – and the one where it's best to invest our resources.

But yeah, nomadic identities are an obvious thing to work towards, because it enables a lot of different things, at least some of which are useful to the majority of XMPP users. Mhh, I might actually mess around with that at some point, seeing as it could just be a Prosody module…

Fyi there is already a xep and systems in place for accolnt migration

But it doesnt migrate everything afaik

Oh, good to know, then there might already be an existing module I can just fuck around with, like I did with mod_e2e_policy. :>

I think you'd probably just want a way to grant a server access to your old account

Some pointers: https://docs.modernxmpp.org/projects/portability/ https://migrate.modernxmpp.org/

If you want that kind of migration

It would require support from the new server, obviously, but not the old one, which is good

Yeah if you still have the client it has all the data anyway.

Mhh, will have to think about this and obviously first read into prior work. Going over the client sounds better to me intuitively, tho. 🙂

Anyhow, going to do this "work" thing now before I procrastinate half the day away. 😛

You mean you're gonna procrastinate account migration all day with work?

> harold: Those are URIs, not DIDs. DIDs are of the form did:<method>:<method-specific-id>, where the method specific ID typically looks random (is a hash or public key) and not user friendly. XMPP and SIP (among others) use federated IDs, that typically have a user-friendly name and a domain name and some separators (e.g. name@domain, @name@domain or @name:domain). As those identifiers are protocol-specific, we need to prefix them with a protocol scheme to make them URIs, that's why we have xmpp:user@domain So 1234 is a sip did number where sip:1234@domain.com or xmpp:1234@domain.com are URI?

harold, a DID is a type of URI that begins with 'did:', so 1234 is not a DID

There is an example of what a DID looks like in the spec: https://www.w3.org/TR/did-core/#a-simple-example

and for the second half of your question, yes, sip:1234@domain.com and xmpp:1234@domain.com are URIs

> There is an example of what a DID looks like in the spec: https://www.w3.org/TR/did-core/#a-simple-example What is a DID? A Direct Inward Dial number (DID), in simple terms, is a virtual number that, for all intents and purposes, can be considered a regular phone number, with the exception that it is not attached to any POTS line (Landline). Once your configuration is ready, your DID will be the phone number that everyone in the world will call to reach you, just like any other phone number. https://wiki.voip.ms/article/FAQ

Does some of you knows well sip?

Ooook, yes, I can see the confusion :)

What exactly is the underlying question?

> What exactly is the underlying question? From me? Its about sip, but also snikket

I'm even more interested and confused how Snikket fits into the question :)

This seems relevant to my interests https://www.rfc-editor.org/rfc/rfc9525.html

But still no movement in cabf on srvnames? :(

yay! and :(

> That's about as long as a Debian release cycle We have to stop thinking in these terms, even the people who use Debian get all their XMPP clients from flatpak, most people are running on the latest release of their client ↺

I certainly hope not, nor does my experience supporting users support this assertion ✏

People are running year old versions of android clients even

Festina lente

Reading Eddie's Board application, and the line implying we've failed to apply for FOSDEM on time, have I missed something?

If you prefer I can reword it: Even people using Debian *can* install the latest clients in a supported way with flatpak

Kev, you've missed nothing

> , you've missed nothing Ta. I don't really understand the comment that we need to improve on this, then!

I'm pretty sure 38c3 wasn't a case of "we missed it" either

If you want to do stuff during FOSDEM, OFFDEM will probably happen again and be a bit more lassez-faire about late reservations.

AFAIK, we *got* the usual FOSDEM stuff, which is why I'm confused.

> Kev: > 2023-11-08 04:24 (GMT+01:00) > Reading Eddie's Board application, and the line implying we've failed to apply for FOSDEM on time, have I missed something? I think its wrong

sorry

Still, my concern is about organisation. Things should be organised with more dedication

XMPP Meet-up Berlin mattj talks about "Spam, Abuse and Moderation" in 15 minutes, join via: https://meet.in-berlin.de/XMPPMeetupBerlin https://fosstodon.org/@xmpp/111368609961723465

Holger, MattJ fwiw the Bind 2 XEP still has language the strongly suggest you have to do the MAM stuff. But as MattJ correctly pointed out clients (at least Conversations) doesn’t use this currently

we could consider making this more optional in the XEP

(there is a "the server MUST figure out the latest mam id) and a SHOULD include the metadata) ✏

I would like to fix the initial message race condition, but yeah, I don't think we want it to hold back SASL2 adoption if implementations are finding it hard

FWIW in principle I totally agree it's meh to leave this to clients.

Just saying it's not necessarily 'simple' to do otherwise 🙂

Yeah

and while MattJ and my marketing team has decided to call the whole stack FAST as a sort of catch all term, the actual fast xep is probably the last of the three XEP you want to implement

Quickly, someone backronym STACK :)

SASL Turbo Authentication Connection Kit

Secure, Timely Authenticated Connection Kit

Which 3? XEPs are those exactly? Searching for "fast" doesn't show relevant results on xmpp.org/extensions Something for XEP tagging maybe? :)

Hm, the Prosody module docs links to https://xmpp.org/extensions/inbox/xep-fast.html

It is possible to have several jabber:x:data forms in a disco#info ?

edhelas: yes

edhelas, with different FORM_TYPE of course

#TodayILearned

Different extentions that put data there will each use their own form

Otherwise you'd have to namespace the field names

^ This guy was accusing me of not having my code properly tested, can you believe it?

code needs to iterate over all jabber:x:data nodes, and search for the correct FORM_TYPE

What will they come up with next? Accusations of not having the tests properly coded??

0424 dropped the support of Message Fastening but not 0425, is there a specific reason for it ?

hello, what's the best xmpp client for iphone, using jingle for audio/video?

Monal, Siskin, or Snikket

‎09/11/2023 | 00:04:10 ‎moparisthebest‎: Monal, Siskin, or Snikket < i tried, and compared to conv/quicksy......:'(

s1: then please provide feedback to the developers

No devroom at fosdem then?

I thought it had already been approved?