Lemmy isnt ready for this project and so deleting the post

I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.

This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.

• Enkrypted.Chat

This is intended to demonstrate client-side managed secure cryptography.

• Introducing Enkrypted Chat
• Whitepaper (work-in-progress)
• Protocol Spec (work-in-progress)
• Roadmap

I know the project above is going to be tricky to understand. It might help to understand with an open-source version of the concept for educational purposes. Its's important to note, i have since deprecated it in favour of the version linked above.

Open source demo (deprecated)

PS. Im calling it a "Signal Messenger Clone"... that's just a matter of how to frame it for users getting started. It doesnt work in a way thats comparable to the signal architecture. This project is fairly complicated and the links above are likely not going to be enough, so feel free to reach out for clarity on the details.

PPS. I made a similar post on Reddit and it seems to be reasonably well recieved and so branching out to Lemmy here. It might help to take a look there if questions are asked/answered already.

Lemmy isnt ready for this project and so deleting the post

I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.

This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.

• Enkrypted.Chat

This is intended to demonstrate client-side managed secure cryptography.

• Introducing Enkrypted Chat
• Whitepaper (work-in-progress)
• Protocol Spec (work-in-progress)
• Roadmap

I know the project above is going to be tricky to understand. It might help to understand with an open-source version of the concept for educational purposes. Its's important to note, i have since deprecated it in favour of the version linked above.

Open source demo (deprecated)

PS. Im calling it a "Signal Messenger Clone"... that's just a matter of how to frame it for users getting started. It doesnt work in a way thats comparable to the signal architecture. This project is fairly complicated and the links above are likely not going to be enough, so feel free to reach out for clarity on the details.

PPS. I made a similar post on Reddit and it seems to be reasonably well recieved and so branching out to Lemmy here. It might help to take a look there if questions are asked/answered already. https://www.reddit.com/r/BuyFromEU/comments/1v8cx0s/europeanbased_signal_messenger_alternative/

i am working on a messaging app and created some details in rust. rust is useful because it has tooling for formal verification. my rust code compiles to WASM to be used in a browser.

my project itself is using cryptography beyond the WASM because browsers provide a crypto api for basic functionality out-of-the-box.

to work with what i have now (javascript/typescript) i came across this page, but the links lead to 404 pages on github. not sure about the status of the project. i dont know if there are other similar projects.

https://formal.land/docs/verification/typescript

i would like to improve the "formal-verification coverage" in my project and wanted to investigate if it could be worth considering rewriting the frontend with dioxus. im happy with an ugly UI (initially) in favour of having formal-verification on a broader scope of my project.

