GitHub - balzack/databag: A tiny selfhosted federated messenger for the decentralized web.
github.com
A tiny selfhosted federated messenger for the decentralized web. - GitHub - balzack/databag: A tiny selfhosted federated messenger for the decentralized web.

Just a hint for people searching a tiny selfhosted messenger with encryption and apps for iOS and android.

  • sbv@sh.itjust.worksEnglish
    281·
    1 year ago

    End-to-End encryption (the hosting admin cannot view sealed topics, default unsealed)

    oh no

    • u_tamtam@programming.devEnglish
      73·
      1 year ago

      It says it’s federated. When you are your own provider, e2ee doesn’t matter nearly as much (you probably have a bunch of personal files, backups, services running on the same box anyway).

      Edit: I would gladly take constructive comments with the downvotes. For a moment I thought we were on “selfhosted”, where “you are your own provider” should resonate in with most

      • IAm_A_Complete_Idiot@sh.itjust.worksEnglish
        7·
        1 year ago

        The point of federation means your content doesn’t only stay on your server. The person you’re talking too can be on a different one and their admin can see them too. Also, I wouldn’t want to be able to access content from any user - it’s a “no trust needed” thing.

        • abeam@lemmy.worldEnglish
          2·
          1 year ago

          with databag, the content only resides on the hosting node, or on the device of a topic participant. in the case of matrix.org, federation means your content will live on other servers, but that’s not the case for databag.

          your point about the admin being able to see the content is valid. if the databag node is hosted by someone else, then they to would have access to the content if e2ee is not used.

        • u_tamtam@programming.devEnglish
          11·
          1 year ago

          The person you’re talking too can be on a different one and their admin can see them too.

          That very much depends on the protocol and type of federation, but a good point indeed

          Also, I wouldn’t want to be able to access content from any user - it’s a “no trust needed” thing.

          Sure, but e2ee also comes with lots of trade-offs and strings attached, that almost only ever make sense in case of extreme centralization (i.e. in a non-federation, where trust in the faceless provider is not an option). PFS means that setting up a new device is a PITA because you can’t access your full messages history on new devices without off-band synchronization, no server-side search means that clients are either limited in this area or have to carry large histories and inefficiently search themselves, MITM/server-mediated attacks are only mitigated with verification (on top of encryption), which is a UX disaster for users non-versed into crypto (and this complexity is imposed upon such users no matter what), etc, etc.

          Of course I’m not advocating against e2ee in the general case (and quite the opposite at that), but if you self host (topic of this community) for yourself and few family members, the downsides quickly outweigh the benefits and so I believe that e2ee should be left at the discretion of the users.

          • IAm_A_Complete_Idiot@sh.itjust.worksEnglish
            1·
            1 year ago

            Right, but when there’s third parties involved which you may not trust (which is almost always going to be the case when talking to users not on your server), e2e’s benefit starts becoming a lot more enticing. And while you have a point on out of band key sharing being annoying, it makes sense as a default - especially when content is going across servers. Content should be secure with an opt-out rather than insecure with an opt-in. The latter is just more error prone.

            Also: while it’s not friction free, apps like signal have shown that you can get verified e2e to be usable for the general population.

      • abeam@lemmy.worldEnglish
        1·
        1 year ago

        Your comment is spot on. e2ee is critical when there is server side replication or when you are using a public server, but neither is typically the case with Databag. e2ee imposes some limitations such as preventing server side processing of content which is useful for streaming. In my opinion e2ee is needed when you don’t know where the content resides, but when you do it’s overkill.

    • Samsy@lemmy.mlOPEnglish
      122·
      1 year ago

      Dumbest answer: I didn’t find a one click solution on casaOS.

        • Samsy@lemmy.mlOPEnglish
          2·
          1 year ago

          casaOS is a docker-compose simplified one click solution, like unraid or heimdall.

          Sure I tried to add xmpp to my apps, but finding the right one on xmpp is like the first experience with Linux … too many alternatives. I tried openfire because it sounds good with a compose file and proxy all to my caddy server. But I am stuck actually (the last 10 min), and I am unable to decide if ejabberd is better.

          • u_tamtam@programming.devEnglish
            2·
            1 year ago

            If your system is based on docker, couldn’t you just use the official docker image I linked? Besides, I wouldn’t recommend openfire, not because it’s not a capable server (it’s been to long since I tried it to have a meaningful opinion), but because it has less widespread usage than ejabberd/prosody, and by extent, probably less resources to help you configure it to your needs.

            I know it’s not the topic of this thread, but you are not making a convincing case (to me!) for a “docker-compose simplified one click solution” that pulls you away from the most popular and well maintained alternatives :)
            And you will also likely encounter things down the road pertaining to firewall configuration, domain name resolution and port multiplexing that containerization will turn into a configuration and troubleshooting nightmare, so… enjoy! (or not)