Conferences/Summit 24/Minutes Day1

XMPP Summit 24 minutes - Day 1

Proposed Topics / Votes

• XMPP Shortage Audit: 10
• MIX when?: 6
• Stickers: 6
• Why Push notifications are not good?: 9
• "Work Spaces": 4
• In-client, unified, public MUC search (not disco): 0
• MAM Search: 0
• Opt-in server metrics report: 1
• Basic C2S feature over REST-like API (HTTP/JSON) // New C2S Protocol with JSON over HTTP: 4
• User-friendly OMEMO key management // Keys / Key Signing: 8
• Multi-client presenceless MUC // Shorterm MUC fixes: 6
• XHTML-IM2: 4
• Inbox/Unread/Bind2 // INBOX // Reconnection: 6
• Fastening/MAM: 3
• Presence/PEP Splitting // User Status in PEP ("Rich Presence"): 6
• Easy password-less device enrolment + account recovery: 10
• Sender-less messages: 1

10:52 - XMPP Shortage Audit

What features would XMPP be missing compared to other solutions (Slack-like, WhatsApp-like, etc.)

Some need specs, some need implementation/deployment.

• Persistence of MUCs (being in the MUC regardless of presence)
• Reactions/collation
• Inbox/etc. sync
• Stickers
• Sensible file-attaching to chats (cross-device)
• Snippets
• File attachment? (No way to reference to these later on?)
• Server / workspaces (à la Discord)
• Sticky messages / Pinning
• Contact discovery (centralised?)
• Management of Notifications
• Conditional / global status / expiry
• Custom emoji in the status
• Location sharing
• Side conversations
• Replying (quoting, with reference to the original message)
• "Stories" / microblogging
• Workspace / communities
• A/V calls (group)
• ACLs, role management, hats
• Mentions + Teams
• Bots / integrations
• Previews!
• Annotations on attachments (images)
• Search

This looks like (is) a shopping list. Do we want to do anything with it?

Not all clients would implement all of these. What about interoperability? What about different UX expectations?

No specific conclusion/action.

11:31 - Easy Passwordless Onboarding and Account Management

Georg wrote 0379 Pre-Authenticated Roster Subscription, and also 0401 with Mark, that MattJ implemented it in Prosody, and Daniel implemented it in Conversations. This improves the on-boarding situation. Still missing a preset password so that users don't have to worry about it either.

Ideas for the handling the password reset? first time setting?

• Email
• SMS
• Web challenge

ISR2 / HT* / ClientKey -> specifically designed for having a token handled by one device only. Also requires device tracking

• Heavy weight TLS certificates? External? SASL Mechanism?
• 0257 (Client Cert management for SASL External)
• 0416/17 ?

Possible flow when you have an authenticated device already:

• QRcode from authenticated device (generate token) -> Scan with non-authenticated device -> Go through password reset and generate client cert from new client.
• Send short code/pin to authenticated device and prompt for it on the non-authenticated device (see Telegram web)

12:00 - Account Rich Presence in PEP

Presence mixes per-device settings with non-per-device settings. Goal: Putting account presence, status, and/or other rich status in PEP (or some other storage mechanism) instead of having it per-device. (Taking WhatsApp status as an example)

Per-account status (Slack style) and stories (Instagram style/microblogging) are two separate things that can coexist (see WhatsApp). Merging those would probably cause confusion/implementation difficulties and limit the possibilities.

Do we want another microblogging node? Comments? Expiration? Expected order: last created? (not last updated) ==> we have XEP-0413 (Order-By)

• Emoji
• Expiry
• Published timestamp
• Icon
• Status show

URIs for images (not limiting that to http(s))

Upgrade path? Kev suggests "None". Servers having been doing that for years and somewhat got it wrong in different cases.

Example for expiry:

• Foo publishes "Bar"
• Foo's calendar bot publishes "In a meeting" with expiry of 1h
• Receiving client see both, filters out expired publications and picks out last created. displays the calendar one

13:31 - MLS

External article explaining MLS and comparing with the Signal algorithm: https://blog.trailofbits.com/2019/08/06/better-encrypted-group-chat/

