Skip to content

id: design: server-side invariants — tick/session/gas/disk bounds, budget observability, platform exploit resistance #5962

Closed

Description

@dezren39

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

Requirement (Drew, in substance)

Our side of the bargain is narrow, and it is the whole safety story:

  • Ticks, sessions, or gas stay below a certain amount. Budgets are platform-enforced, not author-promised.
  • The platform side is solid — it can't be exploited to do more than it's meant to. The capability ceiling is a security boundary, not a convention.
  • Users are aware of what could be done. Awareness (registry listing, permission prompts) is a load-bearing part of the model, not decoration.
  • Within those bounds — disk size and the rest — users can pull whatever libraries they want. No additional gatekeeping is implied by this design.

Design points to settle

  • The budget vocabulary: per-tick gas, per-session totals, per-world aggregate, disk quota per world / per user / per library cache. Which are hard kills, which are throttles, which are bills (see the compile-economics child of #5955)?
  • Observability: what does a world author / server admin see when a budget trips — and what does the user whose function tripped it see? (The brief's program framing names observability as a first-class axis.)
  • Exploit-resistance review surface: enumerate the platform functions as an attack surface; for each, what bounds it (path sandboxing, network egress rules, allocation limits). This is the checklist the "can't be exploited" claim will be audited against.
  • Failure containment: a world that blows its budget must not degrade co-resident worlds on the same server.

Related

  • Per-function gas/timeout research child of #5955
  • Writer-set authority (adjacent boundary): #5545
  • Sandbox implementation today: pkgs/id/src/sandbox.rs; capability catalog pkgs/id/crates/id-core/src/world_caps.rs

Done looks like

A design doc: the budget set with enforcement semantics, the observability surface for each budget, and the platform attack-surface checklist.

Activity

  1. added
    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
    Contributor
  3. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Ruling — C2 capability posture, server-invariant implications (Drew, 2026-11-04 23:57 CST; primary record on #5958).

    Correction to the program's earlier working interpretation: the brief does not supersede the shipped default. The completely isolated seccomp policy (no fs open, no sockets) remains the default and is a standing invariant for server design.

    What changes is additive: an opt-in file+network capability tier is to be investigated/built, with these invariant-level constraints — capabilities off by default on servers; publishing of worlds using them is first-party only for now; the mechanism must be built so it could be enabled for anyone later, with general enablement gated on testing and refining how the platform wrangles and controls such capabilities. Invariant/bounds design here should cover containment for that tier when enabled, without weakening the default isolation.

  4. added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 5, 2026
  5. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · triaged — task 10331 (queue repo-health-code-pilot, lane code-f)

  6. 99 remaining items

  7. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue 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
    queue/queuedHas a queued task in the Supabase agent queue
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    queue/claimedQueue worker lifecycle state
    on Nov 9, 2026
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)queue/parkedQueue task is parked (waiting on CI, time, or an event)status/parkedDeliberately paused with a recorded resume conditionstatus/triagedTriaged and routed (see agent note)status:donetask/small-fixQueue packet kind: bounded fix with reproduction and targeted testswork/assignedQueue worker lifecycle state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions