Identity and signing
You've seen that a document is its operation log, and that the log is what syncs between peers. That raises a question every collaborative system has to answer: who produced each operation, and can a peer trust it? This lesson connects the operation model you already know to Powerhouse's identity and signing story.
By the end you should be able to explain what a signed operation proves — and what it doesn't.
Operations carry an actor
Every operation already records who dispatched it. In the foundations lesson you saw an operation shaped like this:
{
"index": 42,
"name": "completeTodo",
"input": { "id": "t-1" },
"actor": "user:alice",
"hash": "…"
}
That actor comes from an identity. In Powerhouse, identities are issued
through — a decentralized identity layer, so a
user's identity isn't owned by any single server. When someone connects in
Connect, they authenticate with Renown and every action they dispatch is
attributed to that identity.
A claim is not a proof
An actor field on its own is just a claim. Nothing stops a malicious peer
from writing "actor": "user:alice" onto an operation Alice never made. In a
local-first system where operations flow between machines you don't control,
that's a real problem.
This is where signing comes in. When an operation is signed, the actor's private key produces a signature over the operation's content and position in the log. Any peer can then verify, using the public key, that:
- the operation really came from that identity, and
- it hasn't been altered since it was signed.
Because the signature covers the operation's place in the history, you can't lift a signed operation out of one document and replay it into another — the hash chain won't match.
Three gates, not one
It's worth separating the concerns that all meet at a single operation:
| Gate | Question | Where it lives |
|---|---|---|
| Authentication | Who is this identity? | Renown |
| Signing | Did this identity really produce this exact operation? | Signature verification |
| Authorization | Is this identity allowed to perform this action here? | Document permissions |
| Validity | Is the resulting state legal? | The reducer |
A signed operation can be perfectly authentic and still be rejected — because the signer lacks permission on that document, or because the reducer's rules don't allow the change. Identity establishes trust; it doesn't replace the other checks.
Why this falls out of the operation log
None of this needs a bolt-on audit system. Because state is already an ordered, hash-linked log of operations, attaching a signature to each entry is enough to make the whole history tamper-evident: change any past operation and every signature and hash after it stops verifying. The same structure that gives you deterministic replay and conflict-free sync gives you a trustworthy audit trail for free.