threat model

It’s client side JavaScript. I think a webrtc connections is reasonably audited and encrypted. When using webrtc, ip addresses have to be shared. If the IP address could be hidden, it would improve “privacy” on my app.

It would be ideal if I could find a way to interface with the tor network with Client-Side JavaScript. I’ve come across something interesting here which id like to investigate further. https://github.com/Ayms/node-Tor

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.

https://positive-intentions.com/blog/async-state-management/ https://positive-intentions.com/blog/bottom-up-storage/

the state management with the useStore hook seem tricky to explain and can be a whole separate dicussion. i try to explain a bit in those posts. im still working on it more and while it isnt document anywhere, but im also investigating having it store data encrypted-at-rest.

thanks for the info. i’ll take a look later, it sounds like an interesting idea.

“connect to expressvpn and run the test”… is that actually what you were doing?

i tried with a different VPN provider but yeah. understandable for people to not go to an unknown websites like the demo i posted, so a link to the code on github is provided.

IMO you simply can’t do anything reasonably useful here

i agree… im stretching the definition of what is “reasonable”. id settle some something clunky likes a popup for the user to remind them to be on VPN. its important to understand im putting efforts in determining what the safest and securest way is to use my app. i think it has the potential to be a private and secure chat app. the app works with webrtc, the key attack-surface is individuals and their peers not applying good security practices.

in traditional centralized chat system the central server will typically take responsibility for proxying request and consequently, the personal IP addresses are not needed to be shared. so having something like a toggle for “enforce VPN” might do nothing more than remind the user to turn on their VPN. but sometimes a reminder is what someone needs to use good security practices.

Thanks for the clear info! I’ll investigate this further within the demo.

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. the connection details have to explicitly be shared.

the app is pretty experimental in how it works so there isnt any useful documentation on it apart from what is mentioned in the post. if you have questions, feel free to ask and i can try to explain the best i can.