3 Jun
2024
3 Jun
'24
2:58 p.m.
Hi,
On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote:
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.
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.
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.
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. 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. 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