XMPP Office Hours/2021-04-13-Notes

Many topics got merged together / overlapped. Please disregard the headings. Sorry that formatting didn't translate, we'll figure out a better place to keep notes later.

Meeting agenda:

Add your topics for discussion! If there are too many we can figure out who's interested in what and do breakout rooms and then come back together for a summary before we end!

   Modern messaging experience (inbox, markers, reactions, carbons).

   Ease-of-setup for (new) communities (choosing a service, anonymous MUCs, etc.). Are there protocol-level changes that might help here? Organization-level? (AlexP)

   Mobile First (improvements towards better support on crappled devices like iOS) / Merging in: Has XMPP as a network protocol failed? Should we focus on the application level in an XMPP 2.0 (ie. just IM or other applications) / also merging in: JSON-like stanzas? Something more compact than XML? / also merging in: Moving to/having the option for a non-TCP based protocol (e.g. QUIC)? Would likely help with mobile, server deployments. (AlexP)

   Get rid of one-to-one messages, MUC and MIX. Base everything on PubSub.

   Merging C2S/S2S protocols?

Notes:

Modern messaging experience

Nelson: (about modern messaging exp.) After reading https://snikket.org/blog/products-vs-protocols/ Nelson started thinking about this. XMPP competes against services like Whatsapp, but it's a protocol as well like email. But most messaging are closed silos. However, they have very nice UX. As an open protocol we can provide a bigger network, but we don't tend to keep up with the commercial services in terms of UX, we create XEPs in a reactionary way after something else popularizes it.

Sam: we don't have a product manager for the Jabber network or any concept of that, this may be a problem. Also I think we have some procedural issues at the XSF that cause problems such as accepting XEPs that aren't implementable or having lots of XEPs that do the same thing and the network becomes fragmented.

Dave: Inbox started as an implementation in Mongoose with the idea to improve UX on mobile/web clients. Dave wrote it down as a XEP and "threw it out there" (I haven't caught the rest, feel free to add)

Nelson: Rewrote the Inbox code of mongoose. People were asking about the inbox XEP and were asking questions about how it works, but the xep no longer mirrors the mongoose implementation. Other things that need improvements (in XMPP) are markers, reactions, carbons

Daves Dogs: *bark*

Sam: If anyone wants to improve the situation, an office hours talk is a great start!

Dave: XMPP as two things: A platform and a complete product. Those two have different demands. XMPP is among others a building block to create products. Inbox is one modular piece that you can use to build a service.

Kev: People build with XMPP. Role of XSF: Listen what they want to build and create XEPs for what they want to build. Thats hard. If we build XMPP 2.0 we should focus on finding out how make it that the different XEPs play nicely together as a whole.

Ease-of-setup for (new) communities

AlexP: Not directly involved in XMPP development. Thinking about how OS communities are mainly irc-based, now moved to gitter, matrix, slack etc. XMPP has no easy to setup services. Also protocol level issues that prevent mass-migration of users to XMPP. Some related to performance (MUC not scaling well). I'd be interested in how XMPP can be viable choice for those comms. Are there anonymous MUCs or anything like we see in other solutions?

Sam: Freenode has anon auth which stands out. Not sure if there are XMPP clients with that feature.

Dave: wonders if anybody knows about freenodes plans to switch to xmpp (a few years ago)

Sam: If they were planning, all bridges are impossible to discover from xmpp and hard to use

Dave: arc planned to put S2S support in irc server, but nobody knows

Zash: MattJ said something about that the other day

Daniel: Good example of bad interop in xmpp. ejabberd breaks stanza queue if irc room with hunderds users joined. Pieces dont fit well together

Alexp: XMPP2.0 sounds like protocol level. Solving isues requires org/proc level changes as well to allow for coordination. XMPP used in integrating or building products that are not sold as such (gaming, nintendo switch). Knowing who to cater for is hard.

Kev: (to daniel): Focus on resumption is less helpful than full press on rapid startup. Really want to reconnect rather than quickly know what happend since you left.

Sam: (about his time in hipchat?) How quickly does send button turn green is biggest indicator of whether customer wants to buy solution. Distinction between matrix model (one giant xep, only two servers, no real decentralization, trivial client implementation) vs. us (many client features, complexity on clients, hard to interop, many servers).

Kev: You remember the XMPP motto is complex server, simple client, Sam? :D

Sam: We fail at that badly

Nelson: Connection establishment slow. Many roundtrips until chatting. – There's the TCP handshake, then the TLS handshake, and then the many-roundtrips XMPP handshake. Session establishment seems slow.

Dave: Space for both (fast sess resumption, fast sync). Too much focus on resumption. Can we boost compliance suits? Can we make them more well used, more heavily impactful (not in the hipster startup way)

Sam: *bunch of hot words*

Kev: Resumption - yes we need both. Compliance suits - instead of thinking of them as comp suits for clients, we need to see them as guides ("how to write a client"). Explain how to write your client in useful way, these are the XEPs you need. Like Ge0rGs Client Test Cases (link https://wiki.xmpp.org/web/Client_Test_Cases). Interop through guides, not comp suites.

Sam: had such in mind in 2015. Two talks on FOSDEM mentioning features that they did not know about, so suites have good impact. See them more like product management guides. modernxmpp is going in a good direction.

Daniel: compliance.conversations.im tests servers, not clients. RESTish alternative to XMPP? iOS has exceptions for http connection stuff.

Sam: XMPP as IM only? Dropping unrelated stuff?

Kev: What does XMPP look like if we didn't have to deal with backwards comp? We CANT drop interop with older servers etc. but we CAN think about how it would look like and what we would like. S2S works *hahaha*. What would an "XMPP JMAP" look like? What are the drawbacks.

Dave: What iOS can do with http is hand over things to OS (like share) and http can then execute the task. XMPP is much more complicated on iOS. Standardized REST interface to XMPP, not as replacement to C2S but as HTTP interface to control headless client. You ocnnect to client with http. Why not replace C2S: end-to-end principle. But controlling client with REST would be interesting thing.

Daniel: Anecdote: contracting for IM service - new requirement: bot API. First thought: XMPP is API. Not feasable. Avg. dev expects rest api with json. No stanza dance etc. So REST API not only for replacement of XMPP on iOS devices, but also useful for bot development. Keep XML, otherwise server would need to translate.

Dave: webhook interface would be different to client-control-interface but also very interesting

Kev: (i was distracted, pls add)

Merging C2S/S2S?

Alexp: Lets merge S2S and C2S protocols

Dave: pain that all things in differet namespaces although they are so similar. There are differences we need to distinguish. Namespaces drive me nuts.

Sam: We have overlap of protocols. But we want to be able to validate XML. Please leave layers strictly separated.

Dave: makes funny joke. You should have been there!

Kev: Early mistakes colored by external influences.

Alexp: Stateless protocol on server layer would improve situation in environments where processing time is limited (eg. processing as a service)

Dave: we break interop all the time, there are always servers talking slightly different protocols. (XEP-0361 gets mentioned)

emus: Thanks Sam for introducing XMPP office hours! Are there other non-technical levels we can think of for XMPP 2.0? For example organization in the community?

Sam: Please add your own topics to the office hours schedule everyone!!!!111212

Copying notes somewhere that they won't be deleted after a while. Thanks to whomever took over note taking!