4 Jun
2024
4 Jun
'24
10:38 p.m.
Hi Marvin,
Le mardi 4 juin 2024, 17:29:00 UTC+2 Marvin W a écrit :
Hi Goffi,
Thanks for your message.
I know I'm not particularly good with words and my language sometimes
tends to be perceived as aggressive or exclusive. I did not intend to
attack or insult anyone and I apologize if I did.
Thanks for your balanced reply. I'm not always diplomatic either :).
Thing is, most of us are putting a lot of effort and passion into our work,
often for many years. We may disagree on strategy, the way to do things, etc.
This is perfectly fine and that's why we are discussing.
But I trust the community to know well what it is doing, and even if we may
disagree on the right way, I believe that dev teams know what they are doing.
The people that *first* implemented and deployed OMEMO
to a large
number of end-users of the public XMPP network, before making a
reasonable effort to stabilize the specification and to actually get
the implementation itself to a stable state were in my opinion acting
too careless.
It's not always black and white, and to some degree the fault was and
is often the XSF here, which is what this discussion was meant to be
about: To adjust our XSF procedures to better reflect the need of the
community.
OMEMO was a mess, I think we all remember the days when half the
messages on half of the devices would show up as "Message is OMEMO
encrypted", even if their client was supposedly supporting some kind of
OMEMO. Developers of clients were put on a public blame list for not
implementing OMEMO fast enough. The reference for how things needed to
work was not a specification, but a single implementation.
AFAIR there was also a specification on Conversations website from early days.
I don't think that is was a mistake, I've already exposed my opinion, but
there was pressure from the IM alternatives and the users too, and at the time
only OTR was available, and only implemented by few (with problems as we
know).
If we had waited, for the "right" version which was done at 2021-10-07
(version 0.8.1), I'm pretty sure that the state of XMPP ecosystem would be
worst that it is nowadays. First specification is from 2015-10-25, that 6
years!
OMEMO has been quoted many times in literature. I believe that XMPP is still
considered as a viable protocol for IM and more by many partly thanks to
OMEMO.
The "Message is OMEMO encrypted" thing was notably due to one client using it
by default, which is the only case I remember of a breaking protocol thing,
and has nothing to do with specifications. This thing put a lot of pressure on
developers. I don't blame the dev which did that, it was done for a reason and
it's totally understandable, and maybe a good move.
Again, we have disco and namespace to handle various versions, if a client
implement a new version, it's a choice to keep previous implementation for
compatibility, and I believe most are doing that in critical cases
In the case of OMEMO, I only know one client that implement OMEMO:2 and not
the legacy one, and this client is young and took some radical decision; I'm
not sure if it's still the case, but at one point they didn't wanted to
implement XEP-0045, despite its "stable" status, and wanted to focus on MIX,
so the specification status didn't change a thing here.
I really think that we should separate "specification" work from
"implementation" work (put aside the reference implementation thing):
you can have a buggy implementation of a final specification, or incomplete, and
an "experimental" specification can have a rock solid implementation (which can
be updated if new version arise).
Also, it's not necessarily a good thing to rush to put something to stable:
feedback also come from end-user, and they may suggest an interesting change
which could be done with, say, a new attribute or element with a namespace
bump, which is easily done with an experimental XEP, but hard to impossible in
stable or final.
And there are many use cases where important things may not be anticipated at
all by developers because they don't know specific fields. I'm thinking about
accessibility for instance. Feedback from community from implementing clients
is previous there.
Trying to freeze as many specification as possible as soon as possible can be
counterproductive.
And OMEMO still is a mess, next to nobody is implementing the latest
revision, even though we know there are ways to upgrade that do not
break anything. And those few that only implement the latest revision
are totally screwed because their client is incompatible with what all
others do, so they can't even do a lot of testing and are considered
incompatible to OMEMO, even if technically it's everyone else that's
incompatible.
It's a choice to implement only latest version when everybody know that only
few clients are implementing it at the time. First iteration took years too,
because resources are scarce, and we all have our priorities. Without
iterations, we would not have had OMEMO at all before end of 2021, and I'm
pretty confident that several clients would then have disappeared.
Best,
Goffi