NOTE: This is still a work-in-progress and far from finished. It is free to use and not sold or monetized in any way. It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app. I have open source examples of various part of the app and im sure more investigation needs to be done for all details of this project. USE RESPONSIBLY!
I usually post along the lines of "promoting my project". I'm aiming for this post to be more technical. I hope to make it clear how the project works and some features/capabilities I will be working on. Feel free to reach out for clarity.
Im aiming to create the "theoretically" most secure messaging app. This has to be entirely theoretical because its impossible to create the "most secure messaging app". Cyber-security is a constantly evolving field and no system can be completely secure.
If you'd humor me, i tried to create an exhaustive list of features and practices that could help make my messaging app as secure as possible. Id like to open it up to scrutiny.
(Im grouping into green, orange and red because i coudnt think of a more appropriate title for the grouping.)
Green
- P2P - so that it can be decentralized and not rely on a central server for exchanging messages. The project is using WebRTC to establish a p2p connection between browsers.
- End to end encryption - so that even if the messages are intercepted, they cannot be read. The project is using an application-level cascading cipher on top of the encryption provided by WebRTC. the key sub-protocols involves in the approach are Signal, MLS and AES. while there has been pushback on the cascading cipher, rest-assured that this is functioning on and application-level and the purpose of the cipher is that it guarantees that the "stronger" algoritm comes up on top. any failure will result in a cascading failure... ultimately redundent on top of the mandated WebRTC encryption. i would plan to add more protocols into this cascade to investigate post-quantum solutions.
- Perfect forward secrecy - so that if a key is compromised, past messages cannot be decrypted. WebRTC already provides a reasonable support for this in firefox. but the signal and mls protocol in the cascading cipher also contribute resiliance in this regard.
- Key management - so that users can manage their own keys and not rely on a central authority. there is key focus on having local-only encryption keys. sets of keys are generated for each new connection and resued in future sessions.
- Secure signaling - so that the initial connection between peers is established securely. there are many approaches to secure signaling and while a good approach could be exchanging connection data offline, i would also be further improving this by providing more options. its possible to establish a webrtc connection without a connection-broker like this.
- Minimal infrastructure - so that there are fewer points of failure and attack. in the Webrtc approach, messages can be sent without the need of a central server and would also work in an offline hotspot network.
- Support multimedia - so that users can share animations and videos. this is important to provide an experience to users that makes the project appraling. there is progress made on the ui component library to provide various features and functionality users expect in a messaging app.
- Minimize metadata - so no one knows who’s messaging who or when. i think the metadata is faily minimal, but ultimately is reletive to how feature-rich i want the application. things like notification that a "user is typing" can be disabled, but its a common offering in normal messaging apps. similarly i things read-reciepts can be a useful feature but comes with metadata overhead. i hope to discuss these feature more in the future and ultimately provide the ability to disable this.
Orange
- Open source - moving towards a hybrid approach where relevent repositories are open source.
- Remove registration - creating a messaging app that eliminates the need for users to register is a feature that i think is desired in the cybersec space. the webapp approach seems to offer the capabilities and is working. as i move towards trying to figure out monetization, im unable to see how registration can be avoided.
- Encrypted storage - browser based cryptography is fairly capable and its possible to have important data like encryption keys encrypted at rest. this is working well when using passkeys to derive a password. this approach is still not complete because there will be improvements to take advantage of the filesystem API in order to have better persistence. passkeys wont be able to address this easily because they get cleared when you clear the site-data (and you lose the password for decrypting the data).
- User education - the app is faily technical and i could use a lot more time to provide better information to users. the current website has a lot of technical details... but i think its a mess if you want to find information. this needs to be improved.
- Offline messaging - p2p messaging has its limitations, but i have an idea in mind for addressing this, by being able to spin up a selfhosted version that will remain online and proxy messages to users when they come online. this is still in the early stages of development and is yet to be demonstrated.
- Self-destructing messages - this is a common offering from secure messaging apps. it should be relatively simple to provide and will be added as a feature "soon".
- Javascript - there is a lot of rhetiric against using javascript for a project like this because of conerns about it being served over the internet. this is undestandable, but i think concerns can be mitigated. i can provide a selfhostable static-bundle to avoid fetching statics from the intetnet. there is additional investigation towards using service workers to cache the nessesary files for offline. i would like to make an explicit button to "fetch latests statics". the functionality is working, but more nees to be done before rolling out this functionality.
- Decentralized profile: users will want to be able to continue conversations across devices with multidevice-sync. It's possible to implement a p2p solution for this. This is an ongoing investigation.
Red
- Regular security audits - this could be important so that vulnerabilities can be identified and fixed promptly. security audits are very expensive and until there is any funding, this wont be possible. a spicier alternative here is an in-house security audit. i have made attempts to create such audits for the signal protocols and MLS. im sure i can dive into more details, but ultimately an in-house audit in invalidated by any bias i might impart.
- Anonymity - so that users can communicate without revealing their identity is a feature many privacy-advocates want. p2p messages has nuanced trandoffs. id like to further investigate onion style routing, so that the origins can be hidden, but i also notice that webrtc is generally discourage when using the TOR network. it could help if users user a VPN, but that strays further from what i can offer as part of my app. this is an ongoing investigation.
FAQs:
Why are there closed source parts? - This project comes in 2 flavours; open-source and close-source. To view the open source version see here. ive tried several grants applications and places that provide funding for open source project. im aware they exist… unfortunately they rejected this project for funding. Im sure many are inundated with project submissions that have a more professional quality and able to articulate details better than myself. Continuing with open source only seems to put me at a competative disadvantage.
Monetization - Im investigating introducing clerk. I hope to use that to create a subscription model. I would like to charge $1 per-month as per the minimum allowed by clerk. I started off thinking i could avoid charging users entirely given it seems a norm for secure messaging apps to be free. but given the grant rejects and the lack of donations on github sponsors (completely understandable), but its clear that it wont be able to sustain the project. I tried Google adsense on the website/blog but it was making practically nothing; so i disabled it because it wasnt a good look when it goes against the whole “degoogling” angle. This project is currently not funded or monnetized in any way. (Its not for lack of trying)
How does it compare against signal, simpleX, element, etc? - The project is far from finished and it woudnt make sense to create something as clear as a comparison table. Especially because core features like group-messaging isnt working. Some technical details can be seen here if your want to draw your own comparison.
- https://positive-intentions.com/docs/projects/chat
- https://positive-intentions.com/docs/category/sparcle
Javascript over the internet is not secure - im investigating the to use service workers to cache the file. this is working to some degree, but needs improvement before i fully roll it out… i would like to aim for something like a button on the UI called “Update” that would invalidate the service-worker cache to trigger an update. I hope to have something more elegant than selfhosting on localhost or using a dedicated app. its possible to provide a static bundle that can work from running index.html in a browser without the need to run a static server. The static bundle of the open source version can be seen and tested to work from this directory: https://github.com/positive-intentions/chat/tree/staging/Frontend . When i reach a reasonable level of stability on the app, i would like to investigate things like a dedicated app as is possible on the open source version. https://positive-intentions.com/blog/docker-ios-android-desktop
How is this different to any other messaging app? - the key distinction between this project and other like it like signal and simpleX is that its presented as a PWA. A key cybersecurity feature of this form-factor is that it can avoid installation and registration. its understandable that such a feature doesnt appeal to everyone, but along with the native build, it should cover all bases depending on your threat model.
What about Chat Control? - I see a lot a fear mongering in the cybersecurity community around chat-control. I aim to create something that doesn't have the censorship pitfalls of a traditional architecture. A previous post on the matter: https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my
Is it vibecoded? - AI is being used appropriately to help me in various aspects. I hope it doesnt undermine the time and effort i put into the project.
Aiming to provide industry grade security encapsulated into a standalone webapp. Feel free to reach out for clarity on any details or check out the following links:
- Docs: https://positive-intentions.com/
- Subreddit: https://www.reddit.com/r/positive_intentions
- Mastodon: https://infosec.exchange/@xoron
IMPORTANT NOTE: It's worth repeating, this is still a work in progress and not ready to replace any existing solution. many core features like group-messaging are not working. Provided for testing, demo and feedback purposes only.
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)
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.
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.
"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 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.
Let me introduce you to my good friend HTTPS, and PKI more broadly.
So is it about convenience, or security? You expect users to audit their multi-million LOC open source web browser and supply chain before using your app?
Browsers are notoriously not secure. Javascript is heavily sandboxed and access to operating system resources is heavily restricted, so attacks through there are relatively rare. However, attacks from the OS side are almost trivial execute. There's nothing the browser can do to protect its data if the OS falls into the hands of an attacker (eg malware or device confiscation)
That doesn't solve the issue I brought up, which is that a state actor can trivially censor your app by attacking those servers. By contrast, blocking Delta chat would require them to block the entirety of Gmail, for example.
No. Your app is either reliable, or it isn't. A centralized service is vulnerable to being taken down, but that has nothing to do with reliability. The majority of internet traffic goes to centralized sites with 99.99%+ uptime.
IMO, a chat app that struggles to send or receive messages is a toy. It's like trying to use the Pine Phone as a daily driver if you're someone who actually needs to male phone calls every day. Except, pinephone's reliability issues are implementation details that theoretically could be fixed, whereas your app's are architectural that would require a redesign. That's partly why I brought up meshtastic, because it's at least a fun toy.
Comments like this, and your apparent misunderstanding of basic HTTPS make me think you're just vibe coding all of this. WebRTC doesn't have "unparalleled" transfer speeds. That sounds like something ChatGPT would say. WebRTC is a just protocol designed to provide a simple way to do streaming in the browser, without requiring apps to build their own custom protocols on top of eg websockets. Using it for text messages is kind of absurd, because such an application doesn't fit the low latency/high bandwidth the protocol was designed for.
There's nothing wrong with vibe coding btw, you do you, but people need to stay fae away when security is involved.
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). If you're feeling adventurous, look into meshtastic.
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.
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.
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.
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.
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
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.
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.
agreed. my project is far from finished.
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? Because if it's the latter, you're unfortunately not pulling it off this way. Anyone you convince to use this will have their data and privacy at risk, and nothing you've posted here gives me confidence that this will change no matter how much you continue to develop it. It's clear that you are out of your depth here. An LLM isn't going to fill the gap in knowledge and experience you'd need to pull this off successfully. There's no point continuing this discussion, especially if you're just acting as a middle man to ChatGPT.
If this was a side project you were doing for fun, I wouldn't care. But you've been going around pushing this on the fediverse and reddit, and seem to be trying to make money off of it. Giving you the benefit of the doubt, I'll assume you're a well-intentioned person led astray by a sycophantic LLM (which is very common) rather than a grifter.
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.
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.
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.
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.