Re: [Standards] A Meta-Discussion about the Standards Process
On Fri, 17 Jan 2020 at 19:28, Marvin W wrote: > On 1/17/20 11:38 AM, Dave Cridland wrote: > > Well, yes, but the majority of our end-users are probably Fortnite > > players, and they're not talking to us. > I should have been more precise: I was talking about the open XMPP > ecosystem, not any closed/walled garden XMPP implementations with own > client/server and without federation. Those don't care too much about > the standard anyway (they can just do proprietary vendor extensions and > probably do). > > That depends. In my experience, a lot of the draw for XMPP is the fact it's an off-the-shelf solution with interoperable pieces. That's (at least) a by-product of standardization. So, for example, Pando (my employer) uses a lot of standards-based things, and things which aren't standards but are still off the shelf (like ESL's MUC Light and Inbox). There is some proprietary stuff, but there's also a lot of "throw this thing in a message", which is not so useful (hence UDT). Everything we do, though, is moving toward the standards - where we haven' is mostly expediency. And Pando is (currently) a custom client talking to a single XMPP service; in the terms you've described, it's a closed walled garden. (I'll talk about, and show, our app at the Summit for those interested; it's used across the National Health Service in the UK by Doctors, Nurses etc as a primary communications tool). But there are also lots of closed networks where the ability to use an off-the-shelf client and server is very useful, and plenty more where at least using a fully standardized server is useful. Fortnite is the latter, and while I'm struggling to think of a good example of the former, they do exist. And then there's the militaries, where despite a closed network, there's a lot of federation, and standards are fully mandated. Some players in that market handle this by simply adopting standards, others handle that constraint by very active involvement in the XSF and produce a number of XEPs - and many of those are of use for a wider audience. > The reason why WHATWG worked is that their specs were implemented by the > majority of browsers (counted in users) and thus websites can and will > rely on these specs. As soon as they do, any other browser will need to > implement the same spec to stay compatible or loose even further market > share. "Fortnite" wouldn't matter because they have a browser that can > only display a single website and that website is only ever displayed in > their browser. > > Yes; the effect has also been to gradually reduce diversity in the browsers, and lock out new entrants. But I think we're already agreed that WHATWG, for all its successes, has had some serious downsides. In the chatroom, after Guus commented on the one-liner you've replied to, I said: [10:48:05] dwd: I probably should have expanded on that. But "consumer-grade" instant messaging is pretty small beans for XMPP. Embedded use of XMPP into games is, I think, the largest use by numbers of users, and I'm not sure what would be next - probably military, though possibly financial trading. [10:49:28] dwd: That doesn't mean I don't think consumer-grade messaging isn't important, or that we should ignore enterprise messaging (ie, Slack) because we're barely present. Strategically, both those make more sense to concentrate on than gaming (and won't harm gaming either), at least in terms of features. I'll expand on this yet further: The specifications we produce have to have relevance and adoption, that's certainly true, and the consumer-grade messaging that the majority of the Open Source folks are dealing with day-to-day is a very useful guide to this. The military, being people, too, will end up using emoji-based reactions - in fact, they'll probably mandate their use eventually. So while the "personal IM" market is small for XMPP, it's probably leading in terms of UX, it's highly accessible for us, and it's a good guide to what's needed for current trends in messaging. Similarly, though we have even less footprint in the enterprise case, ignoring that would be extremely foolish for us - especially when the incumbents have some increasingly difficult to solve UX issues, and are edging toward some form of pseudo-federation that we can already give. We should, from a strategic point of view, be focusing on the well-defined needs of these two markets. What I wouldn't want to do is focus on these or any particular markets exclusively to the detriment of some of our other, often more outré and esoteric, markets, which don't seem as exciting (or as pure, or whatever). I appreciate that many have mixed feelings about the military use, for example, but I would hope even committed pacifists in the community can at least take some pride that XMPP dominates the military because of its technical qualities (and the fact it's a recognised Open Standard). The benefit to the community is that we have a more broadly applicable set of specif
Re: [Standards] A Meta-Discussion about the Standards Process
On 1/17/20 11:38 AM, Dave Cridland wrote: > Well, yes, but the majority of our end-users are probably Fortnite > players, and they're not talking to us. I should have been more precise: I was talking about the open XMPP ecosystem, not any closed/walled garden XMPP implementations with own client/server and without federation. Those don't care too much about the standard anyway (they can just do proprietary vendor extensions and probably do). The reason why WHATWG worked is that their specs were implemented by the majority of browsers (counted in users) and thus websites can and will rely on these specs. As soon as they do, any other browser will need to implement the same spec to stay compatible or loose even further market share. "Fortnite" wouldn't matter because they have a browser that can only display a single website and that website is only ever displayed in their browser. OMEMO is kind of an example where we got in a similar situation: so many clients (counted in user numbers) in the open XMPP ecosystem do support it, that to stay compatible with the ecosystem, you kind of have to implement it. That's mostly not relevant for walled gardens though. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
On 1/16/20 10:50 PM, Daniel Gultsch wrote: Hi, > I think we are currently in a situation where developers implement and > deploy experimental XEPs which made us more and more careful of what > we accept as experimental. When I say clean up I mean advancing > certain XEPs to draft to get into a situation where developers can > take the "Do not implement this XEP in production" warning serious > again because there are enough 'draft' and 'stable' XEPs to choose > from. In the discussion up to now, and this is not a specific reaction to this comment, I am missing the question *why* a XEP doesn't advance. - does the council need more time to assess it? - is it abandoned by the author (but still useful)? - is it incomplete (too many ToDo's)? - does it have protocol issues? - are there IP issues? I would love to see bugtracking against XEP's and the council assigning labels to bugs when they are blocking propagation to the next stage. That would make the process clearer for XEP authors and inform developers on possible issues when implementing experimental XEPs. (Still, IMHO, it has to be very clear what criteria are used before accepting a XEP as official XEP and which XEP's are accepted as such and which not). Winfried -- privacy strategist & privacy architect +31.6.23303960 https://www.tilanus.com/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
On Fri, 17 Jan 2020 at 10:26, Daniel Gultsch wrote: > have potential to improve the current situation. The problem with the > status quo of how Council makes its decisions is that it is a > combination of tribal law and seemingly arbitrary judgment calls. If > we want to continue with the current status quo we need to codify the > rules that Council has been following in XEP-0001. To outsiders our > decisions must not seem arbitrary. If my XEP got rejected I need to > know why and I need to know that Council followed rules or guidelines > instead of just not liking me personally. For example, I remember the > rejection of MUC Light as being highly controversial and not very > well received by the authors.[1] > (I'll sort of reply to this backwards) You remember drama because there was - I vetoed that, so I remember it well. I don't often veto things, at least from my perspective, but I might be deluding myself. Moreover, I use the protocol now - we use it for team chats in Pando, because, as claimed, it works much better than XEP-0045 for mobile, though in fairness we're not using very much of MUC Light either - it just happens to be easier to drive form the MongooseIM API. It's also an evolutionary dead-end, and I haven't changed my mind that it's unsuited to Standards Track, despite the fact I'm using it. (Widespread support would be quite convenient to me and my employer, in fact). I know how frustrating it is to get a veto, as well - I suspect I might have written more vetoed ProtoXEPs than anyone else, but I can only imagine it's far worse to have your first attempt as a newcomer rejected seemingly out of hand. While I think I use the veto rarely (and I imagine statistics may surprise me), and I think I'm consistent, I'm fully aware that my consistency is not consistent with that of others - different Council people apply different, and entirely personal, rules. I'm all in favour of codifying the rules, but I think it'd be useful to understand from current and previous members of Council what they used as their personal yardsticks, and try to understand what the community at large thinks Council ought to be thinking about. Also, I have wildly different ideas about what's acceptable on the Standards Track compared to off it, and we really don't have much options but on it now. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
On Fri, 17 Jan 2020 at 10:31, Marvin W wrote: > Related to that: If XSF fails to provide what the *majority of users* > (even if it's a minority of developers) expect them to provide (in terms > of features or speed of adoption), we'll end up with something like > WHATWG: an independent working group of the top vendors that don't care > if their standards get accepted by the XSF because they can basically > enforce them through their market power. I don't think that's desirable. > Well, yes, but the majority of our end-users are probably Fortnite players, and they're not talking to us. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
On 1/17/20 11:05 AM, Kevin Smith wrote: > Yes, I agree with what I think you’re saying - if there is a spec published > that does what someone needs, they will implement it regardless of what the > state says at the top (or any warnings about readiness). The “Inbox+” idea > mostly just accepts that and uses the pre-XEP track to make it easy for > people to understand the state of things - because as well as the issue that > if there’s a spec people need they’ll implement it, I also believe there is > confusion because “Well, it’s been published as a XEP”; What will make it easier or more obvious for people to understand they shall not implement a pre-XEP from inbox that we don't already have for Experimental today? > I have at least had people ask for things to be implemented (more by users > than XMPP aficionados) because they’re a XEP and therefore they are Good. I was always under the impression that users ask for features no matter if they are a XEP. "There is no XEP for it" is rather the lame excuse by developers to not implement a requested feature. If people ask you to implement a XEP (being it pre-xep, inbox, experimental, rejected or deprecated) I'd already classify them as "XMPP aficionados" to some degree. Related to that: If XSF fails to provide what the *majority of users* (even if it's a minority of developers) expect them to provide (in terms of features or speed of adoption), we'll end up with something like WHATWG: an independent working group of the top vendors that don't care if their standards get accepted by the XSF because they can basically enforce them through their market power. I don't think that's desirable. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
First of all: People move mountains all the time. That’s how the new Hong Kong airport got built. I think that both approaches * Status quo + Super-Inbox * Follow XEP-0001 have potential to improve the current situation. The problem with the status quo of how Council makes its decisions is that it is a combination of tribal law and seemingly arbitrary judgment calls. If we want to continue with the current status quo we need to codify the rules that Council has been following in XEP-0001. To outsiders our decisions must not seem arbitrary. If my XEP got rejected I need to know why and I need to know that Council followed rules or guidelines instead of just not liking me personally. For example, I remember the rejection of MUC Light as being highly controversial and not very well received by the authors.[1] Codifying our current rules in XEP-0001, even though I believe that our current rules in combination with Super-Inbox would work out somewhat OK, is the mountain that *I* don’t want to move. cheers Daniel [1]: Take that with a grain of salt. That was at the time of my very first Summit and I had just become a member and I might remember drama where there wasn’t really any drama. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
On 17 Jan 2020, at 09:54, Marvin W wrote: > > On 1/17/20 10:29 AM, Kevin Smith wrote: >>> I need a feature X *now* and all I see is >>> an experimental XEP I have two choices; Implement that Experimental >>> XEP or create something myself. >> I don’t think making the barrier to entry to Experimental lower (or Draft) >> will change that fact, so if this assessment of the cause is right, we’ll >> still be in the same position > > I think the important part when having a higher bar on Experimental is > that it won't solve this issue either. The higher bar already means that > people start implementing things that are in inbox. This happened for > example with the Reactions XEP and if I wanted to implement Reactions > today, I'd certainly use what is in the inbox now. Also aesgcm links are > widely used while stuck in inbox. > > To phrase it differently: > > Previous way: > Deemed ready by XSF: Draft+ > People implement: Experimental+ > > Current way: > Deemed ready by XSF: Draft+ > OKish by XSF: Experimental > People implement: Inbox+ > > I don't see any improvement. It will always be the case that some people > implement the protocols as soon as they are publicly accessible and if > it turns out those protocols work well enough, others will follow. > Having a higher bar before the XEP is adopted by XSF will just result in > less being adopted by XSF and not less (pre-)experimental things being > implemented. Yes, I agree with what I think you’re saying - if there is a spec published that does what someone needs, they will implement it regardless of what the state says at the top (or any warnings about readiness). The “Inbox+” idea mostly just accepts that and uses the pre-XEP track to make it easy for people to understand the state of things - because as well as the issue that if there’s a spec people need they’ll implement it, I also believe there is confusion because “Well, it’s been published as a XEP”; I have at least had people ask for things to be implemented (more by users than XMPP aficionados) because they’re a XEP and therefore they are Good. I think it might also be easier for us to stick to that process than the current one, which experience suggests is easy to let slip. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
On 1/17/20 10:29 AM, Kevin Smith wrote: >> I need a feature X *now* and all I see is >> an experimental XEP I have two choices; Implement that Experimental >> XEP or create something myself. > I don’t think making the barrier to entry to Experimental lower (or Draft) > will change that fact, so if this assessment of the cause is right, we’ll > still be in the same position I think the important part when having a higher bar on Experimental is that it won't solve this issue either. The higher bar already means that people start implementing things that are in inbox. This happened for example with the Reactions XEP and if I wanted to implement Reactions today, I'd certainly use what is in the inbox now. Also aesgcm links are widely used while stuck in inbox. To phrase it differently: Previous way: Deemed ready by XSF: Draft+ People implement: Experimental+ Current way: Deemed ready by XSF: Draft+ OKish by XSF: Experimental People implement: Inbox+ I don't see any improvement. It will always be the case that some people implement the protocols as soon as they are publicly accessible and if it turns out those protocols work well enough, others will follow. Having a higher bar before the XEP is adopted by XSF will just result in less being adopted by XSF and not less (pre-)experimental things being implemented. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
(Snipping bits that hopefully don’t cause a misrepresentation of Daniel’s views) On 17 Jan 2020, at 09:18, Daniel Gultsch wrote: > It *almost* feels like we shifted our stages to the left were Draft is > the new Final and experimental is the new Draft. The latter is > currently less true than the former; However I’m afraid that > introducing a stage before experimental will make us raise the bar to > experimental even more and complete this shift. I won’t pretend that this is impossible. > I also don’t think that we got here because people didn’t understand > what Experimental meant but because people had no other choice. I mean > if I'm a developer, somewhat outside the XSF (and every developer > starts out like this), and I need a feature X *now* and all I see is > an experimental XEP I have two choices; Implement that Experimental > XEP or create something myself. This is kinda the point I’m (failing to) make(ing) about Muhammad and Mountains. I don’t think making the barrier to entry to Experimental lower (or Draft) will change that fact, so if this assessment of the cause is right, we’ll still be in the same position - if someone wants to implement something something that’s a XEP they’ll implement it regardless of the formal state it’s in (I hope this isn’t misconstruing what you said). While reducing the number of things in the state that we believe isn’t ready to implement will reduce the surface for this, I don’t think it fundamentally addresses it. > The truth is probably somewhere in between people not understanding > this (and/or at least not seeing the full consequences) and our > failure to move things to Draft more quickly. In any case I think > those two factors are reinforcing each other and we need to stop that > cycle. Moving things to Draft sooner will reduce the surface, yes, but I’m not sure (see above) that it really addresses the issue. > The answer to "people don’t understand the nuances between our 5 > different stages" can’t be "let's introduce more stages". I think that’s possibly true - *unless* the reason that people don’t understand (or are forced to ignore, whichever) our stages is that our stages don’t map cleanly onto people’s expectations, in which case it might be reasonable to move us to the mountain. > On interesting point about the super inbox / non working group draft > version is that it would probably be easier to fork drafts if the > original author is unresponsive. For example if draft-kile-mix-01 is > not moving fast enough I could just create my own > draft-gultsch-mix-01. However I’m not fully sure if we would want to > do that in super inbox and/or if we couldn’t just do something similar > in experimental. Yes, that’s an interesting thought. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
I didn’t want to respond to this last night and then Dave already made most of the points for me. (Which however won’t stop me from repeating some of them.) Am Do., 16. Jan. 2020 um 22:17 Uhr schrieb Kevin Smith : > Tidying up the unlawful East cost to make it more like the well-policed and > gunless wild West (ok, I’m not going to pretend to be cultured or a student > of history) is easier to see (for me) through to the end goals. We got here, > at least in part, through people not understanding that Experimental means > Experimental, and implementing and putting these things in production anyway > - how would we go from here to where that’s not happening? There are also > implications on Draft - where Draft’s barrier to entry would have to be > lowered in order for implementable XEPs to move in with our friend in the > wild West country, or no tidying up is really possible - if things that > previously we thought weren’t ready to Draft because there were likely to be > further changes that we wouldn’t want to inflict on (informed) production > implementations become Draft, what are the implications for the deployments > who expect Draft XEPs to be somewhat stable (as now). I think it would be OK to lower the barrier to Draft from it's status quo back to what is spelled out in XEP-0001. Currently the barrier to Draft is crazy high and to me, in practice, almost indistinguishable from Final. I think this is evident in two things: * One of the questions in the Last Call is: Are you *planning* to implement this. To which we regularly get responses like: I already have. * I have never witnessed a XEP actually getting to Final even though we have multiple Drafts that fulfill the 'implemented in two implementations' criteria. It *almost* feels like we shifted our stages to the left were Draft is the new Final and experimental is the new Draft. The latter is currently less true than the former; However I’m afraid that introducing a stage before experimental will make us raise the bar to experimental even more and complete this shift. I also don’t think that we got here because people didn’t understand what Experimental meant but because people had no other choice. I mean if I'm a developer, somewhat outside the XSF (and every developer starts out like this), and I need a feature X *now* and all I see is an experimental XEP I have two choices; Implement that Experimental XEP or create something myself. The truth is probably somewhere in between people not understanding this (and/or at least not seeing the full consequences) and our failure to move things to Draft more quickly. In any case I think those two factors are reinforcing each other and we need to stop that cycle. The answer to "people don’t understand the nuances between our 5 different stages" can’t be "let's introduce more stages". On interesting point about the super inbox / non working group draft version is that it would probably be easier to fork drafts if the original author is unresponsive. For example if draft-kile-mix-01 is not moving fast enough I could just create my own draft-gultsch-mix-01. However I’m not fully sure if we would want to do that in super inbox and/or if we couldn’t just do something similar in experimental. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
