#XSF #Summit 2020 in #Brussels
Topic 1: #XMPP 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.
Topic 3: Coffee break :coffee
Topic 4: Rich Account Presence in PEP
Classic presence in #xmpp 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.
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.
Now: Lunchtime :)
Lunch was delicious!
Topic 5: Message Layer Security
A workgroup within the #IETF 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.
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.
The discussion participants tend to agree that the master key approach is an elegant solution.
Quick coffee break. Syndace's recommendation of the day: Mix coffee and chocolate in the same cup!
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!
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.
Link to proposed push solution by Tigase: https://tigase.github.io/tigase-xeps/docs/push-notifications
Criteria that need to be taken into consideration are:
* mentions / direct messages
* calls
* notification preferences per channel
* e2ee
* device type
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?).
@vanitasvitae Was the question of "when?" answered? *ducks*
@stevenroose soon... :P