Summit 21 minutes

From XMPP WIKI
Jump to: navigation, search

Collective Notes for XMPP Summit 21

Contents

Day 1

Agenda Discussion

  • Day 1: MIX (XEP-0369)
  • Day 1: MAM (XEP-0313) Sync - BIND 2.0 ( http://xmpp.org/extensions/inbox/bind2.0.html )
  • OMEMO
  • MAM (XEP-0313) Search
  • Day 1: In-chat Media / Form / References
  • IoT
  • Carbons (XEP-0280) Last Call
  • Day 2: General Obsolesce
  • MUC (XEP-0045) sharing
  • Day 1: SPAM
  • Day 1: Auth4 2.0 / Multltiple credentials per account / Multi factor authentication
  • Day 2: XSF's neutrality
  • Day 2: GSoC
  • Day 2: DNSSEC
  • Discussion Infrastructure and Communication Channels
  • Day 2: Winfried's project
  • XMPP Meetup sync across europe (@nyco)

MAM (XEP-0313) Sync - BIND 2.0 - Custom Resources

  • Currently login with carbons and MAM sync is prone to race conditions
  • Proposed solution: a login method that does binding, carbons enabling, MAM sync, unread state sync in an atomic fashion
  • Existing sessions with the same resource are automatically closed
  • Allow custom resources (allow clients to choose a resource)
  • pros:
  • people currently use it (e.g. some IoT deployments where each device has a human readable resource)
  • addressing stability
  • cons:
  • harder server clustering (resource must be unique across cluster)
  • server is allowed to respond with a different resource anyway
  • custom predictable resources can be a security issue
  • motivates clients not displaying resources in UIs
  • UX nightmare
  • suggestion to split client resources (i.e. the ones generated by the server during bind, not MUC resources) into two logical parts, i.e. $STABLE_CHOICE_BY_CLIENT/$SERVER_CHOICE -> the client chosen part allows for easy debugging; the server chosen part prevents resource conflicts

MIX (XEP-0369)

MIX Agenda

  • Intro by Kev
  • Anonymity / Mapping
  • Subject
  • MUC Subjects aren't used as originally intented (subject of current discussion, not a description of the room)
  • What should be in the core MIX spec?
  • channel subject
  • sticky notes, e.g. useful media like URLs, images, etc.
  • current discussion topic
  • short description
  • long description
  • Voice, who is allowed to write to the channel
  • Passwords (maybe later)
  • Clients by channel, different clients being in different sets of joined channels (solved later in PAM when that happens)
  • Roster
  • MAM
  • MUC/MIX (maybe later)
  • MIX Baseline
  • What should be part of XEP-0369?
  • ideally slim, yet usable, but not on its own able to provide full MUC compatibility
  • additional XEPs extending/building on XEP-0369 providing things like sticky notes etc
  • profile XEPs that provide decribe what sets of features are required for certain UX concepts (chat rooms, social feeds ,etc.)
  • Moving MIX fields attributes from plaintext ('Message Node Subscription', 'Name', 'Participants Must Provide Presence') to proper tags ('mix#node_subscription', 'mix#name'…)
  • Simpler to handle in the XMPP libraries
  • Allows i18n on the labels
  • Does urn:xmpp:mix:nodes:config and urn:xmpp:mix:nodes:info are in a way redundant with http://xmpp.org/extensions/xep-0060.html#owner-configure, especially for the metadata (pubsub#title, pubsub#description). Should we block Pubsub configuration (or some fields) on a MIX service?
  • More globally, should MIX "fixes" what was missing/broken in Pubsub (like it tries to do with MUC)


Auth 42.0 / Multltiple credentials per account / Multi factor authentication

  • providing a mechanism to do 2 FA in XMPP
  • reduce the number of roundtrips
  • Dave plans to write a XEP

SPAM

  • one unmonitored IBR server is enough to ruin the current federated XMPP system
  • IM spam could be similar enough to email spam to reuse existing technology here
  • spam could come from malicious servers, malicious accounts on unmaintained servers, legitimate accounts that become malicious, …
  • ===> IBR 2.0
  • Multi-stage
  • Sam and Guus plan to write up multi-step IBR and message stanza challange and response
  • In the case of IoT device we have used http://www.xmpp.org/extensions/xep-0348.html signing forms to be able to connect the IBR registration to explicit set of keys effectively inhibiting unknown from registering. it's implemented in tigase


In-chat Media / Form / References

Informational XEP: "in-chat forms" = fdp + pubsub + forms + references (Nyco+Kev)


Day 2

Neutrality in the XSF

  • extreme neutrality is rather impossible as vendors can claim what they want (@kev)
  • possible use of compliance suites for promotion of software
  • currently xmpp.org lists a lot unmaintained/obsolete software which put a bad light on XMPP as a modern protocol
  • XSF members (more than one) could vote on if a software should be listed (@dwd)
  • Software vendors have to resubmit their software yearly to be be listed on the xmpp.org website (@ge0rg) - automatic removal of unmaintained software and staying neutral
  • wikipedia has a more up-to-date version of a XMPP software list (@arc)
  • limited scope software can lead to complete (rare release software) (@kev)
  • Summary: DON'T REMEMBER THE EXACT PHRASING, 85% raised their hand for something
  • a software version declaration XEP could be used (Link Mauve was talking about making one), with release date. This way, we could automatically deprecate software older than X years. The idea here is to have some form of declaration (e.g. on a special location on the official website), something like {"name":"yaxim", "icon":"https://yaxim.org/logo.png", "version":"1.0", release:"2017-01-31"}

Google Summer of Code

  • put ideas on by monday
  • Kev would do admin again if xmpp.net doesn't kill the wiki again
  • Arc/Dwd would do backup admin

Winfried's eHealth project report

General Obsolesce

  • should we obsolete more XEPs
  • Ralph suggest the actual issue is less that old stuff is not obsoleted but that the XEP list is hard to navigate
  • Kev suggested adding labels again, someone would have to implement
  • tags (seems like the same think than aforementioned labels) in XEPs (chat, groupchat, audio/video, file transfer, encryption, etc.) would improve readability a lot, and could be reused in compliance suite (e.g. encryption clients need at least one XEP with groupchat tag).
  • Gather interest in XEPs by their clients indicating what they claim to support
  • A lot software is out of date or badly designed, that's bad and what can we do to fix it (@nyco)
  • gather (client) software implementors and ignite a broad discussion around the major problems and how to work on solutions

Dave's DNSSEC thing

  • implement DNSSEC, validate DNSSEC on SRV record, check certificates with the hostname (RFC 6125)

RTC Quickstart Guide ( https://github.com/opentelecoms-org/RTCQuickstartGuide )

OMEMO

MIX

  • mix channels go in the roster, offline presence, annotated as a replacement for bookmark XEP

IoT

  • IoT SIG ( https://wiki.xmpp.org/web/IoT_SIG )
  • short report on recent IoT SIG work by Flow and Rikard
  • a lot companies already use XMPP of IoT, but everybody in their own proprietary way, non-interoperable
  • more community involvement for IoT related XMPP standard development
  • general discussion about IoT and how to use XMPP for IoT in the right way, solving the general problem case, instead of the specific IoT problem case, to enable knowledge and code sharing