2020 in

Topic 1: Shortage Audit

We talk about ways in which xmpp comes short compared to other solutions like Slack, WhatsApp etc.

On the list are things such as contact discovery, snippets, microblogging ("stories"), stickers, bots and other integrations.

Some of those are already specified but lack implementation, others are not yet tackled at all.

Topic 2: Easy Password-less Onboarding and Account Management

User onboarding could be vastly simplified by having the registering device generate a random password/key. Problems arising from this are usage with multi devices (QR code scanning with existing devices), password reset (reset link via email, pin via other device).

Other things to consider are client certificates (XEP-0257) and other SASL authentication methods.

Show thread

Topic 4: Rich Account Presence in PEP

Classic presence in is device centered and breaks down in multi device usage.
Eg. if the user sets his desktop client to "away" and starts using his phone, is he now away or on the phone? Both?

Publishing the status of a user (eg. "I'm at the Summit \o/") to a PEP node would solve this issue as that node would be per account instead of per device. The latest status would override the previous one.

Show thread

This would also allow for rich, microblogging like status sharing as known from WhatsApp or Instagram "stories" although status and stories would probably be different features.

Using microblogging (XEP-0277) would be one possible solution for the stories thingy.

Show thread

Topic 5: Message Layer Security

A workgroup within the is currently developing a new end-to-end encryption protocol called MLS which is basically the IETFs answer to the Signal protocol.

MLS focuses on group chat encryption in larger groups, but is also suitable for normal chats. Dave gave an overview of the protocol and suggests that we start looking into how to deploy it with XMPP now.

datatracker.ietf.org/wg/mls/ch

Show thread

Topic 6: Easier End-to-End Encryption Key Management

Key Management in e2ee systems like OMEMO can be a pain, especially in group chat scenarios.

Proposed solutions are cross signing between keys, identity key sharing and/or master identity keys.

Show thread

The discussion participants tend to agree that the master key approach is an elegant solution.

Show thread

Quick coffee break. Syndace's recommendation of the day: Mix coffee and chocolate in the same cup!

Show thread

Lightning talk of Alex about his cross platform XMPP client Palaver.
The app is developed using the MVVM pattern and runs on Windows. Definitely worth to keep an eye on!

Show thread
Follow

Topic 7: Why Push Notifications are not enough?

Push on iOS sucks and appears to be unreliably. Additionally the Push XEP-0357 lacks support for different types of priorities. Therefore spam messages from strangers will always alert the user as there are no silent notifications.

Tigase proposes some very interesting solutions to current push issues, like using encryption to hide message contexts inside push notifications from the push service itself.

There needs to be server-side tweaking in order to figure out which stanzas should trigger a push notification and of what priority.

There is a flowchart diagram by the slack developers that gives an insight on the complexity of push related decisions.

Show thread

Criteria that need to be taken into consideration are:
* mentions / direct messages
* calls
* notification preferences per channel
* e2ee
* device type

Show thread

Topic 8: MIX, when?

MIX is the spiritual successor of MUC group chat. There exist some implementations that suggest that implementing it is feasible. For wider adoption however, MUC downwards compatibility would be necessary.

Part of the feedback to the specification has not yet been addressed, eg. where to store records of all the MIX channels a user joined (roster?).

Show thread

There is also the idea floating around to add a the id of the previous message to each message, so that S2S sync issues can be detected and fixed.

Show thread

Some GDPR issues with message sync are being discussed, but the discussion has to come to an end for today.

This concludes the first day of summit :)

Show thread

Topic 1: IM NG

Historically, XMPP messages were routed to only one receiving device. That may be the device with the highest priority, or a particular device identified by the resourcepart of the jid (eg. vanitasvitae@jabberhead.tk/phone is a phone).

To improve the user experience in modern multi client scenarios, extension protocols like Carbon Copies and Message Archive Management were introduced to adjust the message routing to changed user expectations.

Show thread

However, this still leaves some uncertainties in how messages are supposed to be routed in certain situations.

XEP-0409 IM Routing NG aims at solving this issue by simplifying and unifying message routing for enabled clients. Basically messages sent to a barejid are routed to all IM NG devices, while fulljids are no longer being used in the instant messaging context (you can still use fulljids for other scenarios like machine to machine communication of course).

Show thread

Currently there are some edge cases to be discussed like routing of error messages. Those are being discussed right now.

Show thread

One proposed idea is to simplify the rules of Carbon Copies until Carbon Copies "transforms" into IM NG (which has a simpler syntax). That way the complex rules of Carbons can be dropped some day.

Show thread

Topic 2: Lightning Talk of @nyconyco about the work of the Comm Team.

Comm Team is doing the monthly XMPP Newsletter (to which you can subscribe to by the way: xmpp.org/newsletter.html )

Show thread

Nyco describes the process of collecting links, articles, doing translations etc. that goes into publishing the newsletter each month, as well as the work the team is doing on social media.

Show thread

Lunch was delicious! Thanks to Cisco for hosting us and to @xmpp for providing the lunch :)

Show thread

Topic 3: Inbox

XEP-0430 is the latest published XEP and only a few days old. It describes a way for a client to quickly receive a list of conversations that contain unread messages to display to the user. Without XEP-0430 a client would have to do a full synchronization with the server side archive, which takes some time. Inbox will improve upon this by delivering the users inbox quicker after login.

Show thread

Some open problems include usage with MUC, as messages from MUCs are only automatically copied to the users MAM archive when the user is joined the chat room. That means that MUC messages wont be available at the time inbox elements are constructed.

MIX would not suffer from this issue.

Show thread
Show more
Show more

@vanitasvitae Could you briefly give some examples of what the issues are with Carbon Copies?

@stevenroose Getting it to work reliably with MUC is apparently non-trivial. Also on login there is the possibility of race conditions between carbon enabling and other setup steps.

@vanitasvitae @tigase Hmm, that's not entirely true. The user shouldn't be notified when a push notification comes in. The app should be woken up and the app should check what's new and then decide whether the new content is worth waking up the user, right?
That content doesn't have to be part of the push necessarily for that.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.