Enkrypted.Chat

This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort. A fairly unique offering in the cybersecurity space.

No need for things like phone numbers or registering to any app stores. There are no databases to be hacked. Allowing users to send E2EE messages and files; no cloud, no trace.

Features:

• PWA
• P2P
• End to end encryption
• Signal protocol
• Post-Quantum cryptography
• Multimedia
• File transfer
• Video calls
• Local-first
• No registration
• No installation
• No database
• TURN server

I started off with some open source versions of the core concepts.

• Chat
  • Code: https://github.com/positive-intentions/chat
  • Demo: https://chat.positive-intentions.com/
• File
  • Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js
  • Demo: https://dim.positive-intentions.com/?path=%2Fdocs%2Fusefs--docs
• Crypto
  • Code: https://github.com/positive-intentions/cryptography
  • Demo: https://cryptography.positive-intentions.com/

Open source isnt sustainable. So im taking the Enkrypted.Chat project in a different direction.

To get started, you can take a look here: https://positive-intentions.com/docs/projects/enkrypted-chat/getting-started

To learn more or you want to do a deep-dive: https://positive-intentions.com/blog/introducing-enkrypted-chat

If you really want something to chew on, these are the bleeding-edge docs: https://positive-intentions.com/docs/technical

The docs may answer some questions, but feel free to reach out for clarity instead of reading all that slop.

IMPORTANT: Caution should be used for any unfamiliar project, especially this. I'd like to be clear that I am Al-slop-maxxing at scale. If youre looking for good code, clear docs or best-practices; you should look away now. While this is aiming to provide secure experience, it isnt audited or reviewed. I'm sharing for testing, feedback and demo purposes only. This is a technical demo of a unique concept. Please use responsibly.

(Note: Im actively in the process of rebranding from "positive-intentions" to "Enkrypted Chat". The wording may be inconsistent throughout the docs.)

Been banned for AI-Slop on a few subs here on Lemmy as well as on Reddit.

I always provide a good amount of technical detail in my posts and i try to be as transparant and communicative about the details. My projects are very complicated and I try to document them well.

