Hi, On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote: > Experimental is for the specification. Adding whatever status or > workflow change > you want will not prevent developers from implementing whatever they > feel is > relevant. People have been implementing things that were not official > XEPs > because they felt they were relevant, experimental or not (e.g. OTR, > OMEMO).
In cases where things got widely adopted without being a XEP in first place, we use Historical XEPs to document that. Of course people can always implement things that are not official, but in this case it's obvious that they may have incompatibilities and take special care of this. > Some teams may choose to implement only stable specifications, others > want to > move fast. I'm in the latter case and I'm okay to refactor or even > rewrite > something entirely once experience is gained. And I think that both > ways are > perfectly fine. It's not as soon as your change causes incompatibility issues with other clients if they don't follow and also "move fast" and implement experimental functionality - and if everyone needs to follow yours to be compatible, it's effectively stable, because changes can't be done without breaking compatibility again. So we should just move forward and call it stable, and be happy to fork into a new XEP number that supersedes the old one if needed. > The "experimental" state is clear: it may change and break. That seems to not be clear to anyone, to be honest, especially not end- users and also not in how we market our products. OMEMO is in Experimental and yet a lot of clients feature it as regular functionality and breaking it would have terrible consequences and render communication between some clients impossible. Realistically, siacs OMEMO (XEP-0384-v0.3) is in fact a stable specification, even if we wanted to and eventually did breaking changes to it afterwards. It's a mess. The cleaner way would have been to advance v0.3 to stable and do a new XEP for a second version OMEMO that is what the current XEP. If I want to go to the extreme, I'd say that if something needs a namespace version bump, because an incompatible change was made to a specification that was already implemented and deployed, something went wrong. One XEP should match exactly to one namespace and a new version should just be a new XEP. > > "Stable" may not be desirable for a while. For instance, I've not > requested a > state change on purpose for submitted specifications such as "XEP- > 0356: > Privileged Entity" because I knew that it would take time and > experimentation, > and moving to stable would prevent that. > I've made important changes years after the original submission. > > Also, I was working on the only software using it at the beginning; > now at > least Slidge, a popular bridge, is using it, and its feedback may be > valuable > for updates before moving to stable. > > > > > I suggest that we clearly state somewhere (such as in a "write a > > > proto-XEP" > > > document) that talking to the community before starting any work > > > is > > > highly > > > recommended. However, this should not be mandatory, as people may > > > be > > > experimenting with ideas and specifying them at the same time. > > > > I agree it shouldn't be mandatory, but also we should encourage not > > only talking with the community before writing the XEP, but also to > > talk with the community before experimenting with the ideas. > > Because > > others might have done that before and/or have ideas that are worth > > including in the experimentation. The XEP creation process starts > > with > > the idea, not when writing it down, and IMO we need to find ways > > and > > provide the tools to support XEP creation before the formal writing > > process. > > Once again, experimental is for that. Writing things down helps to > clearly > explain them and how we intend to do them. It's not a starting point > for a > feature, but it's definitely a good starting point for wider > discussions. Experimental certainly is not the place to just dump an example. You also don't create an Experimental XEP "I want to do Remote Control and will upload content here in 2 months after my experiments" - but I would want to encourage both public pre-announcements and a place to publicly scribble ideas. Of course writing things down properly helps to find these things, but it also means that the process takes longer and feedback and collaboration will only be possible at a later stage - which can worst case mean more wasted energy and time, and we all don't really have energy and time to waste. > As I've mentioned above, experimental or not, whatever new workflow > won't > prevent developers from implementing an unstable feature if it is > relevant to > them. Experience has shown this to be the case more often than not. The problem is that people DO implement features based on Experimental and consider this de-facto stable. That's why we do namespace version bumps: because developers don't expect the XEP to break, otherwise it would be no issue to change things in breaking way without namespace version bump. Reality is: The big red warning doesn't change how people see Experimental XEPs and claiming it bigger while not changing how we actually treat it really isn't going to change it. > > > So my personal takeaways on this are: > > > > === > > > > 1. We should move to stable faster. Developers that want to release > > functionality to their users that requires Experimental XEPs need > > to > > step up and push to accelerate the process, so that they don't have > > to > > release based on Experimental XEPs. > > Relevant for some XEPs, but not all. Some time you don't want to move > to draft > on purpose, because you want to gain experiment, and feedback from > others. You > also need something written as a basis for discussion. My XEP-0356: > Privileged > Entity specification is an example. Gaining experience and feedback from others and discuss doesn't require to publicly release and distribute software that uses it to a large userbase. Experimental is totally for these things: experimenting, discussing, incorporating feedback. It's not for production, because then you typically can't break anymore without terrible consequences. XEP-0356 might be a special case here, because it is not very important that it has good interoperability. Most usecases require a single server to work with a single component and those to be compatible. We don't have a large landscape of clients and servers involved that need to all agree on a single standard. So breaking changes there might be easier even if already deployed. Additionally, all software using it is largely considered experimental as well. > As long as it's not mandatory, it's surely a good thing to interact > on > something as early as possible. I personally like to have something > written as > a basis for discussions. As I said above, writing a short mail to the mailing list "I am going to work on XXX the next weeks, who has done something in this area already?" is not a basis for a discussion and it's not meant to be. It's to get everyone informed and ensure we don't have duplicated efforts. This doesn't and shouldn't need to have something larger written. I also wouldn't want to do something like this mandatory, but it honestly wouldn't hurt if it was mandatory to publicly announce that you're working on topic X before proposing a XEP on the topic. > It is already clearly stated. There is a red warning at the very > beginning of > the specification. If people chose to implement it, they have reason, > and they > know what they do. As explained above, reality shows that this is not the case. OMEMO being a perfect example. We'll be stuck with a shitty version of it probably for another decade because people implemented it into production while it was pre-Experimental or still very much Experimental. So I do disagree, people don't consider the consequences of Experimental XEP because in practice, we consider Experimental XEPs stable and will namespace bump instead of doing breaking changes, so there are no compatibility issues. And clients tend to implement multiple versions of Experimental XEPs for good interoperability. > It's not the job of the XSF to say to developer how they should > present > features, and to tell them (beside current indicators) what to > implement or > not. We typically don't consider WhatsApp an XMPP client even if we know it's XMPP with just a bunch of not publicly documented "extensions". XSF can go as far and say "Client X is not compatible with XMPP as it implements a protocol that is still Experimental". We do keep a list of clients that "implement XMPP" so it is within the scope of the XSF to decide what it means to be an XMPP client and requiring that only stable specifications must be enabled in the default configuration of a client to be considered an XMPP client is certainly valid. Marvin _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
