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

Introducing Dim – a new framework that brings React-like functional JSX-syntax with JS. Check it out here:

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

🔗 Website: https://dim.positive-intentions.com/

My journey with web components started with Lit, and while I appreciated its native browser support (less tooling!), coming from ReactJS, the class components felt like a step backward. The functional approach in React significantly improved my developer experience and debugging flow.

So, I set out to build a thin, functional wrapper around Lit, and Dim is the result! It's a proof-of-concept right now, with "main" hooks similar to React, plus some custom ones like useStore for encryption-at-rest. (Note: state management for encryption-at-rest is still unstable and currently uses a hardcoded password while I explore passwordless options like WebAuthn/Passkeys).

You can dive deeper into the documentation and see how it works here:

📚 Dim Docs: https://positive-intentions.com/docs/category/dim

This project is still in its early stages and very unstable, so expect breaking changes. I've already received valuable feedback on some functions regarding security, and I'm actively investigating those. I'm genuinely open to all feedback as I continue to develop it!

Introducing Dim – a new framework that brings React-like functional JSX-syntax with JS. Check it out here:

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

🔗 Website: https://dim.positive-intentions.com/

My journey with web components started with Lit, and while I appreciated its native browser support (less tooling!), coming from ReactJS, the class components felt like a step backward. The functional approach in React significantly improved my developer experience and debugging flow.

So, I set out to build a thin, functional wrapper around Lit, and Dim is the result! It's a proof-of-concept right now, with "main" hooks similar to React, plus some custom ones like useStore for encryption-at-rest. (Note: state management for encryption-at-rest is still unstable and currently uses a hardcoded password while I explore passwordless options like WebAuthn/Passkeys).

You can dive deeper into the documentation and see how it works here:

📚 Dim Docs: https://positive-intentions.com/docs/category/dim

This project is still in its early stages and very unstable, so expect breaking changes. I've already received valuable feedback on some functions regarding security, and I'm actively investigating those. I'm genuinely open to all feedback as I continue to develop it!

Introducing Dim – a new framework that brings React-like functional JSX-syntax with JS. Check it out here:

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

🔗 Website: https://dim.positive-intentions.com/

My journey with web components started with Lit, and while I appreciated its native browser support (less tooling!), coming from ReactJS, the class components felt like a step backward. The functional approach in React significantly improved my developer experience and debugging flow.

So, I set out to build a thin, functional wrapper around Lit, and Dim is the result! It's a proof-of-concept right now, with "main" hooks similar to React, plus some custom ones like useStore for encryption-at-rest. (Note: state management for encryption-at-rest is still unstable and currently uses a hardcoded password while I explore passwordless options like WebAuthn/Passkeys).

You can dive deeper into the documentation and see how it works here:

📚 Dim Docs: https://positive-intentions.com/docs/category/dim

This project is still in its early stages and very unstable, so expect breaking changes. I've already received valuable feedback on some functions regarding security, and I'm actively investigating those. I'm genuinely open to all feedback as I continue to develop it!