Skip to content

docs(protected-content): mint→sell→buy→play journey implementation plan - #22

Closed
andersalm wants to merge 1 commit into
feat/protected-content-custody-providerfrom
cursor/protected-content-journey-plan-af9e
Closed

andersalm wants to merge 1 commit into
feat/protected-content-custody-providerfrom
cursor/protected-content-journey-plan-af9e

Conversation

@andersalm

Copy link
Copy Markdown
Contributor

What this is

A proposal-stage implementation plan to take the canonical protected-content extraction (feat/protected-content-*) from a trust-core foundation to the full end-to-end user journey — mint → sell → buy → play — with first-class design and UI/UX, coherent with PRINCIPLES.md and the canonical architecture in docs/PROTECTED_CONTENT.md.

Base is set to feat/protected-content-custody-provider so the diff is just the new doc (docs/PROTECTED_CONTENT_JOURNEY_PLAN.md).

Highlights

  • Vision alignment as an explicit contract: every stage is mapped to a specific PRINCIPLES.md rule (local-first, no ambient authority, one canonical path, fail-closed, UI-is-not-authority, design tokens, human nouns, trust-travels-with-signed-content). If a design choice can't be expressed as one of those, it's out of scope.
  • Reuses the canonical spine: capsule → Runtime coordinator → rights-provider → custody providers → decrypt-provider, on the existing elastos-protected-content-* crates + custody-provider.
  • Stage-by-stage design (Create/mint, Store/sell, Buy, Play) with the UI surface, Runtime seam, providers, authority/security, and object model for each.
  • UI/UX is the primary focus: _shared design tokens, home-gui canonical window chrome, one consolidated Store, the Home spend-confirmation dialog ("what is displayed is what is signed"), human-noun IA, and a full states/copy/accessibility pass.
  • Names the hard blocker: schedules the RequiredHomeLaunchToken subject-resolution rewire (PR dKMS/dDRM foundation on the ESP substrate (inspired from flint-5.0) #15's parked gate) into Phase 2 rather than deferring it.
  • Reuse/re-derive/reject disposition vs PR dKMS/dDRM foundation on the ESP substrate (inspired from flint-5.0) #15, consistent with the existing "PR dKMS/dDRM foundation on the ESP substrate (inspired from flint-5.0) #15 disposition" in docs/PROTECTED_CONTENT.md.
  • Phased sequencing (dev-lane vertical slice first, then chain-gated buy, then session hardening, then polish, then atomic cutover) with a behavioral-oracle acceptance based on adapting PR dKMS/dDRM foundation on the ESP substrate (inspired from flint-5.0) #15's dkms_rail e2e, plus a merge-gate coherence checklist.

Note

This is a planning document only — no code changes. It's written to be reviewed/edited on the protected-content line; open decisions (Store consolidation, product vocabulary, dev-lane vs chain-gated scope for 0.7) are called out in §10.

Open in Web Open in Cursor 

…n plan

Vision-aligned end-to-end plan (design + UI/UX) to take the canonical protected-content extraction from trust-core foundation to the full mint->sell->buy->play journey on the ESP substrate.

Co-authored-by: Anders <andersalm@users.noreply.github.com>
@irzhywau

irzhywau commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

closed this, it have been merged in upstream/0.7.1-dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants