[Standards] Requirements for "Jid Hidden" Channels

Sam Whited sam at samwhited.com
Sun Jun 3 15:38:41 UTC 2018

On Sat, Jun 2, 2018, at 18:22, Steve Kille wrote:
> Would you do me a BIG favour, and do a review of the new slimmed down 
> 369 (MIX-CORE).   I've worked to get this to a simpler and cleaner base.   
> I would be very interested to hear which aspects of this you still 
> believe to be too complex.

Let me start out by saying that MIX-CORE is now significantly easier to consume in isolation, and I really appreciate the work you've put into that. However, I don't think it's actually possible to read MIX-CORE in isolation. Eg. I get to 7.1.1 and read " The full specification of client interaction with the client's server is specified in MIX-PAM" so now I guess I have to go read MIX-PAM. Or I reach example 23 and read "the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants list. Presence removal is specified in MIX-PRESENCE" so I have to go read MIX-PRESENCE to understand what it's talking about and whether I need to be concerned with it.
Hiding some of the complexity in other documents doesn't make it go away, even if they're "optional" in theory. And MIX-CORE at least looks complex straight from the get go.

After I've cleared the initial requirements and intro sections the first thing I'm presented with is a giant table of documents that I'm told I might have to implement. This might just be a minor editorial problem that can easily be fixed, but it says "Only two of these XEPs are mandatory for providing a MIX service" and then presents a table that includes a lot more than two things marked as mandatory and a lot of section headers that aren't "MIX Service", so I'm not actually sure what it's talking about.
My initial thought when seeing this is that I'll never make it through all those and that I don't know what any of the column titles even mean (eg. what is an "Administrative MIX Client"?). That being said, I do appreciate having some sort of list so that I know hat I have to look at and don't have to go dig through the bigger XEPs list to try and find them.

> 4.6 Proxy JIDs

All of this. At the summit where we started to write the current implementation of MIX proxy JIDs were only added to support anonymous rooms. They were later made mandatory for everything, and while I agree that this simplifies things over using them sometimes and not others, I still think the underlying assumption that they are necessary as part of the MIX protocol is wrong. Having proxy JIDs is complicated enough, but on top of that we also have a new specialized JID format to deal with that encodes information in the local part.

> 5. Error Handling

This section is another list of documents that must be read and supported. I'm all for building MIX out of existing building blocks, but his is becoming a long list of dependencies that are spread over multiple sections and which I have to tease out of the document (and I haven't even started looking at the 6 other MIX documents).

In a more general sense, XMPP has a problem of trying to support everyones specific features while also remaining general purpose and future-compatible. The XMPP community doesn't seem to know if it's building a specific chat service meant to be run by many operators, a general protocol on top of which others may build distinct chat services that interop, or some mix of both. This means we start adding tons of specific features right out of the box. However, good software engineering and design should work the exact opposite way. We can always add features later. Good design is removing as much as possible without breaking things (I feel like I heard someone say that, but the only reference I could find was something vaguely similar in a recent blog post by Russ Cox, so apologies to whomever said it if it was a quote and I'm not citing you).


More information about the Standards mailing list