xoron, xoron@programming.dev

What’s your motivation? Why are you doing this? Do you hope to make money out of it, or do you have more altruistic intentions?

i mentioned it in the post. ‘Im aiming to create the “theoretically” most secure messaging app’… that is the goal. im not aiming for “more secure that whatsapp/signal”… but something fundamentally different in how it works. while things like webrtc and interest decentralized technology has been around for a long time, there wasnt something as general-purpose like what im aiming for.

it started as a sideproject and i kept building on it. i hope to make money out of it and have something that can support me (because ya know… bills to pay). i started off open source; naively thinking i would get open-source funding support if i demonstrated the concept to develop it further. i did several exhausting rounds of grant applications. it was an horrible experience on something outside my competence and towards the end i was dreading applying for grants knowing that they were going to reject my project. i also set up github sponsors, but nobody has donated… completely understandable for something that looks like a weekend project, but its clear that it isnt going to pay any bills.

Anyone you convince to use this will have their data and privacy at risk

you are fear-mongering again… its important for anyone reading this, the app works differently with user data. its all client-side. you dont need to add any personal info for it to work. ive linked how the data can be encrypted at rest. there are irresponsible ways to use any app, your data is not inherently at risk because of this implementation. if you are going to make such claims, you should make it against the code examples i’ve provided… or at least an example of what could go wrong.

i work hard on this project, so of course i promote the project on reddit and the fediverse, but you failed to mention that i also advise caution in all of my posts (including this). i hope its clear that such wording like “work-in-progress” works against marketing/promoting… i include it because its responsible to do on a project like this at its current stage.

acting as a middle man to ChatGPT

its 2026 and AI is very prominent. people are indeed vibcoding some serious stuff. there is clearly a new wave of “developers” that dont have a concept of unit-testing, let alone the appriciation for them. ive been a developer for 10+ years and know how to do this “old-school”, but using AI is clearly a huge enhacement so it understandably looks very vibecoded. its important to study, test and review what is produced. when people get hung up on “OmG YoU’rE UsInG AI”, that seems to be an indicator for me that im not really having a real discussion. especially when i have code examples and unit tests… that doesnt mean my approach is without issues, but the code is right there. your concerns are well placed so i have some questions for you.

• why arent you using an AI to review what ive created?
• what academic/professional hoops do i need to jump through for credability?
• perhaps you can identify something i overlooked?

while you have no obligation to do anything for me, my point is that the code has been openly discussed for a while and other people have reached out about issues and i addressed them to get the project to where it is now. i have a lot more to do on the project before i can remove wording like “work-in-progress” in my communication about the project. the project is working as expected and i expect it will continue to improve.

it seems clear that i dont have enough on the project to convince/inspire confidence in you, which is understandable and respectable. i dont want you to “trust me bro”… its why i keep the open-source versions separate, its useful to be able to point to open source examples when discussing details online as i refine the implementation. you should use what you are comfortable with and you clearly know your way around cybersecurity, so i expect your judgement in how you securely communicate is better than most.

So is it about convenience, or security?

it isnt about convenience or security. while security is clearly important, the “convienience” is important for helping users to get started. from experience, pointing to a github repo is simply not enough. it has to be easy for users to get started. convinience and security both need a great deal of attention. the quality of either is dependent how much time i put into them.

expect users to audit…

i dont expect users to audit the code. at this stage in the project when im still putting it together, i can confirm this code isnt good enough to audit… third-party audits are important to have, but they are prohibitively expensive so dont expect one any time soon.

There’s nothing the browser can do to protect its data if the OS falls into the hands of an attacker

thats just wrong. its possible to combine the filesystem api and the crypto api. a previous post on the matter: https://programming.dev/post/33435342 … in this app i have a working version of passkey-encryption-at-rest. so a user has to register a passkey on their device and all the data is then encrypted at rest in indexedDB… users didnt like that every time they reload the page, the webapp was asking for a fingerprint to unlock… so that feature is disabled for now untill i make it so it can be disabled if the user wants. there is much more to think about there and that could be a whole separate discussion as we consider things like devices supporting passkeys PRF and how “recovery” could work.

censor your app

the frontend (this project), the backend (peerjs-server) and stun/turn servers can be selfhosted. but that moves away from what i can offer. id also like to investigate options for onion-style routing which the stray further from “minimal infrastructure” of p2p commmunication. https://programming.dev/post/41521230

low latency/high bandwidth the protocol was designed for

ive been working on this project for a while. it started off as a p2p messaging framework. i created a simple video calling app and the functionality naturally started leaning towards file transfer and messaging. the logical progression of the framework was to wrap it in a messaging app where you would want low latency/high bandwidth video calls and file transfer. these functionalities are in contrast to tasks like moving files between computers using some cloud service.

people need to stay fae away when security is involved

ive had this kind of fear-mongering/gatekeeping a lot in the cyber security community. its understandable to have high standard and expectation for things like security. but if kerhof’s principles are worth anything, they would apply to this project. in the open source version the concept is resonably demonstrated and there is documentation about how it works on the website. spicier things like “how the crytography works” are actively discussed online (like this). its clear that the code is too complicated for anyone to use their spare time review, buts its at least an option. i have recieved good feedback and iterated over what you see.

For anyone reading this thread looking for a secure chat app, just use Delta Chat, or even Signal (which has some issues, but it’s better than nothing).

agreed. my project is far from finished.

What is not secure here?

javascript over the internet can be be intercepted by a network admin or ISP. if acting maliciously, then it could swap the static js files for their own. particularly concern for webapps because every time you load the webpage, it would load the latest statics, which could have been altered on the network level to provide comprimised functionality. id like to have the service worker cache the statics to avoid that issue. it might be also worth repeating that you can just run the index.html in a browser to avoid fetching new statics. the app is ultimately provided as a webapp to help users get started… because it doesnt rely on knowing seemingly basic things like “how to run the index.html file in a browser” (which, im sure i know many people who dont… and i suspect thats the majority of the users)

PWA security is entirely at the mercy of whatever browser you installed it in

thats the whole point. we step away from “iOS and Android” and enable users to run this on their platform-of-choice. generally, all “modern” operating systems support browsers out-the-box. users should be responsible with how they run this app: e.g. if you trust firefox more than chrome.

they can block your TURN/STUN servers pretty easily

im using the metered.ca turn servers because they have a free plan (more than enough when i limit it to only brokering p2p connections). you have the option to use your own api key to do things like enable a “relay-mode”, which will proxy all messages. using the api key is simple UI abstraction for users to configure a TURN/STUN server. im open to make this as configurable as nessesary if users want to add multiple of their own servers.

P2P is inherently less reliable

“reliable” is a relative term. its entirely possible a centralized backend goes down. its a known fact that in a p2p architecture, peers have to be online to recieve messages… while you dont have things like the ability to send messages offline, there is no backend server in the p2p architecture to go down.

meshtastic

meshtastic is a great solution. i bought a couple units to try it out to integrated their app into my webapp: https://chat.positive-intentions.com/#/meshtastic … its basically a wrapper within my app. i wouldnt plan for go “all in” on meshtastic at all, but i see that it could be useful for smaller payloads (loads more investigation needs to be done to have anything usable). my app is speciafically based on webrtc, which has unparalelled transfer speeds; which is especially useful when sending large files. meshtastic could struggle to exchange a gif. meshtastics has a good reputation in cyber-sec, but i suspect it isnt more popular because people want modern messaging app multimedia capabilities. my app is presented as a webapp specifically for the average joe to get started.

ultimately, its always worth repeating that this is a work in progress and not redy to replace any of the existing app or services.

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

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.