Link to the Working Group: https://datatracker.ietf.org/wg/mls/charter/

MLS is the IETF's answer to the Signal Protocol in some way. Signal Protocol has various issues (as we all known). It also focuses on Groups by default. Signal encrypts to each device in a group, which doesn't scale.

MLS splits a group chat process into two parts: Key negotiation protocol (once per group) and Encryption of the messages themselves.

General idea: Each member of a group has a private key and a public key. Just like with for example Signal, participants will inject a "PreKey" (Signal) <inaudible> (MLS). The keys are then arranged into a tree. (Somebody with cryptography knowledge needs to take over.) … Magic happens … everything is amazing …

Message ordering is less of an issue then other mechanisms: MLS can deal with unordered messages. What needs to be ordered is group keys changes, but ordering information is included in them.

What do we need to write for an MLS XEP?

• About the "same" as OMEMO
• MLS already has an architecture draft
• Maybe define the distribution server?

There is no need for server support of MLS, it's a p2p protocol. (Not sure about this. There is probably support for group management reqiured, just no crypto support)

Possible support from the IETF if we express interest in MLS. The IETF would benefit from feedback from the messaging community.

Identity keys in MLS could be per-account or per-device, this is left open in the design.

14:00 - End-to-End Encryption Key Management

Scenarios:

Yes, I've changed my client/app/device, so what? / Yes, I've added a new client/app/device, so what?

