• 7 Posts
  • 22 Comments
Joined 5 months ago
cake
Cake day: June 13th, 2024

help-circle
  • My app is different because the auth is handled between peers. So it could only every be people you shared your ID with. Security is important for me on this project. Its more important than the app being popular. https://www.reddit.com/r/CyberSecurityAdvice/comments/1ev5kqn/is_this_a_secure_messaging_app/

    People should not connect to strangers on this app because of the potential risks of IP exposure… But between people you trust or between your own devices, it should work as expected for testing.

    As for allowing links with expiration, you basically have that already with what looks like the login/logout functionality. There is no actual registration, it’s just a UI for creating and deleting crypto random ID profiles.

    Lemmy and the fediverse is a good idea. The federation makes it so I can see Lemmy posts on mastodon. Etc… id like to draw a parallel in my app with the chat-view and the inteagram-view


  • I don’t think this kind of app could be an alternative to instagram because of it only being P2P with only people you know.

    The app is using webRTC which exposes IP addresses, so you wouldn’t want something like a global feed on this.

    Immich sounds interesting. I’d like to make time to check it out.









  • thanks for that. its all sage advice.

    im happy to proceed in the public with the apps development. i am generally going for a release-often approach with the code and id like to make decisions public early. as a regular js developer, from a security standpoint id like to aim for as secure as possible.

    guarantees?.. not sure what this would look like when presenting this publicly. my app is a webapp and the key pillars for its security seem to be:

    • that the browser cryptography functions are not compromised.
    • that the peer/device/os is not compromised

    there are many p2p chat apps out there. i think mine is most similar to: https://chitchatter.im … but i think its important to note, as a sideproject, i am also trying to be creative with what is possible with browser technology to set it apart from what else is out there. to create something bare-bones would not be attractive to users. one of the first things i did on the project is the security implementation and then built the other details on top.

    id like to make it clear that the app is using webrtc which requires IP addresses to be exchanged which could result in IP address being exposed when using the public peerjs-server (hosting your own is an option). this app is explicitly NOT for anonymous communication. it explicitly shares IP addresses and data sent/recieved from peers cannot be moderated. the app is using cryptographically random ID’s for profiles to make sure they are unguessable. you should not post your connection data public. it would undermine its unguessable-ness. this is why i have wording throughout my docs to say you should only connect to peers you trust.

    there is also the elephant in the room… the stability of my code. id like to confirm at this early stage, it is not only unstable, but there will be breaking changes. i think its important i mention these details to help users manage expectations of the app. the security implication is that the app is not secure because of this alone.

    as for the project vision of how and what it does, i have generally expressed it in my reddit, but i find that the vision is not so clear to grasp, its mainly that all the parts will fit together. that is hard for me to explain and harder for anyone to understand without it working how i envision. its hard to explain: “decentralised p2p chat app on a blockchain with shared AR and filesystem on the browser”. from a security standpoint, as secure as possible with javascript.




  • if “trust” in the static files from a url is a concern, (which is very reasonable), you can easily host your own instance.

    i think it fits squarely as a “P2P app”. over a hotspot, you can practically send messages offline. im not sure what other qualifiers are needed.

    i dont think its ready to be compared to other tools yet. but i would be aiming to make it comparable to something like signal… but it’ll take a while to get there.





  • Sorry. It’s quite buggy.

    • Its best to start off by clearing all site data from the browser settings.
    • Do not have multiple tabs of the app on the same device.
    • It doesnt hurt to refresh to page.

    What you’re describing might be related to there being 2 tabs of the app running. This results in both reacting to the new-connection-event, but ultimately resulting in a data conflict.

    Plugins shouldn’t be an issue. For stronger security, i have CSP headers to try to prevent browser plugins reading data.

    If nothing works then the egg is squarely on my face and my buggy app is too buggy.