• 81 Posts
  • 104 Comments
Joined 2 年前
Cake day: 2024年6月14日
  • xoronOPtoPrivacy•P2P WhatsApp Clone
    1·
    1 个月前

    do you perhaps have something running on localhost at those ports? i was trying something out, but i will disable it so it doesnt have this issue when users try to selfhost themselves.

    it isnt well explained or demonstrated, but i was trying to do something as described in the link below, where i could connect a selfhosted federated module and have it work as a drop-in replacement.

    https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

    the purpose was to see if there is any benefit to allowing users to host their own federated modules. i think there isnt a distinct advantage so it looks like i will remove that feature entirely.

  • xoronOPtoPrivacy•P2P WhatsApp Clone
    1·
    1 个月前

    im still think of a better name for the project before i promote it properly as stable and secure. “positive-intentions” is understandably not well recieved.

    i call it a “whatsapp clone” to better describe what it can be used for. this is in contrast to calling it a “p2p instant messaging app”… that just sounds too verbose.

  • xoronOPtoPrivacy•P2P WhatsApp Clone
    2·
    1 个月前

    thanks for letting me know, i’ll take a look.

    edit: perhaps this could be your issue… consider that your user-ID is the same one used when you reload the page or open it on another tab. if you open a new browser tab, it will try to connect to the peerjs server with an ID thats already in use… instead try with one incognito browser window (or a separate device).

  • xoronOPtocybersecurity@infosec.pub•*Permanently Deleted*
    3·
    2 个月前

    thanks. this implementation is intended for a p2p messaging app. it works as a webapp and only stores data locally.

    the signal architecture requires prekeys to be store on a server, in a p2p approach you dont need presigned keys and the double rachet starts immidiately (the tradoff is there is no offline messaging).

    im investigating making it so that the service worker caches the initial static files… so page-refreshes dont update the loaded statics. there would be an explicit button to update the statics for the service worker. i have a basic concept working but it isnt finished enough for me to roll-out.

    when open-source, there are additional capabilities that can be unlocked like being able to run the app from index.html without a static server. this would be stronger against anyone making changes on the network-level.

    i understand why signal doesnt do a webapp like many other sevices like whatsapp… the p2p messaging architecture is fundamentally different.

  • xoronOPtoOpensource•Signal Protocol in Javascript
    1·
    2 个月前

    Not ideal, but a professional audit is not an option.

    To be clear, my prompt was not “create me a security audit”. it took time and effort with several stages of refinement. I suspect more effort than writing that article.

    It’s open source for you to critique in a more involved way. The AI audit is intended to get to there faster. If you see any details that are wrong, I’ll be happy to take a look and update appropriately.

  • xoronOPtoJavaScript•Signal Protocol in Javascript
    2·
    2 个月前

    that sounds like a good idea to explore. i didnt consider nostr, but i think i can fit it in. my implementation is fairly unique because im trying out an application-level cascading cipher. the following article isnt finished, but might show some insights.

    https://positive-intentions.com/blog/cascading-cipher-encryption

    like with the signal-protocol, it should be possible to adapt the nostr-protocol to be able to daisy chain to the cascade. im already using the MLS protocol in the cascade to help manage group messages. after taking a quick look at the nostr-protocol. i think its a good idea how it handles relaying messages. it could be useful for group messaging.

  • xoronOPto/c/cybersecurity - Cybersecurity News & Discussion@lemmy.ml•Multi-Protocol Cascading Round-Robin Cipher
    1·
    2 个月前

    thanks for the vibe-check.

    its a bit over the top for encryption. i see that webrtc alone should already be providing sufficient encryption. its audited and it works really well… i hope the redundency could be reassuring to users. if one layer fails it all fails… this is the expected behaviour. having too much encryption is better than not having enough.

    it is a bit security thatre… in a messaging app, security is paramount so i want to have an answer when users (inevitably) compare my approach to signal.

    in cybersec, there are countless nuances. so id like to try this approach with a cascading cipher. a protocol for all protocols.

    i’ll keep an eye out for any sideeffects.

  • xoronOPtoPrivacy@lemmy.ml•P2P WhatsApp Clone
    21·
    3 个月前

    Just to be clear, my app is not better than jami (or any other app)… because its unreviewed close-source code.

    The key distinction in my approach is that it’s a webapp-first approach. You can avoid registration and installation, which is a feature other apps don’t provide.

  • xoronOPtoPrivacy@lemmy.ml•P2P WhatsApp Clone
    4·
    3 个月前

    There are ways around using a central server to establish a p2p connection. It isn’t well explained or demonstrated, but the concept seems to work here: https://github.com/positive-intentions/chat/issues/6 … I’d like to explore this more with exchanging the required data over QR codes or NFC.

    Simplex is a great approach for p2p communication. I can easily recommend it over what I have done so far. At the very least, it’s gone through things like a professional security audits and seem to keep a high standard in their practices.

  • xoronOPtoPrivacy•No-setup P2P Calls in an Browser
    1·
    3 个月前

    youre right that embarrassment is no reason to not open source it. i simply am investigating a close source direction to create a competative product.

    if you interested in how this mechanics work, a very complicated version of it can be seen in: https://github.com/positive-intentions/chat (maybe you can get some AI on it.) … the p2p call demo is a module im creating to be refinement of the old p2p functionality.

    im aware that security and privacy doesnt easily fit with close-source, so id like to eventually open source it when i can figure out funding. open source from the onset didnt work out how i naively thought it would in the old version.

  • xoronOPtoPrivacy•No-setup P2P Calls in an Browser
    2·
    3 个月前

    these are good points. with peerjs this is easily configurable.

    can i pick your brain about a config like the following:

    const newPeer = new Peer(`blah`, {
        config: {
          iceServers: [
            { url: "stun:stun.l.google.com:19302" },
            { url: "stun:stun1.l.google.com:19302" },
            { url: "stun:stun2.l.google.com:19302" },
            { url: "stun:stun3.l.google.com:19302" },
            { url: "stun:stun4.l.google.com:19302" },
          ],
        },
      });

    perhaps you would prefer to manually set your own config there with input fields?

    id appriciate any insights into what you think users with that particular issue would like or find useful.