[Standards] 34C3 XMPP meeting minutes

Maxime Buquet pep at bouah.net
Sun Dec 31 15:58:50 UTC 2017

Hi Standards,

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
all attending.


- 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
  requires polling.
- 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
  automated yet):
  * 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
  interpretation etc.)
- How much information is needed? Do we just want general information?
  Do want details such as MDN includes for HTML, Javascript, etc.
  (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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171231/856ffa2d/attachment.sig>

More information about the Standards mailing list