Repository navigation
Protected-content UI/UX parity gaps vs feat/dkms-esp-port: protect any file type, Creator app, open-through-decryption #42
Description
Context
While testing the protected-content mint workflow from the product UI on feat/protected-content-uiux-reconstruction (staged Mac source-home, release gateway), three UI/UX capabilities that exist on feat/dkms-esp-port are missing on the candidate line. feat/dkms-esp-port (PR #15) remains the product/test reference for these flows — it is the porting source, not merge material.
Missing parts
1. "Protect and List..." is video-only; it should accept any file type that supports protection
On the current branch the only mint entry point is the Library context-menu action "Protect and List...", gated by isRuntimeCustodyProtectableVideo (capsules/library/browser/src/model.js), which requires mime to start with video/. Images, documents, audio, archives, 3D assets, etc. can never be protected from the UI.
The protection process is practically identical for other content types. On feat/dkms-esp-port the mint flow classifies any input (capsules/creator/browser/creator.js — media vs object, with auto-categories for video, ebook, comic, document/source-code, mirroring the dDRM viewer's type registry) instead of refusing non-video input.
- Widen the protectable predicate beyond
video/*(keep the other gates: own object, unpublished, not already protected, not readonly/trash/directory).
2. No Creator app
feat/dkms-esp-port ships a dedicated Create portal (capsules/creator/ — capsule.json declares elastos.creator.mint / asset.mint): a de-privileged app frame that drives seal + prepare-publish with host-mediated wallet-sign and chain-broadcast, holding no keys, no chain RPC, no wallet. The candidate branch has no capsules/creator at all; the Library context menu is the only (partial) mint surface.
- Port the Creator app onto the canonical runtime-custody boundary (its dkms-era providers — encrypt-provider
seal_inline_threshold, publish-provider — map to today's runtime-custody publish path).
3. Double-click on a protected object should open it through the decryption workflow
On the current branch, opening a protected (.ddrm) object from Library lands on the properties/status box — there is no decrypt-and-render path (capsules/library/browser/src has no viewer routing for protected objects). On feat/dkms-esp-port, Library resolves viewers per object (viewerOptions / openWithViewer in capsules/library/browser/src/app.js) and ships capsules/ddrm-viewer (images/docs/3D via render-IR) plus capsules/elacity-player for protected media.
- Route open (double-click / Open menu) on protected objects into the decryption workflow (viewer selection → decrypt provider → render), with the properties box only as fallback.
Related
- The end-to-end UI mint is currently also blocked server-side:
protected-content/custody-composition.jsonandprotected-content/chain-provider.jsonare only ever provisioned by tests; no setup/staging path writes them into a real home (tracked in the ELACITY-2297 provisioning/boot-reconcile work). The Library action surfaces this as "Protection for is unavailable." - ELACITY-2307 (mint-brick crash window) is in progress on
fix/protected-content-mint-intent-adoption.
Activity
irzhywau commentedon Sep 4, 2026
Augmentation: custody/committee UI-UX + operator workflow coverage
Extending this issue beyond mint/buy/play parity: the ELACITY-2298 installed e2e proof (three custody-host nodes, Carrier dial proofs, offline composition ceremony, preflight receipts — all green) exposed that every custody-recognition step is CLI-only today. Product targets and the workflow features that close them:
4. Any
elastos gatewaycan act as a custody node — enrollment UXThe runtime side already holds:
gateway/serveruns the custody provider in-process, andelastos run custody-provider --with availability-provider --with ipfs-providercovers the standalone case. What's missing is enrollment: a gateway home has no way to export its own custody descriptor and be admitted into someone else's committee.node peer addper node5. Approval ceremony UX — request → approve → custody pool
Forming a committee should be a back-and-forth flow (user B requests custody participation → operators A1..N approve → a signed pool/composition results), not an offline CLI ceremony run by one party holding all descriptors.
capsules/wallet-provider(approval.rs) is the existing product shape to reusedocs/superpowers/specs/2026-07-14-dkms-tofn-pool-custody-design.mdonfeat/dkms-esp-port(pool-DID directory, t-of-n — DRAFT, custody model deliberately open); v1 stays 2-of-3, but the UX should not hardcode 36. CLI-only custody operator — quickstart doc (mandatory)
docs/PROTECTED_CONTENT.mddocuments the command surface, anddeploy/custody-host/proves the flow — but that README is explicitly simulation-only. A bare-metal operator quickstart is the missing piece.docs/quickstart: provision (protected-content-config provision-custody-node) → run (elastos run custody-provider --with availability-provider --with ipfs-provider --carrier-addr) → hand descriptor/ticket to the composer → verify (readiness receipt + dial proof) → resurrection/restart semanticsCurrent convergence (active remote branches, 2026-09-04)
feat/protected-content-installed-provisioning+feat/0.7.1-integration: operator provisioning + ceremony CLI + docs — converging on §6's substrate, nothing UIfeat/protected-content-installed-e2e-proof(local): 3-node harness, dial proofs, ceremony, proof driver — the evidence base these UX layers wrapfeat/dkms-esp-port: porting source for §§1-3 above, plus the pool-custody design spec and wallet approval pattern for §5 — no committee UX implemented anywheredocs(audits): record the protected-content 0.7.1 follow-up plan (#42, #…
fix(protected-content): wiring cleanups for #42 gap 3 and #49
feat(protected-content): the 0.7.1 product surface, from Creator to a…