Why it matters
Signed issue events gives ForkMesh a concrete mechanism for issue activity that can be verified no matter which node served it. Every issue open, comment, edit, and close is a signed event. Authorship is verifiable no matter which node, or which mirror, served you the data.
Collaboration data becomes fragile when issues, reviews, and authorship only exist inside one hosted database. In ForkMesh, signed issue events 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 issue events 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: Every issue open, comment, edit, and close is a signed event. Authorship is verifiable no matter which node, or which mirror, served you the data. Mirrors can verify provenance before accepting or displaying collaboration records.
Where it fits
Use signed issue events when project context needs to survive migrations, forks, offline work, and mirror failover.
It pairs with the rest of Signed, portable collaboration because Signed issue events keeps issue activity that can be verified no matter which node served it connected to the repository, its signatures, and the nodes that serve it.