xoron

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.

my app is a sideproject. its aiming to be a regular messaging app (like whatsapp, signal, etc). im not breaking any rules by being a webdeveloper developing a webapp (i already asked this question on reddit). im actively trying to turn this into something that can support me.

i dont see myself moving my work away from github. i dont know what benefits it could bring. being anonymous is not something i see as valuable when trying to create a product.

“private and secure chat app”

I don't think it's a solved problem. There are countless nuances to it. So it's good to have various approaches.

https://positive-intentions.com/blog/docker-ios-android-desktop

this a yet another approach to a "private and secure chat app" because its a unique approach to the same problem which id like to investigate.

its a work in progress and hope to get to a point its comparable to Signal and OnionShare.

for now, the purpose is to present open-source code to demonstrate a concept. like mentioned in the post it isnt ready to replace any existing tools.

sorry for the delay in responding. personal matters required more focus and to reply to you i wanted to set aside some time to write well for clarity.

... Might as well get real-life practice at writing.

im not entirely bad at writing (technical or otherwise) to get to where i am now in the project, i usually write with my own words like now. the blog articles you see on the website are from old reddit posts. questions like your are understandably frequent and so it made sense to create the website and blog to address FAQ's. i think its important to note how im using AI here. while i can say to AI "here are some bullet points, now turn it into an article...", i have written the content and details myself and then have AI reword it for clarity. i think the resulting content is better for clarity.

What is the lifetime of each user’s public/private keypair? What is the lifetime of the symmetric key shared between two communicating users?

the implementation sits ontop of a webrtc connections which mandates its own encryption keys. my app adds an additional set of public/private keypair and symmetric keys. these are persisted to browser storage (indexedDB). the keys are cleared if the user performs a logout (its all client-side, so there is no actual "logout", it clears the local data).

key rotation is a work-in-progress and not testable in the app. while i can have a button that says "rotate keys", im planning to frame it as something like "block contact". this is because it makese to keep user ID's static, so that in future sessions, the app can automatically connect to "known peers". in the case you want to block someone, it makes sense to abandon that ID so they cannot ping you with it. when you connect to a "know peer" that doesnt know your new ID, it can use the previsously establish keys to verify each other and update the contact details accordingly.

its also possible to export the data to a file to then load from that profile. its currently static and unencrypted. there will be an option to have it all password encrypted. https://www.reddit.com/r/cryptography/comments/1lhjpxk/veracryptlike_functionality_from_a_browser/

I take substantial notice whenever a promise of “true privacy” is made

completely understandable. as mentioned in the post cybersecurity is full of caveats. here is a previsous attempt to outline some details: https://www.reddit.com/r/cryptography/comments/1evdby4/is_this_a_secure_messaging_app/

im also investigate various approaches to exchanging data offline with QR codes.

(written by me): https://www.reddit.com/r/positive_intentions/comments/1b5j424/file_sharing_by_qr_code/ (written by having AI transcribe my wording): https://positive-intentions.com/blog/qr-codes-as-a%20data-channel

id also like to investigate other things a browsers can do like exchange encryption data over NFC.

it isnt use-friendly yet, but i also have some basic functionality around p2p broker connections to avoid needing the peerjs-server (which acts as the broker.). some unclear details which could do with AI clarification can be seen here: https://github.com/positive-intentions/chat/issues/6

If a secure medium existed, then secure key exchange would already be solved

the existing key exchange should be already secure enough... but users would understandably want to be sure my code doesnt have a critical-bug and validating hashes provides that bit extra.

many others have also tried their hand at secure messaging, with more fails than successes.

i have seem some other myself, and i still believe my approach is unique. there are of course limitations in the webapp form-factor, but it also provides a lot of flexibility in just being able to run on a browser. while many try/succeed/fail, this is my attemp. i have been refining my approach with feedback and there is still much to do. at this point i dont consider it insecure, but the UI is pretty ugly and combined with various UI bugs, is deterring users. with the code being course source, i often try to present some concepts in a more digestable way with code examples as seen:

there is a lot to learn but by breaking things into small parts, i can better learn how it can all fit together.

“cryptography engineer” and not a cryptographer

i like that term. its new to me. i normally just call myself a webdeveloper to clarify my expertise. its more so the case than a cryptography engineer. i open sourcemy work for transparency, but also great for my own learning.

thanks for the good wishes. hopefully i get to a stage where its better presented as a product and not just a proof-of-concept.