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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
