• ProdigalFrog@slrpnk.net
    link
    fedilink
    English
    arrow-up
    0
    ·
    13 days ago

    I want to point out that the author of that linked blog, Soatok, actually removed a response in the comments from an OMEMO developer which clarified some things, which personally I think was rather odd/bad faith of them to do. When asked about it, this was their response:

    “I’ll make an edit later about the protocol version thing, but I’m not interested in having questions answered. My entire horse in this race is for evangelists to f** off and leave me alone. That’s it. That’s all I want.”

    According to the OMEMO developer in his response (you can it read here), there’s nothing really wrong with OMEMO 0.3.0, as the dev considers it a stable standard that clients can safely implement, with newer versions basically being public beta releases toward a stable ‘OMEMO 2’ standard that can eventually replace 0.3.0.

    Also @smiletolerantly@awful.systems.

    • SwooshBakery624 [they/them]@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      12 days ago

      I didn’t know about this response, thank you for pointing it out. However, this response fails to address the main criticism of the XMPP+ONEMO:

      To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).

      Both of these conditions fail the requirements I outlined under the End-to-End Encryption header in that other blog post.

      And that’s all that I should have needed to say on the matter.