(context: the project where i have formal verification is found here: https://github.com/positive-intentions/signal-protocol (this isnt the gold-standard implementation and its far from finished)

This is a technical demo of a fairly unique approach using a browser-based, local-first and webrtc approach.

• Enkrypted.Chat

This is intended to demonstrate client-side managed secure cryptography.

• Introducing Enkrypted Chat
• Whitepaper (work-in-progress)
• Protocol Spec (work-in-progress)
• Roadmap

Features:

• Core
  • PWA
  • P2P
  • Local-first / Local-only
  • No installation
  • TURN server
  • Encrypted-at-rest
• WhatsApp clone
  • End to end encryption
  • Signal protocol
  • Post-Quantum cryptography
  • Multimedia
  • File transfer
  • Video calls
• Nextcloud clone
  • Word
  • Spreadsheet
  • PDF
  • file-transfer
  • Encrypted vault

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/
• Signal Protocol
  • Code: https://github.com/positive-intentions/signal-protocol
  • Demo: https://signal.positive-intentions.com/

Feel free to reach out for clarity instead of diving into the docs.

IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.

A fairly unique approach to state management using encrypted asynchronous state updates.

It is not production-ready. I'm working on it to use in my own projects. It isn't reviewed or audited by a third-party, so I can't recommend you use it in your own code. Sharing for testing and demo purposes only.

TLDR; The title of this post.

Feel free to reach out for clarity instead of reading the code/docs.

I was working on “react-like syntax for webcomponents”. I started off with an approach for asynchronous state management so that components outside the shadow-root could receive updates. (The events are also encrypted to secure against things like browser extensions.)

https://positive-intentions.com/docs/projects/dim/async-state-management

It then made sense to be able to persist that data so it can work between page releoads.

https://positive-intentions.com/docs/projects/dim/bottom-up-storage

The result looks and works like the following when used in a project.

https://positive-intentions.com/docs/projects/dim/encrypted-store

The Dim framework seems like a dead-end. I wanted to try the hook out on my existing React projects. So I created the equivalent React hook.

https://positive-intentions.com/docs/projects/dim/use-dim-store-react

I find it to be performant and I want to push the scale of the approach, so I am in the process of testing it out on my projects. A notable use-case there is storing encrypted files at rest.

Feel free to reach out for clarity.

This is a technical demo of a fairly unique approach using a browser-based, local-first and webrtc approach. it allows to avoid centralized registration.

Enkrypted.Chat

This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort.

Features:

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

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/

Feel free to reach out for clarity instead of diving into the docs. Please use responsibly.

IMPORTANT: Caution should always be used for projects like this. While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. If youre unsure, this isnt for you.

TLDR; The title of this post.

Feel free to reach out for clarity instead of reading the code/docs.

I was working on a “react-like syntax for webcomponents”, I wanted to create something robust and flexible for secure data storage and management.

I started off with an approach for asynchronous state management so that components outside the shadow-root could receive updates. (The events are also encrypted to secure against things like browser extensions.)

https://positive-intentions.com/docs/projects/dim/async-state-management

It then made sense to be able to persist that data so it can work between page releoads.

https://positive-intentions.com/docs/projects/dim/bottom-up-storage

The result looks and works like the following when used in a project.

https://positive-intentions.com/docs/projects/dim/encrypted-store

The Dim framework seems like a dead-end. I wanted to try it out on my existing React projects. So I created the equivalent React hooks.

https://positive-intentions.com/docs/projects/dim/use-dim-store-react

I find it to be performant and I want to push the scale of the approach, so I am in the process of testing it out on my projects. A notable use-case there is storing encrypted files at rest.

IMPORTANT: Im not trying to promote “yet another ui framework”, this is an investigation to see what is possible. You should not use this in your own code. It is not reviewed, audited or production-ready. It is not on npm. Shared for testing, feedback and demo purposes only.

TLDR; The title of this post.

Feel free to reach out for clarity instead of reading the code/docs.

I was working on a “react-like syntax for webcomponents”, I wanted to create something robust and flexible for secure data storage and management.

I started off with an approach for asynchronous state management so that components outside the shadow-root could receive updates. (The events are also encrypted to secure against things like browser extensions.)

https://positive-intentions.com/docs/projects/dim/async-state-management

It then made sense to be able to persist that data so it can work between page releoads.

https://positive-intentions.com/docs/projects/dim/bottom-up-storage

The result looks and works like the following when used in a project.

https://positive-intentions.com/docs/projects/dim/encrypted-store

The Dim framework seems like a dead-end. I wanted to try it out on my existing React projects. So I created the equivalent React hooks.

https://positive-intentions.com/docs/projects/dim/use-dim-store-react

I find it to be performant and I want to push the scale of the approach, so I am in the process of testing it out on my projects. A notable use-case there is storing encrypted files at rest.

IMPORTANT: Im not trying to promote “yet another ui framework”, this is an investigation to see what is possible. You should not use this in your own code. It is not reviewed, audited or production-ready. It is not on npm. Shared for testing, feedback and demo purposes only.

TLDR; The title of this post.

Feel free to reach out for clarity instead of reading the code/docs.

I was working on a “react-like syntax for webcomponents”, I wanted to create something robust and flexible for secure data storage and management.

I started off with an approach for asynchronous state management so that components outside the shadow-root could receive updates. (The events are also encrypted to secure against things like browser extensions.)

https://positive-intentions.com/docs/projects/dim/async-state-management

It then made sense to be able to persist that data so it can work between page releoads.

https://positive-intentions.com/docs/projects/dim/bottom-up-storage

The result looks and works like the following when used in a project.

https://positive-intentions.com/docs/projects/dim/encrypted-store

The Dim framework seems like a dead-end. I wanted to try it out on my existing React projects. So I created the equivalent React hooks.

https://positive-intentions.com/docs/projects/dim/use-dim-store-react

I find it to be performant and I want to push the scale of the approach, so I am in the process of testing it out on my projects. A notable use-case there is storing encrypted files at rest.

IMPORTANT: Im not trying to promote “yet another ui framework”, this is an investigation to see what is possible. You should not use this in your own code. It is not reviewed, audited or production-ready. It is not on npm. Shared for testing, feedback and demo purposes only.

By leveraging FileSystem API for browser-based file-management, we can create a fairly unique approach for interacting with files on your device from your browser.

Features:

• PWA
• Local-first
• Word
• Spreadsheet
• PDF

Coming soon:

• Support for more filtypes
• Storage sync
• Collaborative editing
• Encryption at rest
• P2P file-transfer

*** 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 Microsoft Office. This is intended to demonstrate client-side managed functionality. Allowing users to get started without setup.

I have a demo version for testing. It isnt ready to replace any existing app or service, but it would be great to get your feedback on it.

The implementation is based on the functionality described in a previous post.

By leveraging WebCrypto API and FileSystem API for browser-based encryption, we can create a fairly unique approach for encrypting and storing files directly on your device from your browser.

*** 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 veracrypt. This is intended to demonstrate client-side managed secure cryptography. Allowing users to get started without setup.

i have a demo version for testing. it isnt ready to replace any existing app or service, but its a work-in-progress and it would be great to get your feedback on it.

the implementation is based on the functionality described in a previous post.

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.

IMPORTANT: While this is aiming to provide a secure implementation, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.

Its worth mentioning that its far from finished and i hope with feedback i can make it better. I have put efforts towards directing it towards unit-tests, an audit and formal-proofs. None of that is good-enough, but i hope it can act as a starting point for verifying the implementation is correct.

Im sure people have better things to do with their time than review unstable and unfinished code. The transparency is intended for professionals that may be curious... Feel free to reach out for clarity instead of reading the code/docs.