โ† All blog posts

Signed collaboration

Ed25519 identity

Nodes and people are identified by local Ed25519 keys. Profiles, catalog records, and every collaboration event carry a signature you can check yourself.

Feature 11 of 72No passwordsSigned, portable collaboration3 min read
Abstract ForkMesh artwork for Ed25519 identity

Why it matters

Ed25519 identity gives ForkMesh a concrete mechanism for local keys that sign people, nodes, catalog records, and collaboration events. Nodes and people are identified by local Ed25519 keys. Profiles, catalog records, and every collaboration event carry a signature you can check yourself.

Collaboration data becomes fragile when issues, reviews, and authorship only exist inside one hosted database. In ForkMesh, Ed25519 identity addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.

How ForkMesh handles it

ForkMesh handles Ed25519 identity through the same split it uses across the product: local identities sign issue events, patch PRs, catalog records, and contribution inbox items before they travel through mirrors.

The behavior is intentionally narrow: Nodes and people are identified by local Ed25519 keys. Profiles, catalog records, and every collaboration event carry a signature you can check yourself. Mirrors can verify provenance before accepting or displaying collaboration records.

Title focus: Ed25519 identity stays tied to local keys that sign people, nodes, catalog records, and collaboration events and the local-first repository model.

Where it fits

Use Ed25519 identity when project context needs to survive migrations, forks, offline work, and mirror failover.

It pairs with the rest of Signed, portable collaboration because Ed25519 identity keeps local keys that sign people, nodes, catalog records, and collaboration events connected to the repository, its signatures, and the nodes that serve it.