Thanks for the tip.

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

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

the org can be found here: https://github.com/positive-intentions

the prerelease demo linked in the post is not open source.

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.

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.

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).

Hi. Yeah I’m the creator.

I think I need to do a bit a of rebranding so that it’s easier to find. “positive-intentions” isn’t the easiest to type/remember.

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.

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.

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.

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.

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.

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.

It’s a webapp hosted on AWS S3. That can be shut down along with the domain. I’d like to improve the functionality I have for the cacheing, so that it doesn’t need to fetch the statics from online if it already previously fetched them.

The open source version has a mirror hosted on GitHub pages. You can fork it and run it yourself there for free: https://positive-intentions.com/blog/docker-ios-android-desktop#github-pages

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.

thanks.

thats unfortunate it doesnt work. maybe a direct link to the storybook can help: https://p2p.positive-intentions.com/?path=%2Fstory%2Fdemo-p2p-call--video-call

i didnt clarify… the glitr app is a ui with hard-coded dara. the functionality in this p2p calls demo is what would be integrated into that ui. its far from finished and doesnt really “work”

my code and documentation website needs much more work before i can point to it for clarity. but i open sourced the poc version here: https://github.com/positive-intentions/chat … you may see that the UI isnt very unintuitive to use and why im going in a different direction with the UI.

pardon for copying from another reply…

i agree. they are all better and more secure when selfhosted.

my project so far is an early preview into the p2p framework in my project. with feedback i can improve the functionality as i integrate it into my messaging app.

https://glitr.positive-intentions.com/

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.

i agree. better and more secure.

my project so far is an early preview into the p2p framework in my project. with feedback i can improve the functionality as i integrate it into my messaging app.

its a work in progress and far from ready to be open sourced.

id like to work towards making it open source eventually.

its largely peerjs and peerjs-sever which themselves are reasonably well documented.