Signal Protocol for a P2P Webapp

TL;DR: I have open-sourced a #Rust implementation of the #SignalProtocol that compiles to #WASM for #Browser-based #P2P messaging, overcoming the #NodeJS limitations of the official library.

I am sharing my implementation of the Signal Protocol designed specifically for the #Frontend. While the official libsignal is the gold standard, its #JavaScript targets are often optimized for Node.js, which creates integration challenges for client-side web applications.

My version is built in #RustLang and compiles to #WebAssembly, utilizing #ModuleFederation to provide robust #Encryption for decentralized environments. It currently powers the end-to-end security for my #P2P messaging project.

Protocol Demo:
https://signal.positive-intentions.com/

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

I am looking for feedback from the #Dev and #Infosec community. If you have experience with #Cryptography audits or formal-proof verification, I would appreciate your eyes on the codebase as I work toward a more finished state.

GitHub Repository:
https://github.com/positive-intentions/signal-protocol

#Signal #SignalProtocol #Rust #RustLang #WASM #WebAssembly #OpenSource #OSS #Privacy #Encryption #E2EE #WebDev #Frontend #BrowserTech #Decentralized #WebApps #Coding #Security #SoftwareEngineering #Networking #PeerToPeer #P2P #Cryptography #Audit #CyberSecurity #Tech #JavaScript #Programming #ModuleFederation #P2PWeb #PrivacyTech #SecureMessaging #WebPerf #TechCommunity #InfoSec #WebSecurity

@xoron Does it have to be compiled to WASM?

@khleedril

fraid so. i would prefer to avoid it, but it seemed nessesary. i had an older version of it that was using the js primitives from the browser, but the issue there was that crypto primitives were not always provided by the browsers and different browsers have their only roadmap for supporting it.

so rust to wasm was a reliable way to get the crypto primitives needed. that was how it was done on several other projects including the official signal one.

@xoron Yes I understand that, I was more wondering if it couldn't have been a more general library which could compile to x86 or ARM?

@khleedril

i havent considered those compile targets. i supose it could be done. is there not something already out there? my version is created specifically for the browser environment.

i think it would be better to start off with the official version and take it from there.

https://github.com/signalapp/libsignal

GitHub - signalapp/libsignal: Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible.

Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible. - signalapp/libsignal

GitHub
@xoron @khleedril I think I need to look at this. I work on Go, me + 3 others are working on SIMD extensions, we are aiming for platform-independent naming (across the common subset, plus high-value emulations). Amd64 is experimental in 1.26, WASM is mostly done, arm64 is early days and about to receive a lot of attention. So, "can we support Signal?" is a notable use case.

@xoron @khleedril

Perhaps useful, so just bringing it up. The #Makepad team are in their presentations always particularly proud in how they make #Rust builds in mere seconds across the full range of compile targets. They make builds after live coding *during* the presentation. Perhaps some of their methods to achieve this are applicable for you. Other than that, watching a recent Makepad presentation is inspiring, as their project is an impressive feat.

https://makepad.nl/

Btw, #Robrius uses Makepad and perhaps has similar approach to compiles, idk really. It is another cool initiative, who build #Robrix a matrix client with their app framework.

https://robius.rs/

Makepad

Blazingly fast cross platform Rust UIs. Makepad is an in development shader based live designable OSS UI-Framework.

@xoron @khleedril

Other than that, some musings..

Your project looks very nice. Kudos! However, the past couple years I've probably seen a quadrillion instant messenger projects pass by. The screenshot on the website is "yet another familiar IM chat UI".

But if I just read your tagline of "Decentralized #P2P encrypted messaging" and I close my eyes a bit, I can picture 'universal messaging' and see something very powerful.

In #ActivityPub conceptual architecture this exists in theory, but the #fediverse diverges from that. In #XMPP and #Matrix protocol realms you hear people say "you can build any social networking use case with the protocol", but then all the documentation and discussions relate narrowly to IM and some of the hardwired abstractions assume IM (like Room in matrix).

With universal messaging I might be empowered with https://eventmodeling.org and https://eventcatalog.dev like solution design, using SDK's on top of a robust p2p protocol component. To model IM and more.

Event Modeling Introduction

Event Modeling can be applied in designing systems that will store state in traditional databases. By providing a more thorough design, the solution can be implemented with a lot less waste that usually comes in the form of having to re-visit finished items as the solution is built up.