Signed patch pull requests

Why it matters

Signed patch pull requests gives ForkMesh a concrete mechanism for portable patch submissions with verifiable authorship. PRs are signed records built around a patch. A contributor can submit one without push access, a fork, or even a branch, and the maintainer can verify exactly who sent what.

Collaboration data becomes fragile when issues, reviews, and authorship only exist inside one hosted database. In ForkMesh, signed patch pull requests 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 signed patch pull requests 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 signature covers more than the patch itself: the PR object (title, base, head, and the patch or commit series it carries) is Ed25519-signed as one unit, and every comment and review on it is signed separately and bound to that PR's number, so the whole discussion thread is independently verifiable. When a maintainer merges, ForkMesh does a real git merge whenever there's a resolvable commit to merge into, and only falls back to replaying the stored patch or commit series when there isn't one — e.g. for a patch-only submission with no branch behind it. The accepted PR and its discussion are committed straight into the repository on their own branch, not just logged in a database.

Diagram of the five-step ForkMesh PR flow: 1. Open a PR — a signed record carrying a patch or pointing to a branch. 2. Sign everything — the PR object plus every comment, review, and thread event is Ed25519-signed. 3. Relay = temporary inbox — the relay routes traffic and stages encrypted submissions without permanently storing Git data. 4. Commit into the repo — the PR and discussion are committed onto the repository's forkmesh/pulls branch. 5. Maintainer merges — a real Git merge when possible, a patch fallback when needed. Full mirrors on peers then sync and converge. — How a ForkMesh PR moves from submission to merge: signed at every step, staged (not stored) by the relay, and committed into the repo itself.

Title focus: Signed patch pull requests stays tied to portable patch submissions with verifiable authorship and the local-first repository model.

Where it fits

Use signed patch pull requests when project context needs to survive migrations, forks, offline work, and mirror failover.

It pairs with the rest of Signed, portable collaboration because Signed patch pull requests keeps portable patch submissions with verifiable authorship connected to the repository, its signatures, and the nodes that serve it.