Optionally signing peer Ids & their changes, and being able to reject failing changes at merge/when re-materializing state

[lee-orr]

I'm wondering if you'd be open to allowing adding hooks of signing & verifying changes by peer id, as well as allowing you to reject changes that don't verify properly. I don't think Loro itself should implement the singing and verification, but having an interface that allows something like (mock interface using typescript):

SignatureMetadata = { signature: Uint8Array, hash: Uint8Array }
SignedChange = Change & SignatureMetadata
// added to the LoroDoc 
{
setIdentityMetadata?: <IdentityMetadata: object>(meta: IdentityMetadata) => void // assigns the identity metadata to the current peer
signLocalOps?: (current: Change, previous: SignedChange) => SignatureMetadata,
verifyIncomingOps?: (peer: {id: number, meta: IdentityMetadata}, incoming: SignedChange, previous: SignedChange) => boolean | {modified: Change}
}

should let folks wanting to add extra validation do things like:

• add identifying info to the current peer
• user hashes current op w/ last ops hash (with their hash algorithm of choice), and signs the resulting hash.
• any connected peers get the signatures as they come in
• you only need to store the most recent signature - since you can always re-verify by looking at the chain of op hashes. If you shallow-snapshot, add a stub with the hash of the newest removed op
• for verification, a false can try to ignore that change, while a modification can be used to let you highlight "this was done by an invalid user" - for example if you want to enable manual resolution of changes made concurrently to a user's access to the document being revoked while leaving the door open of a future merge to make the change valid.

I realize I could implement something like this myself by exporting JSON changes, filtering/modifying them, storing them separately and importing into a new document. But if I do that I lost the capacity to optimize storage or integrate more tightly with the underlying CRDT.

The other feature request I suggested (custom crdts/append only log) would enable doing this for a subset of data without needing additional intervention, but not for the entire document.

(I am happy to try implementing this - but I'm uncertain if there are challenges I don't foresee in the filtering/modifying of incoming operations, so this is framed more as a request to you than an offer to add this feature myself)