• "Security vs convenience", users generally don't do fingerprint verification because "it's annoying"
  • UX-level "solutions"
    • TOFU/BTBV (makes fingerprint comparisons opt-in, guarantees protection only against passive attacks)
  • Protocol-level/technical solutions
    • Sharing the "identity key" with all devices
      • Signal does it that way (probably a "mistake" in the current spec not to do it that way)
      • Only one fingerprint to compare per account to trust
      • Requires somehow transfering the private key from existing devices to new ones (MattJ's onboarding!)
      • Can't revoke/untrust single devices, only the full "identity"
    • Cross-signing/trust transfer
      • Would basically create a web-of-trust
      • The happy path of this "web-of-trust" seems fine (only one fingerprint to compare), but the unhappy path still exposes multiple identities to users which is confusing
      • Is there even a happy path for this WoT?
        • "WoT" here would only mean cross-signing own devices. Not user signing other users' keys. "WoT" is probably not the right term.
      • On-boarding thing could be used as a way to cross-sign new devices
    • Per-account "master key"
      • Very similar properties to the solution of "sharing the identity key" (aka IK sharing)
      • One fingerprint per account
      • Requires somehow signing new keys using the master key (MattJ's onboarding!)
      • If done carefully, would still allow revocation/untrusting of single devices -> advantage over IK sharing
      • Master Key could be used for other stuff in the XMPP multiverse, e.g. login to XMPP servers, migrations or to sign encryption keys for even other e2ee schemes -> advantage over IK sharing
      • More complicated than IK sharing -> disadvantage compared to IK share
      • How to handle Master key's password/token/..? -> Out of scope

ACTION: Syndace volunteers to draft/spec about Master key

Wait, what are... keys? What should I do with them?

Kind of related to the first two questions, per-account trusting is a lot more convenient and easier to understand than per-device trusing.

Oh no, again, another something is encrypted and I can't decrypt it

• State of implementation/deployment (of $encryption) not being complete
• XEP being crappy and fixing this is still a WIP
• Device tracking would allow other clients to easily see what receiving clients do $encryption
  • Potential signing of device keys (identity keys) to allow for some kind of automatic trust
  • Revocation?
  • Key Expiry? (Doesn't cancel out Revocation as one might want to revoke before expiry)

Why can't I read/decrypt this old message?

That's PFS, nothing we can do about this(?)

15:00 - Palaver IM Client

History:

• Discovered XMPP when asked to write an ICQ-compatible client
• Convinced $company to use it
• Did lots of prototypes with web-stuff (electron etc.), didn't like them
• Went back to "native", with the idea to be cross-platform, on desktop

• .NET core / netstandard / c#
• MatriX vNext XMPP library
• Cross-platform (Windows/Mac/Linux) UI Framework: Avalonia UI (XAML, MVVM, ReactiveUI)

TODO: Link slides.

Conversation view rather than roster view. Supports:

• messages
• avatars
• read markers
• groupchats (MUC?)

Will be published under GPL (possibly dual-licensed). Still needs cleanup, currently unpublished.

Somewhat based on Slack UI-wise

15:15 - Why Push Notifications are not good enough?

Tigase proposed extensions: https://tigase.github.io/tigase-xeps/docs/push-notifications

Most server operators decided to disable informations that can be enabled in notifications for privacy reasons. While this is a normal concern, if a server sends a notification without content,

• On Android, clients would reconnect and then decide to show a notification or not. This doesn't appear to be possible on iOS.

 ** iOS now has "High-priority" notifications that are always displayed. At the point a device gets the notification it doesn't know if it should or not display it. "No silent notifications"

It would be nice to be able for the client to specify what it wants to filter.

• What needs notifying?
• Wire format? Do we want our own query language? static ruleset?
• As a start we could have the XMPP server send information of low/high-priority to the App server. This is already done but undocumented in prosody/ejabberd

Regarding privacy issues:

• A normal reconnect to the server takes 3-5s. This is already too long and drains battery
• Encryption could be used (XMPP server and client can generate keypair somewhat like Web Push does)

We don't currently have a way to "register devices" (do we not?)

CSI already means to do most of what is needed for this proposal to work and could be used by 0357

Possible things that we want to notify for: (possible example: https://i.imgur.com/0GXxzU9.jpg - Slack flowchart)

• Mentions / direct
• Conversations muting
• Calls
• Defaults / Notification management: "all msg in conv.", "only mentions", etc.
• Device registration
• Per-Device-Type (Desktop vs Mobile vs ..). To be combined with device registration

What about E2EE?

• You can choose to have the server understand when you're being mentioned or not

Should we focus on XEP-ing the Slack diagram?

• It's probably not the full story (does it matter? better than nothing)

ACTION: Who volunteers? Kev says "At some point in no time soon". MattJ as a reminder to Kev in noon time soon. Andrzej: Volunteers to write the Tigase proposal as a patch to 357.

16:00 - MIX when?

• Multiple people have tried implementing MIX.
• MIX is technically implementable
• Not enough will from various actors to put time into it
• MUC compat needed for adoption
• Server implementation that client devs can deploy themselves could help
• Part of the feedback still not addressed (putting mix in roster?)
• Keeping it in the roster is not bad, but should be optional
• jonas suggests that having MIXed roster items (hah, get it?) is a bad idea, as it makes client library development unnecessarily complex as it would lead to strange couplings between mix and roster stuff. The need to fire disco infos against all roster items would be unfeasable.
• ralph notes that in some clients the roster lives in a different place than the account.
• "clients are already broken if they assume that what is in your roster is another client"
• If we do reinvent the roster for MIX. We really do reinvent the roster (e.g., versioning, pushes). If so, we could take the opportunity to improve roster operations.
• Channels added to the roster are already annotated (with your participant-id) with roster annotations. https://xmpp.org/extensions/xep-0405.html#mix-roster-capability-sharing
• Kev admits that ALL of this is his fault.
• For the sake of keeping history in your MAM archive, we could add a parent key (previous message's stanza-id) to messages so you can know if you missed a message due to S2S outages.
• Do we consider that everything should go in your private archive and when you join you get everything from there? Or ..<please fill in>??
• Backfilling priori to joining the room might not be GDPR compliant, (which is not what was suggested, but MAM actually supposedly does support it).
• It's bad for scalability if you have participants from vast amounts of users in different channels and instead of deduplicating copy the contents of channel mam archives to the users private MAM. On the other hand fethcing each channel individually also does not scale well.
• It is not clear, if copying messages from server to server is a GDPR issue.
• MAM full text searching pre-join messages should be optionaly supported (servers can reply with error/no message/some message depending on policy).