It seems really cool but I’m a bit wary of it due to the crypto stuff.

  • mox@lemmy.sdf.org
    link
    fedilink
    arrow-up
    24
    arrow-down
    1
    ·
    22 days ago

    From two days ago:

    https://lemmy.ml/comment/13108576

    A few SimpleX shortcomings beyond what you noted, in no particular order:

    • No multi-device support.
    • Adding contacts requires sharing somewhat large links (as either text or QR code) which can be inconvenient.
    • Messages are lost if not retrieved soon after they’re sent. (I think it’s 21 days by default. I’ve had vacations longer than that.)
    • No group calls.
    • Group messaging is full-mesh, meaning that as a group grows, the network traffic will balloon faster than it would with any other topology. This is generally bad for high-traffic groups, but it might be okay if they stay small or everyone always has great unmetered connectivity.
    • The claim to not have user IDs is misleading at best, and outright false in group chats.
    • The desktop app uses Java, which will be unappealing to more than a few people. (To be fair, several other messengers use Electron, which is also unappealing to more than a few.)

    It does have some neat design ideas. I don’t consider it ready for general use, but I look forward to seeing how it develops.

    • jet@hackertalks.com
      link
      fedilink
      English
      arrow-up
      6
      ·
      22 days ago
      • The claim to not have user IDs is misleading at best, and outright false in group chats.

      I’m in a group chat but I’m unable to send a direct message to a group member, that’s annoying, but would substantiate the claim that they don’t have general user IDs.

      • mox@lemmy.sdf.org
        link
        fedilink
        arrow-up
        6
        ·
        edit-2
        22 days ago

        Their queue IDs are user IDs. Each one points to a specific user. You can call it a queue ID, or an account ID, or a user ID, or an elephant, but that doesn’t change what it is.

        They crate a different ID to share with each contact in 1:1 chats, but that doesn’t make them anything less than user IDs. You can do the same thing on any other chat service by creating a different account to reveal to each contact. (This is obviously easier to manage on clients that support multiple accounts, but again, that doesn’t change what the IDs do.)

        And in group chats, they don’t even do that; they reveal the same ID to all group members.

        • ReversalHatchery@beehaw.org
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          21 days ago

          Do I understand it correctly that the queue ID is specific to the group chat? How is that a user ID, then? The point is that the user doesn’t have an ID, and so you can’t find them in any other group chats unless they have introduced themselves. It basically only identifies the destination, and you really can’t avoid that, can you? Well, unless all messages are basically broadcasts, and everyone receives them, generating unimaginably larger traffic

      • mox@lemmy.sdf.org
        link
        fedilink
        arrow-up
        3
        ·
        21 days ago

        That does seem like a decent workaround for the multi-device problem, if you only communicate in small groups and each member only has a couple of devices. Directly addressing each other could get unwieldy fast as a group (or the number of devices) grows, but I’m guessing you’re not in that situation. Nice work.

        • Dymonika@beehaw.org
          link
          fedilink
          arrow-up
          1
          ·
          21 days ago

          Yeah, that’s super-creative; I would never have thought of that.

          … because we shouldn’t need to in the first place!

    • refalo@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      21 days ago

      What would you consider ready for general use? I feel like this is being unnecessarily harsh to the majority of potential users.

      • mox@lemmy.sdf.org
        link
        fedilink
        arrow-up
        2
        arrow-down
        2
        ·
        edit-2
        13 days ago

        I feel like this is being unnecessarily harsh to the majority of potential users.

        I don’t know why you would think it harsh to point out shortcomings in software. It’s not a matter of opinion. These limitations exist, plain and simple, and some of them are not easily discovered from a quick visit to the SimpleX home page.

        By listing them here, it saves everyone else the time and trouble of having to investigate on their own. (Unless they assume I’m lying or don’t know what I’m talking about, but I can’t help them with that.) It might also save some people from starting to build their network of contacts on a particular messenger, only to later discover a deal-breaking problem and have to start all over, asking all their contacts to switch again.

        What would you consider ready for general use?

        I can’t make a single suggestion to fit everyone else’s needs, because there is no messenger that addresses everyone’s needs. All of them have different tradeoffs, so we have to prioritize the things we want.

        For myself and my contacts, Matirx does all the things we must have: Free, anonymous, good crypto, audited, multi-platform, multi-device, not centralized, self-hostable, reasonably easy to use, and delivers messages (without time limits) even when we’re offline. It even supports some nice extras, like screen sharing and voice calls.

        Matrix detractors generally complain about certain metadata not being encrypted, which is technically true: A few things like the usernames that have joined a room, and avatars (if you set one), have not yet been moved to the encrypted channel and can therefore be seen by your homeserver admin. Frankly, it’s not a high enough priority for us to be driven away from a tool that meets our needs. Protecting the content is our priority. We could self-host a server to protect the metadata, but we don’t bother, because it’s not part of our threat model.

        Would I recommend Matrix for high-risk work, where state authorities finding out who you’re talking to could threaten your safety? No, at least not in its current state. Communications like that demand very specific protections, and those protections don’t exist in any messenger that has the conveniences and features that I expect from a modern chat service. That’s (one of the reasons) why whistleblowers and targeted journalists turn to special tools. Having a separate tool/platform for high-risk work is fine; giving up features to meet those needs is a perfectly appropriate tradeoff.

        But again, that metadata issue is not a risk factor for us. We’re certainly not going to reject a uniquely useful chat platform because of it.

        Back to your question:

        I don’t post on social media telling everyone to use the same tool I do, because I don’t know everyone’s needs, and I do know that a few people have very specific needs that don’t match mine.

        However, it turns out that the vast majority of the people I’ve talked to about this stuff have needs similar to mine, so Matrix (the protocol) often ends up at the top of the list of things to consider.

        My main reservation in suggesting Matrix for general use right now is that the official reference clients (they’re called Element on every platform) still have some rough edges. For example, occasionally sending messages that cannot be immediately decrypted by the recipient unless they jump through some troubleshooting hoops, and a search feature that isn’t implemented in all clients yet. The underlying bugs have been steadily disappearing, so these issues are becoming less and less common, but since they’re not entirely solved yet, I use an alternative client and avoid suggesting Matrix to mom and dad for now.

        I already use it daily with friends (who I can help if a problem comes up) and people who are comfortable with troubleshooting on their own. It’s visibly moving in the right direction.