xoron

Id like to share my implementation of the signal protocol that i use in my messaging app. The implementation is in rust and compiles to WASM for browser-based usage.

• Github: https://github.com/positive-intentions/signal-protocol
• Demo: https://signal.positive-intentions.com/

Its far from finished and im not sure when its a good time to share it, but i think its reasonable now.

The aim is for it to align with the official implementation (https://github.com/signalapp/libsignal). That version was not used because my use case required client side browser-based functionality and i struggled to achieve that in the official one where javascript is used but is targeting nodejs.

There are other nuances to my approach like using module federation, which led to me moving away from the official version.

While i have made attempts to create things like audits and formal-proof verication, i am sharing it now if there is feedback about the implementation. Any outstanding issue i may be overlooking? Feel free to reach out for clarity on any details.

This signal implementation is for a p2p messaging app. See it in action here: https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story

IMPORTANT: Lets get a few things out of the way first. My app is not better than any other app in any way. It hasnt been reviewed or audited. This app works by exchanging IP addresses... This app is NOT for anonymous comms.

The project is experimental and far from finished. It's presented for testing, feedback and demo purposes only (USE RESPONSIBLY!).

By leveraging WebRTC for direct browser-to-browser communication, it eliminates the middleman entirely. Users simply share a unique URL to establish an encrypted, private channel. This approach effectively bypasses corporate data harvesting and provides a lightweight, disposable communication method for those prioritizing digital sovereignty.

Features:

• P2P
• End to end encryption
• Forward secrecy
• Post-quantum cryptography
• Multimedia
• Large file transfer
• Video calls
• No registration
• No installation
• No database
• TURN server

This project isnt finished enough to compare to existing tools like Simplex, Signal and WhatsApp... This is intended to introduce a new paradigm in client-side managed secure cryptography. Allowing users to send securely encrypted messages; no cloud, no trace.

Technical breakdown: https://programming.dev/post/44282222

Demo: https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story

Docs: https://positive-intentions.com/docs/technical

https://positive-intentions.com/docs/technical/architecture

i cooked a bit too hard on this. i don't advise you use this approach. its something I wanted to investigate for myself.

https://webpack.js.org/concepts/module-federation/#promise-based-dynamic-remotes

i was already using microfrontends for my project. when i came across dynamic remotes, i figured i could use it for statics redundency management. (tbh... a problem that doesnt exist.)

my project is far from finished and it would make sense to add additional safety nets for static-resource-integrity, but the basic concept seems to work and i wanted to share some details ive put together.

By leveraging WebRTC for direct browser-to-browser communication, it eliminates the middleman entirely. Users simply share a unique URL to establish an encrypted, private channel. This approach effectively bypasses corporate data harvesting and provides a lightweight, disposable communication method for those prioritizing digital sovereignty.

Features include:

• Webapp
• P2P
• End to end encryption
• Forward secrecy
• Post-quantum cryptography
• Multimedia
• Large file transfer
• Video calls
• No registration
• No installation
• No database
• TURN server

*** The project is experimental and far from finished. It's presented for testing, feedback and demo purposes only (USE RESPONSIBLY!). ***

This project isnt finished enough to compare to simplex, briar, signal, etc... This is intended to introduce a new paradigm in client-side managed secure cryptography. Allowing users to send securely encrypted messages; no cloud, no trace.

Technical breakdown: https://positive-intentions.com/blog/p2p-messaging-technical-breakdown

Demo: https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story

By leveraging WebRTC for direct browser-to-browser communication, it eliminates the middleman entirely. Users simply share a unique URL to establish an encrypted, private channel. This approach effectively bypasses corporate data harvesting and provides a lightweight, disposable communication method for those prioritizing digital sovereignty.

Features include:

• P2P
• End to end encryption
• Forward secrecy
• Post-quantum cryptography
• Multimedia
• Large file transfer
• Video calls
• No registration
• No installation
• No database
• TURN server

*** The project is experimental and far from finished. It's presented for testing, feedback and demo purposes only (USE RESPONSIBLY!). ***

This project isnt finished enough to compare to simplex, briar, signal, etc... This is intended to introduce a new paradigm in client-side managed secure cryptography. Allowing users to send securely encrypted messages; no cloud, no trace.

Technical breakdown: https://positive-intentions.com/blog/p2p-messaging-technical-breakdown

Demo: https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story

https://positive-intentions.com/blog/quantum-resistant-encryption

demo: https://cryptography.positive-intentions.com/iframe.html?args=&globals=&id=cascading-cipher-ml-kem-demo--mlkem-standalone&viewMode=story

code: https://github.com/positive-intentions/cryptography/blob/staging/src/crypto/CascadingCipher/layers/MLKEMCipherLayer.ts

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.

Demo

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

Demo

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.

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.

Demo

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

Demo

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.

NOTE: This is still a work-in-progress and partially a close-source project. To view the open source version see here. 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!

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.

Demo

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

Demo

FAQs:

Why are there closed source parts? - ive tried several grants applications and places that provide funding for open source project. im aware they exist… all 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 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? - https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my

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. Provided for testing, demo and feedback purposes only.

NOTE: This is still a work-in-progress and partially a close-source project. To view the open source version see here. 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!

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.

Demo

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

Demo

FAQs:

Why are there closed source parts? - ive tried several grants applications and places that provide funding for open source project. im aware they exist… all 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 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? - https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my

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. Provided for testing, demo and feedback purposes only.

IMPORTANT NOTE: This is still a work-in-progress and largely a close-source project. To view the deprecated open source MVP see here. Nothing has been audited or reviewed. This app should not be considered secure, private or even stable. I guarantee there will be breaking changes! Presented here for testing purposes only, not a replacement for any messaging app. There are countless details to improve throughout and it should not be used for sensitive/private/personal data. This project implements a unique but experimental approach to secure messaging with a PWA.

Want to send E2E encrypted messages and video calls with no downloads, no sign-ups and no tracking?

This prototype uses WebRTC to establish a secure browser-to-browser connection. Using browser-only storage—true zerodata privacy!

enkrypted.chat

The aim is to have an experience as close to Whatsapp as reasonably possible so that the experience is intuitive.

Some features include:

• P2P
• End to end encryption
• Browser-based
• No installation/registration
• Local-Only storage
• Text Messaging
• Multimedia Messaging
• File Transfer
• Video Calls

To find out more check out the docs.

• Docs: https://positive-intentions.com/
• Reddit: https://www.reddit.com/r/positive///_intentions
• Mastodon: https://infosec.exchange/@xoron

I wanted to investigate about onion routing when using WebRTC.

Im using PeerJS in my app. It allows peers to use any crypto-random string to connect to the peerjs-server (the connection broker). To improve NAT traversal, im using metered.ca TURN servers, which also helps to reduce IP leaking, you can use your own api key which can enable a relay-mode for a fully proxied connection.

For onion routing, i guess i need more nodes, which is tricky given in a p2p connection, messages cant be sent when the peer is offline.

I came across Trystero and it supports multiple strategies. In particular i see the default strategy is Nostr... This could be better for secure signalling, but in the end, the webrtc connection is working correctly by aiming for fewer nodes between peers - so that isnt onion routing.

SimpleX-chat seems to have something it calls 2-hop-onion-message-routing. This seems to rely on some managed SMP servers. This is different to my current architecture, but this could ba a reasonable approach.

In a WebRTC connection, would there be a benefit to onion routing?

It seems to require more infrastructure and network traffic... and can no longer be considered a P2P connection. The tradeoff might be anonymity. Maybe "anonymity" cannot be possible in a WebRTC connection.

Can the general advice here be to "use a trusted VPN"?