my project is pretty cryptography-heavy... the act of me sharing my efforts in an attempt to show transparency... but it is used against my project by calling it AI-slop (undermining Kerkhoff's principles).

It's 2026 and most developers are using AI. I have used it to create things like formal proof and verification.

my project is aimed to be a secure messaging app. i have all the bells-and-whistles there along with documentation.... but if the conversation cant move past "its AI-generated"... then it seems the cryptography/cybersecurity/privacy community isnt aligned with the fact that using AI is now common practice for developers of all levels.

AI is a tool. you cant (and shouldnt) "trust" AI to do anything without oversight. AI does not replace the due-diligence that has always been needed. i dont "trust" my hammer to bash in a nail... i "use" the hammer. AI is not different in how you need to be responsible for how its used.

i've busted my ass on my project for it to be called AI slop. i think its completely fine when it comes from folks in the community. cryptography is a serious subject and my ideas and implementation SHOULD/MUST be scrutinised... but its simply ignorant if mods are banning me for the quality of my work considering the the level of transparency and my engagement on discussions about it.

It's a bit reductive to call it slop. I think i try harder than most in providing links, code and documentation. Of course I used AI... and it's clearer for it. (you can find more detail on my profile)

i am of course sour from being banned, but am i wrong to think my code isnt AI slop? Some parts of my project are clearly lazy-ui... but im not sharing on some UI/UX/design sub. the cryptography module has unit tests and formal verification. if that is AI-slop and can result in me being banned, i simply dont have faith in that community to be objective on the reality of where AI can contribute.

while its understandable people dont want to review AI-slop... i think the cryptography/cybersecurity community needs to get on board with the idea of using AI to help in reviewing such code. am i wrong? is the future of cryptography is still people performing manual review of the breathtaking volumes of AI code?

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

• App: https://chat.positive-intentions.com/

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

• Mastodon: https://infosec.exchange/@xoron

• Reddit: https://www.reddit.com/r/positive_intentions

How it works: https://positive-intentions.com/docs/projects/chat

TLDR: im working on a p2p messaging webapp. webapps are generally not considered secure because of the nature of serving satics over the internet. this is correct, but not a limitation of this project. (selfhosting options: https://positive-intentions.com/blog/docker-ios-android-desktop).

as a webapp, i can provide the app with zero-installation and no-registration. the storage is local-only from your browser/device. so “the cloud”, but the cloud storage capacity is made up of your devices. this allows for things like p2p authentication: https://positive-intentions.com/blog/security-privacy-authentication.

Future: im aiming to create the most secure messaging app out there... (more than signal, simplex, etc). i know i have a have a long way to go to get there. the UI is fairly ugly for the average user, but i think the mechanics are working as expected. i think javascript is underrated in what you can do with it. i actively investigting improving the encryption approach further to align to how the signal protocol works (currently using the classic diffie-helman key-exchange).

Support: i would like to keep this project open source, but open-source funding is not working for me. i dont want your donations because it isnt sustainable for a long-term project. i have so far only experienced grant-funding rejections. i have no idea what im doing in trying to get funding for this project, so any support/advice is appriciated. in recognition of the project in its current state not able to get funding... (sorry) i will have to go close-source (which id like to avoid because it undemines several cybersecurity claims id like to make.)

Decentralized Architecture: https://positive-intentions.com/blog/decentralised-architecture

While my approach here could be considered overly complicated (because, well, it is), I'm trying something new, and it's entirely possible this strategy won't be viable long-term. My philosophy is "there's only one way to find out." I'm not necessarily recommending this approach, just sharing my journey and what I'm doing.

Potential Benefits

I've identified some interesting benefits to this approach:

• Statics as Chat App Infrastructure: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

While I often see module federation and microfrontends discouraged in online discussions, I believe they're a good fit for my specific approach. I'm optimistic about the benefits and wanted to share the details.

When serving the federated modules, I can also host the Storybook statics. I think this could be an excellent way to document the modules in isolation.

Modules and Applications

Here are some examples of the modules and how they're being used:

• Cryptography Modules: https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs
• P2P Framework: https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

This setup allows me to create microfrontends that consume these modules, enabling me to share functionality between different applications. The following applications, which have distinct codebases (and a distinction between open and closed source), would be able to leverage this:

• P2P Chat: https://chat.positive-intentions.com/
• P2P File Transfer: https://file.positive-intentions.com/

Sharing these dependencies should make it easier to roll out updates to core mechanics across these diverse applications.

Furthermore, this functionality also works when I create an Android build with Tauri. This could streamline the process of creating new applications that utilize these established modules.

Considerations and Future

I'm sure there will be some distinct testing and maintenance overhead with this architecture. However, depending on how it's implemented, I believe it could work and make it easier to improve upon the current functionality.

It's important to note that everything about this project is far from finished. Some might view this as an overly complicated way to achieve what npm already does. However, I think this approach offers greater flexibility by allowing for the separation of open and closed-source code for the web. Of course, being JavaScript, the "source code" will always be accessible, especially in the age of AI where reverse-engineering is more possible than ever before.

Decentralized Architecture: https://positive-intentions.com/blog/decentralised-architecture

While my approach here could be considered overly complicated (because, well, it is), I'm trying something new, and it's entirely possible this strategy won't be viable long-term. My philosophy is "there's only one way to find out." I'm not necessarily recommending this approach, just sharing my journey and what I'm doing.

Potential Benefits

I've identified some interesting benefits to this approach:

• Statics as Chat App Infrastructure: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

While I often see module federation and microfrontends discouraged in online discussions, I believe they're a good fit for my specific approach. I'm optimistic about the benefits and wanted to share the details.

When serving the federated modules, I can also host the Storybook statics. I think this could be an excellent way to document the modules in isolation.

Modules and Applications

Here are some examples of the modules and how they're being used:

• Cryptography Modules: https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs
• P2P Framework: https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

This setup allows me to create microfrontends that consume these modules, enabling me to share functionality between different applications. The following applications, which have distinct codebases (and a distinction between open and closed source), would be able to leverage this:

• P2P Chat: https://chat.positive-intentions.com/
• P2P File Transfer: https://file.positive-intentions.com/

Sharing these dependencies should make it easier to roll out updates to core mechanics across these diverse applications.

Furthermore, this functionality also works when I create an Android build with Tauri. This could streamline the process of creating new applications that utilize these established modules.

Considerations and Future

I'm sure there will be some distinct testing and maintenance overhead with this architecture. However, depending on how it's implemented, I believe it could work and make it easier to improve upon the current functionality.

It's important to note that everything about this project is far from finished. Some might view this as an overly complicated way to achieve what npm already does. However, I think this approach offers greater flexibility by allowing for the separation of open and closed-source code for the web. Of course, being JavaScript, the "source code" will always be accessible, especially in the age of AI where reverse-engineering is more possible than ever before.

im working on a webapp and im being creative on the approach. it might be considered over-complicated (because it is), but im just trying something out. its entirely possible this approach wont work long term. i see it as there is one-way-to-find-out. i dont reccomend this approach. just sharing what im trying/investigating.

how it will be architected: https://positive-intentions.com/blog/decentralised-architecture

some benefits of the approach: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

i find that module federation and microfronends to generally be discouraged when i see posts, but it i think it works for me in my approach. im optimisic about the approach and the benefits and so i wanted to share details.

when i serve the federated modules, i can also host the storybook statics so i think this could be a good way to document the modules in isolation.

cryptography modules - https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs

p2p framework - https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

this way, i can create microfrontends that consume these modules. i can then share the functionality between apps. the following apps are using a different codebase from each other (there is a distinction between these apps in open and close source). sharing those dependencies could help make it easier to roll out updates to core mechanics.

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

p2p file transfer - https://file.positive-intentions.com/

the functionality also works when i create an android build with Tauri. this could also lead to it being easier to create new apps that could use the modules created.

im sure there will be some distinct test/maintainance overhead, but depending on how its architected i think it could work and make it easier to improve on the current implementation.

everything about the project is far from finished. it could be see as this is a complicated way to do what npm does, but i think this approach allows for a greater flexibility by being able to separating open and close source code for the web. (of course as javascript, it will always be "source code available". especially in the age of AI, im sure its possible to reverse-engineer it like never before.)

im working on a webapp and im being creative on the approach. it might be considered over-complicated (because it is), but im just trying something out. its entirely possible this approach wont work long term. i see it as there is one-way-to-find-out. i dont reccomend this approach. just sharing what im trying/investigating.

how it will be architected: https://positive-intentions.com/blog/decentralised-architecture

some benefits of the approach: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

i find that module federation and microfronends to generally be discouraged when i see posts, but it i think it works for me in my approach. im optimisic about the approach and the benefits and so i wanted to share details.

when i serve the federated modules, i can also host the storybook statics so i think this could be a good way to document the modules in isolation.

cryptography modules - https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs

p2p framework - https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

this way, i can create microfrontends that consume these modules. i can then share the functionality between apps. the following apps are using a different codebase from each other (there is a distinction between these apps in open and close source). sharing those dependencies could help make it easier to roll out updates to core mechanics.

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

p2p file transfer - https://file.positive-intentions.com/

the functionality also works when i create an android build with Tauri. this could also lead to it being easier to create new apps that could use the modules created.

im sure there will be some distinct test/maintainance overhead, but depending on how its architected i think it could work and make it easier to improve on the current implementation.

everything about the project is far from finished. it could be see as this is a complicated way to do what npm does, but i think this approach allows for a greater flexibility by being able to separating open and close source code for the web. (of course as javascript, it will always be "source code available". especially in the age of AI, im sure its possible to reverse-engineer it like never before.)

I've been looking at the WebCrypto API. When combined with the File system API, it can be used to encrypt and store files on your device storage in what seems to be a pretty secure way.

A webapp has some clear vulnerabilities with the code being served over the web (so you shouldnt be using this for any serious purposes!).

Live demo: https://dim.positive-intentions.com/?path=%2Fstory%2Fusefs--encrypted-demo

Demo code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js

IMPORTANT NOTES TO PREVENT MISLEADING

• this isnt a product. it provided for testing and demo.
• it isnt reviewed or audited.
• the "password encryption" is using a hardcoded password. id like to aim for a passwordless approach for this, but i havent considered it enough to discuss yet :)
• this isnt aimed to replace anything like veracrypt. just to show a comparison.
• this respository represents a webcomponent UI framework. while it holds some ideas i think are interesting, the ui framework seems like its going to be deprecated and i will be refactoring the functionality in favour of React.

Not to poke at React or any of the other popular frameworks, I'm sure they're suitable for Cybersecurity projects. They surely go through things like reviews and audits.

I'm asking from the perspective that web components are native to the browser and thus reducing what I think is called supply chain attacks (like if "npm install" introduces something it shouldn't).

Maybe the frameworks don't matter and depends on the browser/os/device it's run on?

Context: I have a p2p messaging app created with ReactJS and a separate project for a UI framework based on Lit. Both these projects can be a whole separate discussion. I was wondering if there could be any advantages to refactoring (or starting from scratch) the messaging-app to be based on the webcomponent ui framework.

Same question on Reddit with comments here. I have an answer there, but posting here in-case anything is being overlooked.

Not to poke at React or any of the other popular frameworks, I'm sure they're suitable for Cybersecurity projects. They surely go through things like reviews and audits.

I'm asking from the perspective that web components are native to the browser and thus reducing what I think is called supply chain attacks (like if "npm install" introduces something it shouldn't).

Maybe the frameworks don't matter and depends on the browser/os/device it's run on?

Context: I have a p2p messaging app created with ReactJS and a separate project for a UI framework based on Lit. Both these projects can be a whole separate discussion. I was wondering if there could be any advantages to refactoring (or starting from scratch) the messaging-app to be based on the webcomponent ui framework.

Same question on r/ExperiencedDevs with comments here. I have an answer there, but posting here in-case anything is being overlooked.