Skip to content

Compute placement: headless execution and its E2E consequences; peer-triggered push via subscription-as-capability #12

Description

@lannbot

Decide the compute-placement story and the push design. See NOTES.md — Compute placement and push.

Placement: "one artifact across environments" tempts running app components headless at a provider (always-on sync peer, push generation, agents). The cost stated plainly: a headless host holds plaintext/keys for everything that component is granted. So placement is a powerbox decision surfaced to the user ("run an always-on copy at your provider: it will hold keys to X and Y"), defaulting to user-owned always-on nodes (old laptop, phone runtime) — component-iroh's browser/native/in-guest deployment matrix exists for this.

Push, keeping the origin static: the subscription is a capability. Web Push senders need only the subscription endpoint + VAPID key; hand them (encrypted) to the contact group over the sync layer, and peers wake the service worker directly, payloads E2E on top of RFC 8291. Metadata cost: contacts learn the push endpoint; the push service sees sender IPs.

Open sub-questions:

  • Is headless-at-provider in scope for v1 at all, or browser + user devices only?
  • Who decides to notify: peer-side logic covers peer-triggered events; timers/digests/watches need something always-on — enumerate what v1 actually needs.
  • Subscription-capability rotation (contact removal should stop their ability to wake you).
  • The notification permission model app-side (framework is the OS notification service; apps request through it).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions