Bored on holidays or miss Omegle? Come chat with us on MeroChat!

It’s a web based random chat where you’re presented with a flow of user profiles, whom you can choose to chat with. And of course someone else might find you the same way and send you a message out of the blue (provided your privacy settings allow it).

And here’s the code. (Written in PureScript!) A lot remains to be done but it’s a joyful thing already.

  • Undertaker@feddit.org
    link
    fedilink
    arrow-up
    21
    arrow-down
    2
    ·
    1 day ago

    Messages are not end to end encrypted and can thus be read from service provider.

    Additionally Google is integrated into website.

    • TiukuOP
      link
      fedilink
      arrow-up
      12
      arrow-down
      1
      ·
      1 day ago

      That’s true. It’s due to lack of implementation.

      Getting e2ee right is tricky business. Any help or insight would be appreciated.

      • Semperverus@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        edit-2
        17 hours ago

        Look into libaxolotl (AKA “OMEMO”), it is the same system Signal uses and is highly standardized.

      • waffle@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        ·
        20 hours ago

        I know Matrix has E2EE with some public documentation on its implementation. Maybe it could help you? Idk how familiar you’re with E2EE or what kind of implementation you’d want, anything will have drawbacks :/

        • TiukuOP
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          19 hours ago

          Thanks for the tip!

          I have somewhat of a grasp on how Signal does it, but that’s very client oriented. How to go about it a web app is a mystery to me.

          • waffle@sh.itjust.works
            link
            fedilink
            arrow-up
            4
            ·
            16 hours ago

            Yeah, I’m not used to E2EE in the browser either and StackExchange seems to agree that there’s no nice solution :/

            The sanest option in terms of user practicality to me appears to be storing the private key on the server, maybe encrypted with the user’s password, and sending it to the user on successful login where it would be decrypted client side. It seems like it’s more or less what Mega is doing since they have a similar issue

            If the server having temporary access to the user’s password is an issue maybe the password could be partially pre-hashed before being sent?

            It’s be interesting to talk about it with someone with more experience, especially since implementing all of that will be a pain so it can’t be redone every Thursday