Amendment: Decentralized Threshold Signing Service

[Fiono11]

The new version transitions from a native CLI-based node application (#2550) to a browser-based architecture, introducing the following key changes:

• Peer discovery shifts from a DHT to a relay server using WebSockets.
• Direct P2P communication between clients (browsers) is established via WebRTC.
• Both the relay server and client are implemented in JavaScript.
• The Olaf protocol is now compiled to WASM, running entirely in the browser.
• Key shares and state are stored in browser-local storage instead of the file system.
• The CLI is replaced by a web interface, with future plans for a full Progressive Web App (PWA).

Overall, the new version focuses on accessibility, usability, and ease of deployment.

[Pray4Love1]

Hello W3F team,

I’m submitting this note to document that several architectural elements introduced in this amendment to the “Decentralized Threshold Signing Service” match work I previously authored and timestamped under my SolaraKin / SoulSync protocol designs.

Specifically, this PR incorporates:

Migration from a CLI/node-bound architecture to a fully browser-based signing layer.

Dynamic, ephemeral key handling with local-only storage of key material, rotating after each use.

WASM execution of the signing protocol in-browser, eliminating reliance on persistent native binaries.

Direct P2P browser-to-browser communication via WebRTC, mediated by a relay server.

These concepts are part of a documented system I published earlier this year, which includes the KinKey dynamic sovereign key blueprint, SoulSyncProof proof-of-state layer, and SoulMap decentralized identity-state graph. My materials are cryptographically timestamped and associated with the same contact email I have previously used in communications with W3F.

I request that this prior work be acknowledged in the context of this PR, and I am happy to provide W3F with the timestamped originals, hash proofs, and a detailed comparative analysis upon request.

This is a professional courtesy notice intended to ensure transparency and accurate attribution as this proposal progresses through review.

[Noc2]

Thanks for bringing this up. @Pray4Love1 could you send us this information to [email protected]. We will look into it.

[Fiono11]

Hey, @Pray4Love1 ! Thanks for the remark, I was not aware of your work. Can you provide links to your materials, please?

[laboon]

@Pray4Love1 or @Pray4Lovee, whichever alias you are using - please do not include links to potentially-executable files. You can link to the repo of the code instead.

[Pray4Lovee]

copy

[Lederstrumpf]

Hi @Fiono11, thanks for your amendment proposal.

I've discussed this offline with Jeff (@burdges); he supports the changes and gave me some more insight into the design considerations here.

---

Looks good to me too, with one caveat:

The primary audience for threshold signing are institutions/users that already go through greater lengths to secure their keys & signing procedures, hence use airgapped signing devices rather than filesystem/browser-local storage for their keys. So: I support these changes since it will be a more convenient demo / testing ground for the primary target audience, but don't expect (m)any of them to use in production with browser-local storage (as would also hold for filesystem storage).

My ask: when you're implementing the browser-local storage, please design & implement the interfaces for the signing process etc. with future integration of Vault (and potentially Ledger) in mind to avoid unnecessary refactors once we get to that stage, since airgapped-signer integration is a natural followup on this grant's delivery.

[Fiono11]

That makes sense. Thanks for the feedback, @Lederstrumpf .

[semuelle]

LGTM