Skip to content

id: design: permission UX — Play Store-style prompts, client-side vs server-side disclosure, admin grant modes #5960

New issue
New issue
Open
Open
id: design: permission UX — Play Store-style prompts, client-side vs server-side disclosure, admin grant modes#5960
Assignees
dezren39
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)kind/designA design proposal (design-architect): multi-step, phased, decision-bearingpriority/normalOrdinary priority (the default)status/triagedTriaged and routed (see agent note)task/triageQueue packet kind: verify, reproduce, and route this item

Description

@dezren39
dezren39
opened on Nov 5, 2026

Part of the worlds design program: #5955. Statements S19–S23 of the 2026-11-04 brief.

Requirement (Drew, in substance)

Design the permission system for worlds — at least in the user-friendly examples and main interfaces, a simple version of what the Play Store does: before you connect, it tells you what the thing can do.

  • The disclosure must distinguish whose capability is exercised: "this app connects to the internet using your client" is a different sentence from "this app reads things from the internet through the server side." Client-side and server-side capabilities are presented as separate lines, because they implicate different parties.
  • Granting server-side capabilities is a server admin decision.
  • Admin grant modes to support: approve generally; ignore for all time for specific websites; ignore for specific permissions; YOLO mode — don't worry about anything.
  • The client-side analog (per-user memory of grants) should mirror the same shape: ask once, remember per world / per permission / globally, with YOLO as an explicit user choice, not a default.

Design points to settle

  • Prompt content: the requested set and the discovered-used set (capability-model child of #5955) — show both when they differ ("asks for X, only uses Y").
  • When prompts fire: first connect, capability change (see the change-notices child), never on an unchanged reconnect for a remembered grant.
  • What a denial does: world still loads with the denied capability inert, or connection refused? Per-capability granularity implies the former is possible — say which capabilities are load-bearing.
  • YOLO mode scoping: per-server, per-user, time-boxed? It must be loud in the UI that it's on.

Related

  • Knowledge-layer sharing & permissions (different layer, same vocabulary problem): #5840
  • Capability-change notices and permission precedents research: children of #5955

Done looks like

A UX design: prompt mock/content spec for client-side and server-side grants, the admin grant-mode matrix, memory/remembering rules, and denial semantics.

Activity

  1. dezren39
    added
    status/needs-triageNot yet triaged; needs a first look
    priority/normalOrdinary priority (the default)
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    kind/designA design proposal (design-architect): multi-step, phased, decision-bearing
    on Nov 5, 2026

  2. developing-today commented on Nov 5, 2026

    @developing-today
    developing-todayBot
    on Nov 5, 2026 – with developing.today
    Contributor

    CODE-1626

  3. dezren39 commented on Nov 5, 2026

    @dezren39
    dezren39
    on Nov 5, 2026
    MemberAuthor

    Wave-2 tie-in (conversation archaeology, findings F4 + F9) — the engine exists; this is its presentation layer.

    • Drew settled the substrate question on 2026-10-09: ACL-vs-OCAP was asked explicitly, and the capability/delegation side won. The group/permission system shipped in Phases 0–8 (permission sets for anonymous/registered/confirmed groups; access/read, manage/write, admin levels). What never got built is the user-facing Play-Store-style presentation — this design is that layer over the existing engine, scoped to UX + admin policy presets, not a new engine.
    • Hard constraint (F9, settled and built 2026-10-29 on #170, implemented in pkgs/id/src/groups/delegation.rs): delegation is attenuate-only and never amplifies; revoke cascades by reachability; no function values inside the replicated log — removals resolve pre-emission with the concrete mode logged, because every peer folds the log identically. Any function-valued permission or grant in this UX must respect the pre-emission rule. Do not re-derive these semantics.

    Record: workspace/scratch/worlds-capabilities-brief-2026-11-04/conversation-tie-ins.md (F4, F9).

  4. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 5, 2026
  5. github-actions
    assigned
    dezren39
    on Nov 5, 2026
  6. developing-today
    added
    work/assignedQueue worker lifecycle state
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    status/needs-triageNot yet triaged; needs a first look
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 5, 2026

  7. developing-today commented on Nov 5, 2026

    @developing-today
    developing-todayBot
    on Nov 5, 2026 – with developing.today
    Contributor

    🤖 Agent note · handed off

  8. 1 remaining item

  9. dezren39
    added
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    on Nov 5, 2026

  10. dezren39 commented on Nov 5, 2026

    @dezren39
    dezren39
    on Nov 5, 2026
    MemberAuthor

    🤖 Agent note · handed off

  11. dezren39
    added
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 5, 2026

  12. dezren39 commented on Nov 5, 2026

    @dezren39
    dezren39
    on Nov 5, 2026
    MemberAuthor

    Agent note · picked up

  13. dezren39
    added
    status/triagedTriaged and routed (see agent note)
    and removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 5, 2026

  14. dezren39 commented on Nov 5, 2026

    @dezren39
    dezren39
    on Nov 5, 2026
    MemberAuthor

    Triage — task 10329 (2026-11-05)

    Verdict: #5960 is a valid, still-open V2 UX design work item. Keep it open for the design; do not implement or replace the permission engine here.

    Fresh verification: #5960 is OPEN with no hard-stop labels and no matching open PR. Parent #5955 is OPEN and maps permission UX as its own V2 child. Current main is b830347c2a5398ef5a1846e6ee4a424e9793bd93; pkgs/id/src/groups/delegation.rs already models attenuating grants. The issue’s existing F9 note records the settled pre-emission rule (no function values in the replicated log); #170 is CLOSED. No existing Play-Store-style UX design was found in the searched pkgs/ and doc/ paths.

    Scope and inputs: keep this at the user-facing prompt / policy layer over existing capability and grant machinery. Distinguish client-side from server-side capabilities; server-side grants are an admin decision. Design requested-vs-discovered-used disclosure against #5958; align first-connect and changed-capability prompts with #5959 (including no prompt on unchanged remembered reconnect); use #5961’s platform-precedent research to ground grant memory and modes. The denial behavior, requested/used presentation, remember scopes, admin mode matrix, and YOLO scope/loudness remain decisions for the design, not triage blockers.

    Ordering: #5958 (capability model), #5959 (change notices), and #5961 (precedent research) are all OPEN; #5959 is currently parked. Keep the UX design coordinated with those sibling outputs before freezing the prompt contract. These issues already exist, so no duplicate follow-up task was created. No Drew/access blocker identified.

    Triage complete; #5960 remains OPEN for its design deliverable.

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

Metadata

Metadata

Assignees

Labels

app/idPackage/app: id (pkgs/ or apps/ in this repo)kind/designA design proposal (design-architect): multi-step, phased, decision-bearingpriority/normalOrdinary priority (the default)status/triagedTriaged and routed (see agent note)task/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions