Modern XMPP project discussion - 2025-01-02

Thanks

So if Conversations is supposedly problematic in terms of proper XEP conformance (or whichever other complaints there are), then what are the recommended alternatives for native Android clients (that's actively maintained, the people are actually using, and not just giving me an answer based on a 5 second search query)?

What is problematic about Conversations?

given I seem to be having issues presumably with OMEMO in Conversations with publishing prekeys in PubSub, and it seems like there has to be server-side fixes of something pertaining to a namespace relative to Conversations (eu.siacs.conversations.axolotl.*)

I'm not aware of any such issues, and I'm a server developer

Conversations uses XEP-0163 to publish prekeys, same as any other OMEMO client

Understood, I'll probably poke in the ejabberd chat as it's probably a misconfiguration on my part then

Hmm

There was a period where ejabberd supplied a default config file which explicitly blocked this

> So if Conversations is supposedly problematic in terms of proper XEP conformance (or whichever other complaints there are), then what are the recommended alternatives for native Android clients (that's actively maintained, the people are actually using, and not just giving me an answer based on a 5 second search query)? Convertation is good enough and I don't notice an issue like you describe but I'm using monocles and I'm pretty fine with it ↺

So if your ejabberd is out of date or still using the config file from that period then you would indeed have problems (with any OMEMO client, not just Conversations)

It was without any PubSub-specific tweaks, to which I then tried applying said (presumably outdated?) tweaks, to no avail either. The server hosts two very separate domains (one work-related, one family-related), but both have a discoverable PubSub endpoint via service discovery, but yet when trying to contact any user even within the same domain, it would complain about key discovery issues.

OMEMO doesn't use any pubsub service you can see via service discovery

If you mean something like 'pubsub.example.com'

XEP-0163 is provided directly on each account by the server

So to clarify: PEP is a reduced subset of PubSub (OMEMO solely uses PEP), however resources are identified under the bare JID rather than some separate XMPP service endpoint entirely (e.g. pubsub.example.com), and I assume only queriable if a user has an active presence subscription to that user? ✏

So to clarify: PEP is a reduced subset of PubSub (OMEMO solely uses PEP), however resources are identified under a user's bare JID rather than some separate XMPP service endpoint entirely (e.g. pubsub.example.com), and I assume only queriable if a user has an active presence subscription to that user? ✏

Pretty much, until the last point

Clients are able to configure the access policy of PEP nodes

Some may be viewed only by contacts, but they can also be configured fully private (accessible only to the user's own clients) or fully public (accessible to anyone)

whereas the "force_node_config" was a server-side override of the access policy?

prekeys are generally the latter, e.g. so that you can participate in encrypted groups without needing to have every participant in your contact list

That sounds like an ejabberd feature, and I guess that's what it does, yes (override the client's requested policy)

Well, wouldn't it operate differently for groupchats, whereas if you're in a groupchat, then it's assumed you would permit other members of the groupchat to query your OMEMO keys, especially so if you're identified in the room by MUC JID (semi-anonymous)? I thought prekeys would be for any case ('chat' and 'groupchat') as isn't the first part of key exchange in X3DH?

Or rather than the access policy for prekeys are 'fully public' in scope of groupchats? ✏

(I only have a very surface-level understanding of it all, and trying to fill in the blanks, as I've skimmed through parts of specs, but haven't applied any of that yet to make sense of it, as I'm occupied with other projects before getting back to toying with recent XMPP experiments) ✏

> if you're in a groupchat, then it's assumed you would permit other members of the groupchat to query your OMEMO keys Your server barely knows you're in a group chat, let alone who the other members are

OMEMO is used in non-anonymous groups, so queries can be sent to actual user JIDs

whereas in semi-anonymous, the MUC service just forwards the query, just the same as it does with messages?

Semi-anonymous configuration is usually used in public groups, and it happens that E2EE in public groups generally doesn't make much sense

> whereas in semi-anonymous, the MUC service just forwards the query, just the same as it does with messages? This is actually unspecified in the protocol. Prosody does it, ejabberd does not.

> Semi-anonymous configuration is usually used in public groups, and it happens that E2EE in public groups generally doesn't make much sense it is possible to e2ee DMs in a pseudonymous chat ↺

Yeah, though the current style of DMs (at the protocol level) doesn't have long left, I think

it's disabled in GC3?