3 Jun
2024
3 Jun
'24
5:29 p.m.
On Mon, 03 Jun 2024 16:06:37 +0200
Goffi <goffi(a)goffi.org> wrote:
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.
Agreed. We don't need yet more XEP numbers to shift through. We already
have way too many of them.
Instead we should start using the namespaces more. And also we shouldnt
be afraid to update Stable XEPs if there are substaincial changes. I
mean we have feature discovery and namespaces for that reason :)
MSavoritias
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.