• 22 Posts
  • 7 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2024

help-circle




  • all understandable questions.

    group messaging

    this is very complex as im sure you can imagine. im using a p2p and the approach im using is that a “group” is basically a “room with ID”. when sending a message to a group, you send the message to the peers individually and they know to store the payload within the context of the “room with ID”. scaling something like that is limited by how many webrtc connections are possible by the hardware.

    i have some research relating to using MLS, but without some central store to keep the mls keys per-epoch, its very unstable as peers can go offline unexpectedly. another approach im investigating is to be able to ping connected peers to create a kind of mesh-graph that i could use to relay messages. this approach could also be better resiliant to peers going offline in the sense, that the graph could heal from peers going offline.

    im sure there are many details i havent considered, but i have buggy group messaging on the WIP version here: https://enkrypted.chat/ (go to chat-thread page > 3-dot menu on top-right > invite peer)

    offline delivery

    ive mulled over it enough to at least try using an approach to use git as a CRDT. it seems overkill for application data, but it would also allow use git as an offline message cache. https://programming.dev/post/51866250 . i havent implemented anything for this yet. im still mulling it over to make sure i dont overlook important details.

    alternative networks

    webrtc isnt the bit that make this app secure, its the local-first. no need to register anywhere when you have local-first crypto-random IDs. im open to considering other networks. tor has limitations around webrtc. this is perhaps where the git-based offline cache can come in useful in a tor network. i2p is also good as are many others like nostr. i’ll see what setup works best. i think it would be great to be able to support multiple.

    if you want to know more about “how it works”, you can take a look at the roadmap here: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown

    feel free to reach out for clarity instead of reading all that.







  • thanks for your feedback there. id like to share my thoughts and observations on your points.

    its a great personal shame for me to go in the close-source direction. those links to the open source repos, will remain open source because its demonstrates the unique concept around how it work. if people are interested in how it works and dont want to trust me (and you shouldnt!)… the open source repositories demo the functionality and also have a reasonable ampount of documentation around it. i had deluded myself that if i opensource something unique like this, i would be able to get open-source funding. i have no experience in the matter, i was just working on a sideproject to begin with (and its arguably still a sideproject). i put focus on transparency, communication and documentation. the project still gets called a scam/slop whether is open/close source.

    the app itself is pure client-side javascript so i dont see how i can offer a managed service.

    while i have a “decent” amount of documentation on the project, i dont expect most people to take a look. that was all intended for transparency when seeking open source funding. open source cybersecurity seems prohibitively expensive wheather you’re big-tech or not. my personal experience in seeking an audit: https://www.reddit.com/r/CyberSecurityAdvice/comments/1su8lir/security_audit_feedback_from_radically_open

    id like to put things into perspective here:

    As others have pointed out privacy without transparency (in the way of making the underlying code open source) isnt a guarantee of privacy its a weak promise at best

    https://github.com/positive-intentions/chat the core concept is demonstrated here. its a full functional p2p messaging with focus on client-side cryptography. i’ll be keeping it open source. the key different is that the open source version doesnt have as nice a user experience… if a nice user experience make all the difference, then i dont think people are looking at it objectively.

    removing openness in its entirety isn’t a solution privacy focused people will accept

    i agree; and just to be clear im not removing openness in its entirety. its open-source to demonstrate how it works. if you want a secure open-source p2p encrypted messaging… you have that… it simply isnt going to be the best experience i can offer. if you want to fork the repo and try iron-out the creases yourself? be my guest (its pretty complicated, so feel free to reachout for clarity). perhaps im being naive, but i dont think any amount of vibecoding is going to make the open-source version competative to the close-source version.

    marketing

    this is very difficult for me. no idea what im doing in marketing and my candid communication doesnt seem well recieved. especially in the cryptography and cybersecurity communities. no idea how to do marketing beyond posting on reddit and lemmy. i have been spending most of my time in improving the project and i can do that forever… but i shouldnt. its something i need to work on.

    i think i have offered a great deal of transparency, honesty and communication about how the app works. i expect it will be tough to sell “secure, but paid for messaging app”, but it seems the only logical option. this isnt my first rodeo; open-source is not a gamble that will pay off.