Ipfs Design

Design an owned-node IPFS adapter

IPFS through an owned or configured node is a possible storage adapter, not a currently qualified EdgeORE feature. It provides content-addressed storage and retrieval primitives. A content identifier does not guarantee indefinite retention, confidentiality, availability or payment. Designing the adapter begins by separating these properties so the interface never turns Upload complete into a permanent-backup promise.

Define the trust boundary

The phone should encrypt a file before sending it to a node that does not need plaintext. Identify who holds the decryption key, how the key can be recovered and whether another device can restore the content. The local Keystore vault's device-bound key is not automatically a portable backup key. A distributed-storage design therefore needs a distinct recoverability policy, not a silent reuse of the existing envelope.

Configure a node the operator controls and authenticate the API path. Do not expose an unrestricted IPFS administration API to the public internet. An allowlisted gateway or tightly scoped service can provide narrower behavior than direct arbitrary API access. The app should know which endpoint receives ciphertext and which authority can remove pins or view metadata.

Separate add, pin and retrieve

Adding bytes yields a content-addressed result, but retention depends on pinning and node policy. Record the identifier, encrypted length, encoding or chunking policy and acknowledgement. A pin acknowledgement is a provider claim about retention at that time. A retrieval test checks that the requested bytes are available now. Neither proves independent replicas or a long-term service-level agreement by itself.

Fetch ciphertext under strict byte limits, verify its expected identifier or digest and authenticate its encryption before releasing plaintext. Handle missing blocks, a stopped node and an incorrect object as different failures. Never replace a failed retrieval with an empty file that looks successful. If a user chose a different node or gateway, record that change so the recovery path remains auditable.

Plan deletion and metadata

Unpinning from one node does not guarantee every other peer deletes a copy. Public content addressing and provider records can reveal metadata. Encryption protects content under a key, but file size, request timing and identifiers may still disclose patterns. Document the limits before advertising deletion or anonymity. Convergent encryption has additional guessability considerations for low-entropy files and should not be marketed as automatically extremely secure.

A customer-funded service would need a retention period, capacity reservation, retrieval deadline, challenge rules and evaluator authority. Those are beyond the IPFS add API. Fees, settlement and disputes must be designed separately on Solana if the product later pays SOL. A stored CID is not a receipt of payment or proof of useful contribution.

Build a first bounded prototype

Keep the adapter on a feature branch. Start with a small non-sensitive file, an owned node, client-side encryption, upload acknowledgement and a clean restore on another authorized environment. Preserve hashes and explain key recovery. Then test node outage and pin removal. Only after these results should the site call it an implemented adapter. Until then, IPFS storage — planned is an accurate capability label.

---

Wiki home · Qualification updates · Sources and credits