Integrate holochain-open-dev/file-storage as DigitalAsset CapabilitySlot for NDO content attachments

[TiberiusB]

Why now

NDOs need to carry their content (design files, 3D models, documentation, images) as first-class attachments rather than bare links to external URIs that can rot or be taken down. The NDO Layer 0 identity anchor (NondominiumIdentity) already defines a stigmergic attachment surface via CapabilitySlot links (ndo_prima_materia.md §6). The DigitalAsset slot type is already in the SlotType vocabulary but has no backing implementation. Without it, a Specification-stage NDO (Layer 1) can describe a hardware design but cannot carry its actual CAD files inside the network.

Scope

In scope:

• Add holochain-open-dev/file-storage zomes to the nondominium DNA (chunked upload + retrieval, peer-hosted in DHT)
• Add a DigitalAsset variant to the SlotType enum in zome_resource integrity; target of the capability slot link is the file manifest entry hash produced by file-storage
• Coordinator functions: attach_digital_asset(ndo_hash, manifest_hash) and get_digital_assets(ndo_hash) in zome_resource
• Any NondominiumIdentity entry hash is a valid attachment surface regardless of LifecycleStage (ideation notes, prototype photos, stable design files)
• Basic UI: file upload / download panel on the NDO identity card (Layer 0 view), supporting documents, images, 3D model files, and design files
• Sweettest coverage: attach a file, retrieve it from a second agent

Out of scope:

• Per-file encryption / capability-gated private files (post-MVP, aligns with the PrivatePersonData capability-sharing pattern)
• Digital integrity verification manifests and Merkle-tree chunk proofs (post-MVP, see digital-resource-integrity.md)
• Storage quotas or deduplication
• IPFS, IPNS, or any external (non-DHT) storage backend
• Fabrication queues triggered by file attachment (post-MVP FabricationQueue slot type)

Acceptance criteria

• holochain-open-dev/file-storage integrity + coordinator zomes are wired into nondominium.yaml and compile cleanly in the nix environment
• SlotType::DigitalAsset variant exists in zome_resource integrity; attach_digital_asset creates a CapabilitySlot link from any valid NDO Layer 0 hash to a file-storage manifest hash
• get_digital_assets(ndo_hash) returns all DigitalAsset capability slot links for an NDO, with manifest metadata (filename, size, mime type)
• A file uploaded by agent A can be retrieved (all chunks reassembled) by agent B after DHT consistency; covered by a Sweettest test in dnas/nondominium/tests/src/
• UI: the NDO identity card includes a collapsible asset panel; agents can upload a file and see it appear with name + size; clicking downloads and reassembles chunks
• Existing Sweettest suites pass without regression

Architectural notes

Integration pattern: Add file-storage-integrity and file-storage-coordinator from holochain-open-dev/file-storage as additional zomes in the nondominium DNA (same cell, not a separate DNA). This keeps file chunks peer-hosted on the same DHT as the NDO entries they relate to, avoiding cross-DNA complexity.

Attachment mechanism: Following ndo_prima_materia.md §6.2:

NondominiumIdentity action_hash
  →[LinkType: CapabilitySlot, tag: { slot_type: DigitalAsset, author, attached_at }]
  →  file-storage manifest entry hash

The DigitalAsset slot type is already listed in the SlotType vocabulary table (§6.2). No schema change to NondominiumIdentity is needed: the attachment surface is the DHT link space from the Layer 0 hash.

Farmhack pattern reference: The Farmhack implementation demonstrates attaching chunked file assets to a MOSS Weave context using the same holochain-open-dev library. The key pattern: the file manifest hash is stored as the link target; the manifest contains the chunk count, MIME type, and individual chunk hashes. Retrieval fetches all chunks in parallel and reassembles client-side.

Governance surface: DigitalAsset links follow the same trust tiers as other capability slots (§6.4): links from the NDO initiator or custodians are trusted by default; links from Accountable Agents are conditionally trusted; the governance zome can validate or filter attachments through the existing validate_new_resource pattern.

Related

• Blocks / blocked by: depends on [Epic] NDO Three-Layer Architecture #78 (NDO Layer 0) being complete, specifically [Layer 0] NondominiumIdentity entry type with PropertyRegime and ResourceNature enums #73 + [Layer 0] LifecycleStage enum, update function, and immutability validation #74 so the NondominiumIdentity entry type and CapabilitySlot link type exist
• See also: ndo_prima_materia.md §6 (CapabilitySlot surface), §6.2 (DigitalAsset slot type), digital-resource-integrity.md (post-MVP Merkle integrity layer that builds on top of this)
• Reference implementation: holochain-open-dev/file-storage, Farmhack