xoron

TLDR; If you're looking for great engineering and best-practices... you should move away now. I'm creating a solution to a problem that nobody (including myself) has. I'm working with module federation between multiple cloud-providers to create an app that can use interoperable modules from multiple sources.

I have a webapp that I deploy with aws-cdk. It's a static webapp that I have on on S3.

AWS-cdk works as expected, but now id would like to investigate a multicloud deployment. Using something like pulumi or terraform (but not limited to those)

Most vendors have something like S3 and so I would like to have something that can deploy to multiple cloud vendors simultaneously.

In that approach, I would like an exhaustive number of vendor providers. I don't just want the top vendors like aws, gcloud, azure... But I'm looking for something that can also handle providers over seas like Alibaba cloud, Kamatera and I'm sure many I haven't heard of.

My project only needs something like S3 (static server) so I don't expect that being exhaustive in providers would be too expensive.

Im looking for something like terraform or pulumi, but I haven't user either enough to settle on one. When deploying to the S3 equivilent, i dont want it to deploy to either GCloud or Azure... i want it to be able to deploy to both.

(aws-cdk is handling things like the TLD so i think i'll have to stick with that setup.)

To provide more context about what I'm trying to do, I created a webapp that uses webpack module federation. (see my profile for more details)

The aim is for a resilient infrastructure. S3 is not expected to fail, but in a multicloud approach, if any cloud provider has issues, i want there to already be multiple redundancies in place.

I deploy the same app on gh-pages and aws-s3. Its set it up in a way that it can interoperate with statics from aws-s3 or gh-pages. It works as expected.

https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure#module-federation-in-action

I'd like to scale that up further, so the next level after that is to have something that can deploy to multiple cloud providers.

(Unrelated but worth mentioning: i will also be adding SRI on those imported static files to make sure they have a content-hash that matches expectations. I wont have to "trust" that the providers are serving the correct statics.)

Signal doesnt create a webapp version for valid reasons around vulnerabilities of a webapp. In my project i approach the architecture differently that means it can overcome some of those limitations.

The goal is for it to be at least as secure as the Signal messaging app with their Signal protocol.

My project is pretty ugly and large parts of it are still a work in progress, but i think its at a reasonable stage to demo and share. I started off with an open source version here: https://github.com/positive-intentions/chat

MVP Demo: https://chat.positive-intentions.com/

The open source version was largely created manually (without AI agents). I am a software developer and creating webapps is my is my expertise. Open source helps to be able to discuss details online. I think the core-concepts around client-side managed cryptography is demonstrated, but unfortunately open source isnt sustainable.

So its unfortunate i have to consider introducing close-source components into the project (, so that i can maintain a competative advantage).

Components now close source:

• UI component library: https://ui.positive-intentions.com/
• P2P framework: https://p2p.positive-intentions.com/
• Frontend: https://glitr.positive-intentions.com/

I still keep some components like the cryptography module open source for its importance in transparancy.

The close-source version 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.

Take a look at some of the technical docs which ive updated to answer questions i frequently recieve in previous posts.

Technical breakdown and roadmap: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown

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

Beta version: https://enkrypted.chat/

(Note: The alpha version is a bit more stable for testing, but the beta version is what is aimed towards being production ready... but it isnt there yet.)

If you really want something to chew on, you can take a look at the more comprehensive docs here: https://positive-intentions.com/docs/technical

IMPORTANT: Lets get a few things out of the way first. My app is not better than Whatsapp 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.

Feel free to reach out for clarity on any details.

Aiming to provide comparable features and functionality as mainstream messaging app.

https://github.com/positive-intentions/chat

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:

• PWA
• P2P
• End to end encryption
• Multimedia
• 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.

Take a look at some of the technical docs which ive updated to answer questions i frequently recieve in previous posts.

Technical breakdown and roadmap: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown

Demo: https://chat.positive-intentions.com/

If you really want something to chew on, you can take a look at the more comprehensive docs here: https://positive-intentions.com/docs/technical

I created the signal protocol for a related project. 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/

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.

The implementation is now moving past the MVP stage. It is integrated into a p2p messaging app. See it in action from the link on my profile.

While i have made attempts to create things like audits and formal-proofs, it isnt enough. I hope by sharing it, it can serve as a starting point for feedback about the implementation and highlight outstanding issues i may be overlooking. Its open source so you can take a look, but i completely understand it isnt worth your free time. Feel free to reach out for clarity on any details.

Ultimately id like to gear it up towards getting a professional third-party audit. If a free audit isnt going to happen, its prohibitively expensive... Users ask me questions about how my app works. In particular, people often ask about the protocol when it comes to cryptography. I'll have to share references to the AI audit, which id like to avoid.

TLDR; I’ve been experimenting with react-like jsx-syntax with webcomponents to see if I could theoretically replace React in one of my projects. It is not ready for production use, but rather an exploration into CustomElements and modern browser capabilities.

https://github.com/positive-intentions/dim

The goal was to build functional Web Components that handle state management and DOM updates without the overhead of a massive JavaScript framework. By leveraging standard Web APIs and Proxy objects, I’ve managed to create a reactive programming model that feels familiar—using JSX—but stays much closer to the browser platform.

I wanted to see how far i could take web components before the architecture broke down. If you’re interested in frontend software engineering or web standards, you might find the logic behind the updates (which avoid a traditional virtual DOM) interesting.

Full technical tutorial and deep dive: https://positive-intentions.com/docs/research/Tutorials/dim/dim-functional-webcomponents

Disclaimer: This project is not ready for production use. In fact, this project may be getting deprecated soon, but I’m sharing it because the unique details into custom elements and modern JavaScript performance might be interesting or educational for others exploring the web platform.

TLDR; I’ve been experimenting with react-like jsx-syntax with webcomponents to see if I could theoretically replace React in one of my projects. It is not ready for production use, but rather an exploration into CustomElements and modern browser capabilities.

https://github.com/positive-intentions/dim

The goal was to build functional Web Components that handle state management and DOM updates without the overhead of a massive JavaScript framework. By leveraging standard Web APIs and Proxy objects, I’ve managed to create a reactive programming model that feels familiar—using JSX—but stays much closer to the browser platform.

I wanted to see how far i could take web components before the architecture broke down. If you’re interested in frontend software engineering or web standards, you might find the logic behind the updates (which avoid a traditional virtual DOM) interesting.

Full technical tutorial and deep dive: https://positive-intentions.com/docs/research/Tutorials/dim/dim-functional-webcomponents

Disclaimer: This project is not ready for production use. In fact, this project may be getting deprecated soon, but I’m sharing it because the unique details into custom elements and modern JavaScript performance might be interesting or educational for others exploring the web platform.

TLDR; I’ve been experimenting with react-like jsx-syntax with webcomponents to see if I could theoretically replace React in one of my projects. It is not ready for production use, but rather an exploration into CustomElements and modern browser capabilities.

https://github.com/positive-intentions/dim

The goal was to build functional Web Components that handle state management and DOM updates without the overhead of a massive JavaScript framework. By leveraging standard Web APIs and Proxy objects, I’ve managed to create a reactive programming model that feels familiar—using JSX—but stays much closer to the browser platform.

I wanted to see how far i could take web components before the architecture broke down. If you're interested in frontend software engineering or web standards, you might find the logic behind the updates (which avoid a traditional virtual DOM) interesting.

Full technical tutorial and deep dive: https://positive-intentions.com/docs/research/Tutorials/dim/dim-functional-webcomponents

Disclaimer: This project is not ready for production use. In fact, this project may be getting deprecated soon, but I’m sharing it because the unique details into custom elements and modern JavaScript performance might be interesting or educational for others exploring the web platform.

IMPORTANT: Lets get a few things out of the way first. My app is not better than Whatsapp 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.

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:

• PWA
• P2P
• End to end encryption
• Signal protocol
• Post-quantum cryptography
• Multimedia
• 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 and roadmap: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown

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

I’ve been working on a P2P messaging implementation focused on mitigating "Harvest Now, Decrypt Later" risks by integrating Post-Quantum Cryptography (PQC) directly into the browser.

Since NIST recently finalized FIPS 203 (ML-KEM), I decided to implement ML-KEM encryption into my cascading. The goal was to ensure that the security of the exchange doesn't rely solely on the relatively new lattice-based assumptions of ML-KEM, but remains anchored by classical ECC (X25519) via the Signal Protocol.

I’m using a application-level cascading-cipher to merge the shared secrets from ML-KEM-768 and X25519. This follows the "composite" approach currently being discussed in IETF drafts to ensure the system is at least as strong as the strongest individual algorithm. The implementation wraps the Signal Protocol's Double Ratchet. Even if a future cryptanalytic breakthrough targets ML-KEM, the classical layer still requires a discrete log break to compromise.

I’ve put together a few resources for the community:

• Technical Write-up: A deep dive into the "Cascading Cipher" logic and the KDF used for the hybrid secret. https://positive-intentions.com/blog/quantum-resistant-encryption

• ML-KEM Standalone Demo: A tool to inspect the encapsulation/decapsulation process in the browser console. https://cryptography.positive-intentions.com/?path=%2Fstory%2Fcascading-cipher-ml-kem-demo--mlkem-standalone

• Messaging app demo: This implementation can be seen working in action in the webapp here https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story

• GitHub: the implementation is far from finished and not ready to review, but if curious, you can take a look here: https://github.com/positive-intentions/cryptography

(NOTE: We are talking about JavaScript for crypto. So it's important to be clear, that this is for end-to-end P2P browser communication where the environment is already JS-dependent, I'm using Web Crypto API where possible for the classical primitives. The only exception is the signal protocol, which needed primitives not provided by the browser: https://github.com/positive-intentions/signal-protocol.)

IMPORTANT: AI is used in this project, so lets get that out of the way. im not sure how to quantify it. i use different AI models on different tasks in the code as well as the documentation. i dont want to mislead or inspire undue confidence in this implementation. its open-source for transparency. not ready for general use.

its always worth mentioning this project is far from finished and i hope with feedback i can make it better. i have put efforts towards directing it towards unit-tests, audit and formal-proofs. none of that is good-enough, but i hope they can compliment each other and can act as a starting point for verifying the implementation is correct. the functionality is built around the requirements of my project. it isnt professionally audited or reviewed. use responsibly.

my motivation on this project is that im mainly working on a p2p messaging app. i hope you can understand the pushback i get when i promote my messaging app as “secure”, so this transparency with the signal protocol is nessesary. im sure people have better things to do with their time than review unstable and unfinished code. i only put it out there for you to take a look if you’re interested. as a solo dev, there isnt anyone reviewing my code. if i dont share it like this, no one will come across it.

This project is unfinished so I could be sharing it too early, I wonder if I'm sharing it too late at the point I'm using it 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/

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.

This signal-protocol implementation is purpose-built for a p2p messaging app. i posted about it a couple months ago here: https://programming.dev/post/44280693

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

IMPORTANT: it's worth repeating that this is not audited or reviewed. Its far from finished and I don't recommend you use it in your code. It's open source for transparency.

Edit:

Cryptography with AI isn't well received. Going to unlist the post.

IMPORTANT: AI is used in this project, so lets get that out of the way. im not sure how to quantify it. i use different AI models on different tasks in the code as well as the documentation. i dont want to mislead or inspire undue confidence in this implementation. its open-source for transparency. not ready for general use.

its always worth mentioning this project is far from finished and i hope with feedback i can make it better. i have put efforts towards directing it towards unit-tests, audit and formal-proofs. none of that is good-enough, but i hope they can compliment each other and can act as a starting point for verifying the implementation is correct. the functionality is built around the requirements of my project. it isnt professionally audited or reviewed. use responsibly.

my motivation on this project is that im mainly working on a p2p messaging app. i hope you can understand the pushback i get when i promote my messaging app as “secure”, so this transparency with the signal protocol is nessesary. im sure people have better things to do with their time than review unstable and unfinished code. i only put it out there for you to take a look if you’re interested. as a solo dev, there isnt anyone reviewing my code. if i dont share it like this, no one will come across it.

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/

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.

This signal-protocol implementation is purpose-built for a p2p messaging app. i posted about it a couple months ago here: https://programming.dev/post/43579394

IMPORTANT: AI is used in this project, so lets get that out of the way. im not sure how to quantify it. i use different AI models on different tasks in the code as well as the documentation. i dont want to mislead or inspire undue confidence in this implementation. its open-source for transparency. not ready for general use.

its always worth mentioning this project is far from finished and i hope with feedback i can make it better. i have put efforts towards directing it towards unit-tests, audit and formal-proofs. none of that is good-enough, but i hope they can compliment each other and can act as a starting point for verifying the implementation is correct. the functionality is built around the requirements of my project. it isnt professionally audited or reviewed. use responsibly.

my motivation on this project is that im mainly working on a p2p messaging app. i hope you can understand the pushback i get when i promote my messaging app as “secure”, so this transparency with the signal protocol is nessesary. im sure people have better things to do with their time than review unstable and unfinished code. i only put it out there for you to take a look if you're interested. as a solo dev, there isnt anyone reviewing my code. if i dont share it like this, no one will come across it.

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/

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.

This signal-protocol implementation is purpose-built for a p2p messaging app. i posted about it a couple months ago here: https://programming.dev/post/43579394