Information confidentiality processing. You can delete this post.
The very nature of a blockchain means that data committed is immutable. That means it is not possible to delete data. It is possible to use a file system layer and encryption that emulates data deletion - burning an encryption key for a file would have the same effect as deletion. There are other clever ways to handle CRUD operations. Think about a Git style method of recording differences between file versions to handle updates for example.
And there are blockchain specific append-only databases which could be useful. Some quick research throws these examples up:
| Project | Append-Only Model | OSS License | How It Could Use Autonomys DSN |
|---|---|---|---|
| immudb (GitHub) | Cryptographic append-only KV/SQL log; Merkle proofs on every write. | Apache-2.0 | Store the immutable log segments or Merkle tree checkpoints in DSN, giving DSN-backed verifiable history. |
| EventStoreDB (GitHub) | Strict append-only event streams; event sourcing DB. | Source-available (ESLv2) | Streams could be persisted in DSN, while Autonomys provides content addressing + redundancy. |
| XTDB (GitHub) | Bitemporal, append-only transaction log; all “updates” are new facts. | MPL-2.0 | Transaction log and document versions could be backed by DSN for immutability + auditability. |
| TerminusDB (GitHub) | Git-for-data model: each commit appends; diffs + revision graph. | AGPL-3.0 | Store commit objects/blobs in DSN, using DSN as the remote repository. |
| Fluree (GitHub) | Ledger-style RDF/graph DB; new blocks of facts only. | AGPL-3.0 | Each ledger block could map directly to DSN storage, with Autonomys providing content permanence. |
| OrbitDB (GitHub) | Append-only logs built with CRDTs on IPFS. | MIT | Swap IPFS layer with Autonomys DSN or bridge DSN as the backing blockstore. |