3 Jun
2024
3 Jun
'24
4:06 p.m.
Le lundi 3 juin 2024, 14:58:23 UTC+2 Marvin W a écrit :
My client implements both old and new OMEMO and adapts to the right version
thanks to namespaces.
Doing a new XEP would not have changed anything. People have implemented OMEMO
because there was a need (and pressure from users and other IM solutions).
Waiting for a new version years later would have only put XMPP in oblivion.
Now, projects have to handle priorities, and the current version is working
well enough that they handle the implementation when it makes sense to them.
Also the "proper" new version is more difficult to implement, so it makes sense
that it's done progressively.
I've never said that. I've just said that the current situation, and I've
actually said that it's not good.
It's actually quite the opposite: my point is that I would like to make it
easy to create a minimal specification, with enough information to be
implementable. A Council vote would ensure that the minimal requirements for
an implementation are there, and then the feedback, update, and experiment
cycle can start. This would be far better than having to rely on
specifications, code, and dump snippets scattered all over the web.
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.
Changes don't cause incompatibilities, we have namespaces to handle that.
You can perfectly adapt to the change according to namespace.
The issue is that people are afraid that other won't implement new things.
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.
I totally disagree on that. Namespace bumps are not that expensive and should
be used freely in experimental XEPs. But my position is known there, so
there's no need to continue in circles forever. I would like to see other
inputs.
> > 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.
If they have done it before there should be an experimental XEP. My point is
actually that experimental XEP should be easier to produce. And we may not all
work the same way, but implementing, and writing specification can go in
parallel to clarify and draft an idea. Then experimental is there for
community feedback/update/experiment cycle.
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" -
Why is that? People can try to implement this version and give feedback on
what is good, bad, or ugly, or even without implementing it. Why would it not
be okay to update it based on experiments and feedback after a period of two
months?
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.
Of course, the process would take longer: pre-announcement, explanation,
waiting for feedback (how much? 24 hours? 2 weeks?), understanding feedback,
explaining that the idea was not understood correctly, etc.
Here, everybody knows that work is done on a specific topic when protoXEP is
submitted, work has started, everybody can read the spec to see exactly what
is it about and the vision of the author, and feedback.
I don't says that pre-announcement is a bad thing, but it's clearly delaying
everything and may actually make things more complicated.
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.
I don't see a problem that people do implement experimental feature, but if
they consider it as stable, that means that they can't read big red warning
(or just the warning and state, people may be colorblind).
Not sure about others, but I do implement experimental feature, I do expect
them to break, and I'm not worrying because there are namespaces. Actually,
why do you even think that developers don't expect the XEP to change?
"break"
is not even the right word here because they don't break precisely because
there are namespaces.
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.
Certainly not "publicly release and distribute software that uses it to a
large userbase", who has said that?
A first draft of a specification describing what is the idea, what is it used
for, and how to implement it is certainly very much useful.
Regarding the choice of implementing or not something, it's the job of
developments teams, not of XSF.
[SNIP]
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.
No, OMEMO was implemented due to need and pressure, and it's a good thing that
it was done because it took years to have a good version.
In the meantime, support for OMEMO has been advertised as a strength of XMPP
in literature for years.
It is absolutely possible to have old and new versions running in parallel (my
client does it), and clients will eventually do so when the need arises. There
are already several clients implementing OMEMO:2.
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.
So, clients that implemented OMEMO when it was just a web page outside of the
XSF would no longer be considered "XMPP clients"? If you want to kill XMPP
once and for all, that's probably the best way to do it.
Best,
Goffi