Browse DIDLab Docs
Storage · IPFS
Store encrypted content with a verifiable CID
DIDLab keeps the public workflow simple: derive encryption locally, publish only ciphertext with a separate wallet authorization, preserve recovery metadata, and use the CID as a content-addressed reference.
01
Encrypt
Browser creates an encrypted payload before upload.
02
Store
IPFS returns a content identifier (CID).
03
Keep recovery data
Preserve the IV, encryption timestamp, and ciphertext digest—never the encryption signature.
04
Retrieve
Gateway serves the encrypted bytes by CID.
Two signatures, two purposes
Encryption authorization
A no-gas wallet signature derives the browser encryption key. It stays in memory and is not uploaded or written into the recovery bundle.
Publish authorization
After encryption, the browser signs the SHA-256 digest and encrypted byte size. The server verifies this separate proof before forwarding ciphertext to Kubo.
Filename privacy
What the CID proves
A CID is derived from content addressing. If the encrypted bytes change, the CID changes. The CID does not reveal a plaintext file when the uploaded payload has already been encrypted.
Recovery responsibility
Blockchain + IPFS pattern
Store large content off-chain and anchor only a compact identifier or digest on-chain. The public DocumentHash example demonstrates this separation.
IPFS
Encrypted file bytes, content addressing, retrieval by CID.
DIDLab chain
Small immutable reference such as a digest, CID string, document ID, event, or timestamped transaction.
Validation profile
Network
DIDLab Blockchain
Chain ID
252501
Client
Hyperledger Besu
Consensus
QBFT
Native asset
TRUST
Platform token
TT (ERC-20)
Solidity examples
0.8.24
Last validated
August 2026
Go deeper in DIDLab Labs
Public documentation explains the workflow and expected result. Authenticated DIDLab Labs adds managed workspaces, deeper exercises, checkpoints, evidence capture, and instructor assessment.
Open DIDLab Labs