The Signal Server repository hasn’t been updated since April 2020. There are a bunch of links about this here but I found this thread the most interesting.

To me, this is unforgivable behaviour. Signal always positioned themselves as “open source”, and the Server itself is under the best license for server software (AGPLv3 – which raises questions about the legality of this situation).

Signal’s whole approach to open source has constantly been underwhelming to say the least. Their budget-Apple attitude (secrecy, i.e. “we can never engage the community directly”, “we will never merge/accept PRs”, etc) has lead to its logical conclusion here, I guess. I have been somewhat of a “Signal apologist” thus far (I almost always defend them & I think a lot of criticism they get it very unfair) but yeah I’m over Signal now.

  • Dreeg Ocedam@lemmy.ml
    link
    fedilink
    arrow-up
    11
    arrow-down
    3
    ·
    edit-2
    4 years ago

    Because centralized messengers

    • Have better UX than federated ones
    • Are more reliable than P2P ones (less battery usage, messages can be sent without the need for both clients to be online at the same time)
    • Have been audited by third parties
    • Leak less metadata

    Edit: Here are a few examples of what metadata Signal protects that Matrix doesn’t:

    • kevincox@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      4 years ago

      Have better UX than federated ones

      This is definitely currently the case, and could be factual but I think the fundamental difference is minuscule. People are currently using QR codes or phone numbers to find each other (both supported my Matrix) and regularly use emails. You can probably argue that the @domain.example suffix to IDs is a hurdle to UX but I think it is incredibly minor.

      So I hold out hope that UX of decentralized messengers will approach or surpass the centralized ones.

      Are more reliable than P2P ones - less battery usage

      Maybe for “pure-P2P” but for services that still use servers this isn’t the case. (Like Matrix, and IIUC there are XMPP extensions for using external push services that put battery usage on par with any of the centralized ones)

      Are more reliable than P2P ones - messages can be sent without the need for both clients to be online at the same time)

      This is also only a concern for “pure-P2P” services. Furthermore many pure-P2P services have solutions to this via distributed buffers and logs. In fact for optimal privacy you don’t want to directly connect to the recipient anyways.

      Have been audited by third parties

      Some of them. However some open-source ones have also be audited and have research done on them. I would love to see enough funding for some of the open-source messengers to get official audits.

      Leak less metadata

      citation needed. To be fair signal is very good in this regard. However there are better decentralized options and worse centralized options. I don’t think this claim can be applied to centralized or decentralized messengers in general.

      • Dreeg Ocedam@lemmy.ml
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        4 years ago

        I do agree with most of what you said here but here are a few things:

        What I call centralized/federated are things like XMPP/Matrix, which require servers to function but are interoperable. What I call P2P are apps that don’t need any servers (beside a few bootstrap nodes) to function like Tox. As you said, when it comes to battery, Matrix/XMPP work fine with push notifications, and users don’t need their phones to be on all the time.

        A lot of UX could be improved in Element, that is completely separate from the fact that it is federated. I have never used XMPP though. The #1 problem is that apps for federated services will always have to present you a screen “what instance are you using ?”, and ask you to do your own research to find a decent one, whereas centralised services can just create your account on the fly.

        Some of them. However some open-source ones have also be audited and have research done on them. I would love to see enough funding for some of the open-source messengers to get official audits.

        Can you share some sources for that? Last time I checked I failed to find any info on Matrix passing (or not) third party audits. If you have something about another decentralised protocol with audited implementations I’d be happy to have it.

        citation needed

        That’s fair, I was just lazy in my first post. I don’t think it’s impossible to develop a federated protocol that leaks very little metadata like Signal, but it would be a pain to get different clients/server version to handle it correctly. One aspect is also that with whatever metadata still leaks, you will have to trust two servers (receiving and sending) instead of just one.

        Here are a few examples of what metadata Signal protects that Matrix doesn’t:

        • kevincox@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          4 years ago

          decentralised protocol with audited implementations

          There haven’t been many, funding for it would be great. But at least some XMPP OTR implementations have been audited: https://www.eff.org/pages/secure-messaging-scorecard. But this isn’t really different between centralized and decentralized, it is just individual. (And usually connected to how much money they have)

          a few examples of what metadata Signal protects that Matrix doesn’t

          For sure. As I said Signal is a very good protocol. But not because it is centralized, just because it was designed to be very privacy friendly.

          Also for what it is worth a lot of that group metadata can be undone because they have some idea who is sending and receiving the messages along with timing. Of course it is still better that they have the sealed sender and encrypted group data but it definitely isn’t perfect.

          And yes, Matrix does intentionally leave more of that in the open. Everything is tradeoffs.

      • Dreeg Ocedam@lemmy.ml
        link
        fedilink
        arrow-up
        13
        arrow-down
        3
        ·
        4 years ago

        For 99% of the people that use messaging services, convenience is the number 1 priority.

        • Echedenyan@lemmy.ml
          link
          fedilink
          arrow-up
          3
          ·
          4 years ago

          Then you must teach them ethics. If you see that, it is in your hand try it, so it is a moral obligation.

          • someone@lemmy.ml
            link
            fedilink
            arrow-up
            3
            arrow-down
            5
            ·
            edit-2
            4 years ago

            I hate that they downvoted you for pointing out facts. Convenience is slavery, more you prefer it the lazier you become.

    • federico3@lemmy.ml
      link
      fedilink
      arrow-up
      2
      arrow-down
      2
      ·
      4 years ago

      Leak less metadata

      citation needed. On the contrary, any network observer can perform a timing attack by correlating messages being exchanged to/from clients and servers. Having centralized servers only makes it easier.

      Briar, on the other hand, is P2P and uses Tor as transport network making such attack way more difficult.

      • Dreeg Ocedam@lemmy.ml
        link
        fedilink
        arrow-up
        2
        arrow-down
        2
        ·
        4 years ago

        I edited the comment with citation.

        Briar suffers from the problems I mentioned about P2P requiring more battery and not being able to use push notifications. It also has the works UX of the lot, since you can’t even begin communicating with someone without being in having a way to get them a cryptographic identifier/QR code. No way anyone but the most tech savvy will ever use it. Also, it’s still not available on IOs.

        • federico3@lemmy.ml
          link
          fedilink
          arrow-up
          3
          arrow-down
          3
          ·
          4 years ago

          To protect users metadata including the type of application, protocol, and timing push notifications cannot be used. Equally, direct connections to centralized servers are not suitable. That’s a reason for Briar to use Tor.

          The thread is about centralized vs decentralized. Availability on OSes, polished UIs and so on are besides the point.

          • Dreeg Ocedam@lemmy.ml
            link
            fedilink
            arrow-up
            1
            arrow-down
            2
            ·
            4 years ago

            The thread is about centralized vs decentralized. Availability on OSes, polished UIs and so on are besides the point.

            Yes, your are obviously right. Who cares about the end user? /s