Hi Standards, Below are a few notes of an unofficial meeting held during the 34C3 at Leipzig.
There was 18 attendees, among which a few client/lib developers, XEP authors, XSF members, and other generally interested people. Thanks to all attending. https://events.ccc.de/congress/2017/wiki/index.php/Session:XMPP Agenda: - 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@. - 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 users. ## DOAP Proposal - Documenting client metadata for automatic use https://mail.jabber.org/pipermail/standards/2017-August/033123.html - 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 time). - 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
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
