the org can be found here: https://github.com/positive-intentions
the prerelease demo linked in the post is not open source.
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).
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.
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.
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.
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