[Standards] 34C3 XMPP meeting minutes
pep at bouah.net
Sun Dec 31 15:58:50 UTC 2017
Below are a few notes of an unofficial meeting held during the 34C3 at
There was 18 attendees, among which a few client/lib developers, XEP
authors, XSF members, and other generally interested people. Thanks to
- vcard avatar on rooms - vcards avatars on pubsub nodes
- Tooling (Compliance Tester, TLS tester, uptime monitor -> aggregating
to human readable short list of recommended servers).
- Exchange about the DOAP proposal by Link Mauve (contrary to the
previous point, about implementation rather than deployments), see the
[DOAP thread] on standards at .
- About e2ee, proposal to make the [OX stanza container example] a
separate XEP, and use it in OMEMO.
[DOAP thread]: https://mail.jabber.org/pipermail/standards/2017-August/033123.html
[OX stanza container example]: https://xmpp.org/extensions/xep-0373.html#example-2
## VCard avatar on rooms
- Would clients/libraries break if MUC services started sending
presences from their bare JID?
- MUC vcard already implemented in ejabberd and used by Movim, but
- Link Mauve being volunteered for writing/modifying a XEP.
## Tooling / TLS Tester, Uptime Monitor / List of recommended servers
- Need for a list of services that can be used as recommendations in
clients, and/or by client developers.
- Current tools that generate/use such a list (not necessarily fully
* TLS Tester (xmpp.net),
* Conversation's compliance tester.
- Updating a server entry on the TLS Tester is a manual operation. The
suggestion would be to run tests against services regularly.
- Also need to take into account non-metrics data such as service
policies, (e.g., EULA), who runs the service, where, etc.
- Some client devs would rather use the list themselves (not
automatically fetched into the application) and include servers they
think better meet requirements for their app, and propose that to
## DOAP Proposal - Documenting client metadata for automatic use
- How is "support" of a XEP defined. (XEP reading subject to
- How much information is needed? Do we just want general information?
(e.g., JS functionX supported by BrowserX.Y, bugZ also opened)
- Who would publish it? Suggestion is client devs on their website,
with the current PR system against xmpp.org.
## E2EE - full stanza encryption
Proposal to more or less take the [example 2] of the [OX XEP], --
container inside `<message>` that contains to-be-encrypted elements --
and make it its own XEP.
- Whether to replace elements into the enclosing message, replacing
everything, or to wipe its content and interpreting the encrypted
payloads as the only ones in the message.
- See [Daniel's post to standards@] about what elements from the outer
stanza is going to be processed after decryption. This should be a
**very** strict whitelist.
- Complaint about having to fire up the parser once more (mostly
handwaived by the current method invoking a protobuf parser every
- Daniel proposed to start the discussion with current XEP authors.
After the meeting:
- [Encrypted Session Negociation] is already a thing and does full
stanza encryption, but it is only implemented in Gajim. What is wrong
with it? Why is nobody using it? What can we learn from its
full-stanza encryption method?
[Daniel's post to standards@]: https://mail.jabber.org/pipermail/standards/2017-December/034028.html
[Encrypted Session Negociation]: https://xmpp.org/extensions/xep-0116.html
[OX XEP]: https://xmpp.org/extensions/xep-0373.html
[example 2]: https://xmpp.org/extensions/xep-0373.html#example-2
Maxime “pep” Buquet
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards