Recently we held another XMPP sprint, this time in Dusseldorf at the Chaosdorf clubhouse.
We had 10 participants and an ambitious agenda with a long list of proposed topics to sprint on. We didn’t get to work on everything, and we spent a considerable amount of time discussing and prioritizing the agenda. Some of the things not worked on can however easily be moved to future sprints. After the sprint, iNPUTmice suggested that we consider having more focused sprints, for example focusing only on implementing XEP-369 MIX in clients and servers.
I think having a more focused, single-topic sprint is a great idea, and MIX is a good topic to tackle. AFAIK there’s currently no FOSS MIX implementation for either clients or servers. IMO this can partly be attributed to a stalemate situation where everyone is waiting for someone else to make the first move. By organizing a sprint around it we can break the deadlock by starting to work on it together. Discussions
Easy-muc-joining (jcbrand, Ge0rG, pep., Link Mauve)
This was related to the Easy XMPP Invitation work already done by Ge0rG. When using a supporting client, you can generate a URL to a landing page which makes it easy for someone to create a new XMPP account and/or to join a groupchat (aka multi-user chat, MUC).
For “easy MUC joining”, the goal is to figure out whether a MUC is hosted somewhere in a webchat, and to present this to the user so that they’re not forced to choose, download and install a desktop client.
Various approaches were discussed and eventually we decided that since the invitation URL is generated by a MUC service, that MUC service can also encode in the URL whether it has an associated webchat or not.
Initially we thought about using XEP-0156 service discovery on the MUC, but after discussing it futher with Ge0rG, we agreed that XEP-0401 Easy User Onboarding can be extended to MUCs as well, so that the MUC can be queried similarly to how a user invitation is generated.
MUC Push Notifications (jcbrand, iNPUTmice, Ge0rG, MattJ, Link Mauve)
XMPP has an extension XEP-0357 which allows you to register an external push service (such as Google Play for Android) to which messages can be pushed when you’re offline.
This approach can also be used for registering a push service that sends out email notifications. This is especially useful in a teamchat setup (like Slack, Mattermost, etc.).
XEP-0357 calls the push service the “app server”, but I find this terminology confusing and too much tied to the mobile use-case, so I’ll stick with “push service” instead.
XEP-0357 currently doesn’t mention MUCs at all and we wanted to discuss how registering a push service for MUCs would work.
Before this sprint, I wrote a proof-of-concept Prosody module, mod_muc_cloud_notify which can be used with Converse.
That module has the requirement that the MUC knows the JID (Jabber ID) of all the users, so that it can keep track of the push services registered for them, and it needs to know the JID even when the user is offline. Additionally the module requires that XEP-0372 references are used to make it clear when someone is mentioned.
This restriction means that anonymous rooms are excluded, and requires that all users register their nicknames on the MUC.
iNPUTmice proposed simply keeping some kind of token other than the JID, to keep track of registered push services, removing the need for nickname registrations.
Additionally he suggested sending all messages to the push service, instead of sending only messages in which the offline user is explicitly mentioned. This opens the possibility of configuring the push service to also notify you based on other criteria, for example when a particular keyword or phrase is mentioned.
We agreed that XEP-0372 is broad enough for this usecase and that we don’t need a new XEP.
Sync open conversations across clients (pep., iNPUTmice, Ge0rG, Link Mauve, MattJ, jcbrand)
A common request I’ve received from customers, and something which isn’t yet solved in a standardized way, is the ability keep track of open conversations across multiple chat clients (e.g. Desktop, mobile and web) or sessions and to quickly get information on the amount of unread messages or mentions in those conversations.
We spent a substantial amount of time discussing this feature, trying to cover as many use-cases as possible while coming up with something elegant.
Eventually it was decided to split the requirement into two parts and to only discuss one, leaving the other for a later date.
The two new requirements are:
- To keep track of open conversations across chat clients (and chat sessions)
- To get an overview of unread messages and mentions for those open conversations
The proposed solution for #1 is to use a private PEP node containing a list of JIDs representing open chats.
Like the Bookmarks2 specification, items should be stored separately, so that they can be added and removed individually (i.e. without having to specify the whole list).
This will require us to fix PEP so that we can get deletion notifications.
MUC JIDs aren’t stored in this list, since we already have the auto-join feature for MUC bookmarks. Private MUC chats will however be stored as well.
XEP-0283 <moved/> (pep., Ge0rG)
XEP-0283 provides a mechanism for informing your contacts that you’re changed your account and now have a new JID.
pep. and Ge0rG had a discussion on how to automate the operation entirely.
Currently the security considerations contain a clause which to them defeats the point of the XEP:
“In order to prevent other users from maliciously altering contacts the client SHOULD NOT automatically subscribe to a
JID when it receives an unsubscribe and SHOULD NOT automatically unsubscribe to a JID when it receives a subscribe.”
Also the XEP uses presence stanza only, which makes the whole operation rather ephemeral.
The plan is to change the XEP to use PEP mostly.
Programming, documentation and various other tasks
iNPUTmice added two new tests to the compliance tester, one for MUC Avatars and a check for CORS Headers on HTTP Upload, which is especially important for webchat clients like Converse.
He also tried to fix a bug in Conversations that happens intermittently on Android 9.
MattJ worked on the 0.11 release of Prosody. He also worked on adding support for CORS in mod_http_upload.
pep. registered an XMPP assembly for 35C3. He also worked on the slixmpp OMEMO plugin and got decryption working. Additionally he and Link Mauve worked on a French translation of the Prosody release announcement.
Link Mauve worked on implementing Jingle in Converse, fixing bugs and updating strophe.jingle.js to not use jQuery. As part of this, he and I looked at better exception handling in Converse.
He also helped pep. and syndace with the slixmpp plugin interface and spent some time trying to deploy JSXC.
Roel worked on the homebrewserver.club article on how to configure a modern XMPP server. MattJ helped out on Sunday as well and AFAIK their collaboration also caused MattJ to add some clarifications and simplifications to the Prosody config file.
Roel and rtq3 also worked on a Spanish translation of the homebrewserver.club article.
Syndace worked on resurrecting a non-merged PR from Andy Straub for the OMEMO XEP which adds various changes to the XEP, including using an XML-based wire format. By choosing our own wire format, we also make permissive OSS licensed OMEMO implementations possible. Such a change will however not be backwards compatible with current OMEMO implementations.
Andy joined us on Sunday and participated in discussions around the PR and OMEMO in general with iNPUTmice, pep and Syndace.
Haeckse showed us a demo of Chatty, the chat (and SMS) client that she is working on for the upcoming Purism phone.
I worked on adding support for XEP-0156 to Converse, based on a PR from Link Mauve. The original PR was closed, due to being very old and difficult to merge, and work is now continuing in a branch with a new PR #1340.
I also made smaller fixes and changes, for example only rendering image URLs inline if they use HTTPS (to avoid mixed-content warnings in the browser).
Conclusion
Chaosdorf
Much thanks to Chaosdorf, for generously making their clubhouse available for the sprint.
Kuro even made some chilli for lunch and baked a cake!
In the evenings we went out to dinner. Dusseldorf has a large Japanese population, so we were quite keen to try out some Japanese food.
I had proper Ramen for the first time on Sunday night and on Saturday we had some great sushi.
Future sprints
A sprint can be measured by its output in the form of code, documentation, translations and so forth, but this only tells part of the story.
Much of what makes sprints valuable is the social aspect of making friends and working together on something you all care about.
One way to judge the success of the sprint, is to consider how excited the participants are about organising and attending future sprints.
Roel intends to organize a sprint in Brussels, around the time of the XMPP summit and FOSDEM. This sprint will focus on UI/UX issues and on finding a common user-facing terminology for XMPP clients. Roel comes from a design background and will be inviting some fellow like-minded designers to join.
Link Mauve indicated that he’d like to organize a sprint in Paris in 2019 and pep. thinks we should go to Sweden.
During our sprint we also found out that the Berlin XMPP Meetup group is considering organizing a sprint there soon.
Then there’s also the upcoming 35C3, where there will be an XMPP assembly and the opportunity to hack together.
Thanks to everyone who joined the Dusseldorf sprint, some of whom spent a considerable sum of money in order to be there. I had a great time and am looking forward to more such events coming in 2019.
Come chat with us
We hang out in the XMPP-Sprint groupchat and this is also where upcoming XMPP sprints will be discussed and planned.
You can visit the webchat at https://chat.cluxia.eu/anon/#xmpp-sprint or click on xmpp:xmpp-sprint@chat.cluxia.eu?join to open it in an installed client.
