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 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.
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 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.
Link to proposed push solution by Tigase: https://tigase.github.io/tigase-xeps/docs/push-notifications
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?).
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. firstname.lastname@example.org/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.
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).
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.
Topic 4: SASL2 / Bind2
SASL2 and bind are mechanisms that are used early in the process of connecting a client to a server. SASL2 (XEP-0388) is the next iteration of SASL which is used as an authentication mechanism, while bind2 (XEP-0386) is the successor of bind, which is used to setup the session in terms of activating features like enabling carbons, doing resource binding etc.
Topic 5: Lightning talk of Winfried about XMPP as a mandatory communication standard for healthcare in the Netherlands.
The Dutch ministry of health wants to have more standardization in the industry. Starting with email, they are pushing for the usage of tried and tested standards. The Dutch government, being also interested in interoperability, are keeping a list of open protocols and are looking at XMPP as a possible solution for communication.
There are some hurdles though:
Whats needed to push XMPP more in this domain is sponsorships to be able to have a voice.
There is also quite a lack of knowledge on instant messaging from important actors in the area.
It is unclear, how the XSF can keep a neutral position while supporting this endeavor.
> messages from MUCs are only automatically copied to the users MAM archive when the user is joined the chat room
Is that part of the MAM spec, or just current implementation in ejabberd and Prosody?
@stevenroose The problem is that MUC joins are not persistent at the moment. If you take a look at a MUC and its participants you will only see people that are online right now.
Thats a problem with the specification and is addressed in MIX.
@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.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.