Modern XMPP project discussion - 2025-02-05

For all the time people put into writing blogposts and holding meta conversations on the state of OMEMO, MLS, etc, we'd probably have enough manhours to have rewritten all of that (or implemented MLS) a few times over by now.

Well, be the change you want to see 🙄

I agree, I'm just poking around with nomadic identity in ActivityPub first, then I'll poke around with XMPP next

or toy around with MLS in ActivityPub also, somewhere inbetween

In regards of OMEMO, has anyone written any test suites for clients?

> I agree, I'm just poking around with nomadic identity in ActivityPub first, then I'll poke around with XMPP next So you'll be poking around with nomadic identities in XMPP too? ↺

And you intend to do that according to the DID spec if I am not mistaken?

DID doesn't involve blockchains or cryptocurrency right?

I heard someone say that it does but I can't really find that in the spec so I assume that's a prejudice

> DID doesn't involve blockchains or cryptocurrency right? The current set of published DID methods can be: - based upon a JSON file published on a website (did:web, therefore dependent on DNS), a standalone cryptographic keypair (did:key, though not really meant to be used directly), - a self-certified cryptographic identity that you'd publish to miscellaneous registries to be discoverable (did:plc as used in Bluesky, and did:fedi as I wrote for an experiment with ActivityPub, and many many more), - a combination of the two (did:webvh, which is like a combo of did:web and self-certified), - derived from an existing blockchain address (there's a handful for Ethereum, Bitcoin, etc), - self-certified cryptographic identity published on a blockchain (surely some exist, I don't know of examples quickly off-hand), - or just totally outright centralized (e.g. did:id, and a few other really odd ones) The current list of known DID methods that people have come with is at: https://www.w3.org/TR/did-extensions-methods/ ↺

> Well, be the change you want to see 🙄 I'm glad this is catching on ↺

A DID method essentially specifies the criteria of how an identity is created, updated, resolved, and/or revoked, within that method. A DID method specifies the format and meaning of the 3rd part of the identifier (which is specific to that method), and anything that follows (as well as how to handle 'DID URLs'). So essentially anyone could just come up with their own arbitrary DID method, with whatever arbitrary criteria they set forth for it. For example, someone could make up a dumb idea like a hypothetical "md5dns" DID method; where the rule is: you take the method-specific identifier (the 3rd part of the DID), hash it against MD5, then slap on a ".com" at the end, treat it like a domain name, and load a JSON file over HTTP stored at "(md5 output).com/.well-known/md5dns.json" or something; and ta-da: you have a DID method. The point is that there isn't one specific way that DIDs work, anyone could come up with a better idea, just as long as it doesn't collide with an existing published DID method identifier

> So you'll be poking around with nomadic identities in XMPP too? Yus: https://arcanican.is/excerpts/did-method-fedi/ ↺

Just one part to clarify from potential confusion: generally an application should only really support the DID methods that make sense within it's context. I don't think it's a rational objective to have every DID-aware application support every DID method. Additionally, DID resolvers aren't necessarily meant to be considered directly equivalent to having public DNS resolvers; a DID resolver should generally be a local software running on the same machine or on a local trusted system, not something where you just openly query any random DID resolver across the internet, otherwise the trust model breaks down, because of course: there could be malicious DID resolvers out there, you wouldn't be able to tell the difference, and identity is a very critical context. You'd instead run a resolver locally that natively implements the DID methods you need (probably realistically barely 3-5 methods, maybe), and build an application off of that.

But overall, DIDs can effectively act like your own little personal certificate authority of 'you' and be a DNS-like system to resolve resources namespaced under your DID, which can be moved around.

conversely, it could also be abused as a vector to inject and mandate government ID online

To segue back to XMPP: I think DID URL support in clients could be helpful for HTTP uploads; or alternatively, some weird resolver/relay service that resolves the real server location for a user identified by DID (probably in the user-part of a JID) and forward messages to their current server.

though it's probably more work than it's worth, as I don't know what forms of data are normally stored on an XMPP server that couldn't just be copied over to a new server, other than any references to public PubSub posts (such as the blog-like posts in Movim) breaking ✏

arcanicanis: see XEP-0227, which is used for cross-server account migration

That's the data part

I mean doing DID support in XMPP is probably more work than the benefits it provide, especially when there's an export serialization to move data between servers anyway (except HTTP uploads don't seem to be considered in XEP-0227, but that's probably hard to account for) ✏

I mean doing DID support in XMPP is probably more work than it's worth, especially when there's an export serialization to move data between servers anyway (except HTTP uploads don't seem to be considered in XEP-0227, but that's probably hard to account for) ✏

What transport projects are there other than Slidge? Cannot really find much, there must be a list somewhere.

(I'd be interested in Signal [the one from Slidge seems dead], Google Chat [annoyingly I have one single contact refusing everything else, lol], Threema... but also just in general I'd like to see what's out there)

biboumi for IRC

edhelas, there’s still spectrum (purple-based)

Yeah but barely alive

nicoco saved the day

Now the future of the whole XMPP bridging ecosystem rely on his shoulders

a heavy burden

There are also some individual bridges like Parsee

Slidge is basically a xmpp frontend for libraries developed for matrix bridges. Which has good and bad sides...

Got a link? Cannot find anything that looks like it could be it. ✏

https://git.kappach.at/lda/Parsee.git

Yeah Bifrost is crap

I know of XMPP server admins who ban Bifrost outright because of all the psuedo-HTML spam that Bifrost causes

Like if someone mentions an XMPP user from Matrix you will get a long fake HTML tag instead of just the nickname being inserted

It's very spammy

> Got a link? Cannot find anything that looks like it could be it. Parsee's a WIP Matrix-XMPP bridge ↺

pretty sure work has slowed a bit due to LDA's internet being down or something like that