The VisionFlow ecosystem deploys Solid pods across four deployment tiers, each with different capability envelopes. This document is the single reference for what works where.
| Capability | CF Workers | Embedded agentbox | Native server | Git-capable |
|---|---|---|---|---|
| Protocol | ||||
| LDP (Basic Containers) | Y | Y | Y | Y |
| Content negotiation (Turtle, JSON-LD, N-Triples) | Y | Y | Y | Y |
| PATCH (N3, SPARQL-Update, JSON Patch) | Y | Y | Y | Y |
| Conditional requests (ETag, If-Match) | Y | Y | Y | Y |
| Container creation via PUT | Y | Y | Y | Y |
| HTTP COPY | Y | Y | Y | Y |
Glob GET (/folder/*) |
Y | Y | Y | Y |
| Range requests (RFC 7233) | -- | Y | Y | Y |
.meta sidecars |
Y | Y | Y | Y |
| Access Control | ||||
| WAC (full spec) | Y | Y | Y | Y |
acl:agent / acl:agentClass / acl:agentGroup |
Y | Y | Y | Y |
acl:default inheritance |
Y | Y | Y | Y |
acl:origin enforcement |
-- | Y | Y | Y |
| WAC 2.0 conditions | -- | Y | Y | Y |
WAC-Allow header on 403 |
Y | Y | Y | Y |
| PaymentCondition (HTTP 402 Web Ledgers) | -- | -- | Y | Y |
| Identity and Auth | ||||
| NIP-98 (Schnorr/secp256k1) | Y | Y | Y | Y |
did:nostr resolution (Tier 1 + Tier 3) |
Y | Y | Y | Y |
| Solid-OIDC + DPoP | -- | Y | Y | Y |
WebID cross-verification (alsoKnownAs) |
Y | Y | Y | Y |
| WebAuthn passkeys | -- | -- | Y | Y |
| Schnorr SSO (NIP-07) | -- | -- | Y | Y |
did:key support |
-- | -- | Y | Y |
Embedded identity provider (solid-pod-rs-idp) |
-- | -- | Y | Y |
| Notifications | ||||
| WebSocketChannel2023 (Solid Notifications 0.2) | -- | Y | Y | Y |
| WebhookChannel2023 (RFC 9421 signed) | -- | Y | Y | Y |
Legacy solid-0.1 WebSocket |
-- | Y | Y | Y |
Updates-Via header |
-- | Y | Y | Y |
| Federation | ||||
| ActivityPub (inbox/outbox, HTTP Signatures) | -- | -- | Y | Y |
/.well-known/apps (JSS #464) |
-- | -- | Y | Y |
| NIP-05 pod-resident endpoint | -- | -- | Y | Y |
| Git | ||||
| Git auto-init at provisioning | -- | -- | -- | Y |
| Git HTTP smart transport (clone/push/pull) | -- | -- | -- | Y |
| Pods as app repositories | -- | -- | -- | Y |
| Admin and Operations | ||||
| CORS allowlist | -- | -- | Y | Y |
PSK admin provisioning (/_admin/provision) |
-- | -- | Y | Y |
| Cohort-based access control | -- | -- | Y | Y |
Per-pod storage quota (.quota.json) |
-- | Y | Y | Y |
| Rate limiting | Y (CF) | -- | Y | Y |
| Webhook signing (RFC 9421 Ed25519) | -- | Y | Y | Y |
| SSRF guard (private IP, DNS rebinding) | -- | Y | Y | Y |
| Path traversal guard | -- | Y | Y | Y |
| Observability (spans, logs, metrics) | CF analytics | Y | Y | Y |
| Storage Backend | ||||
| Cloudflare R2 | Y | -- | -- | -- |
| Workers KV | Y | -- | -- | -- |
Host filesystem (fs-backend) |
-- | Y | Y | Y |
In-memory (memory-backend) |
-- | Y | Y | Y |
S3-compatible (s3-backend) |
-- | -- | Y | Y |
Custom backend (implement Storage trait) |
-- | -- | Y | Y |
Legend: Y = supported, -- = not available.
Cloudflare Workers compile to wasm32-unknown-unknown. The runtime has:
- No
tokio::process-- cannot spawn subprocesses (nogit init, no CGI). - No native filesystem -- storage is R2 (object store) and KV (key-value), not POSIX.
- No Tokio runtime -- async is handled by the Workers runtime, not by Tokio.
- 30-second CPU budget -- hostile to expensive operations like packfile generation.
These constraints are structural, not configuration gaps. ADR-087 documents the wasm32/Tokio wall; ADR-089 documents the git-specific unavailability.
Moving a user's pod from the CF Workers tier to the native (or git-capable) tier is an admin-driven process, not a self-service operation.
- A running
solid-pod-rs-serverinstance (with--features gitif git is needed). - A Cloudflare Tunnel or equivalent TLS termination exposing the native server.
- PSK admin key shared between the auth-worker and the native server.
- User's cohort added to the
allowlist_cohortsindreamlab.toml.
-
Provision the native pod. Admin triggers
POST /api/native-pod/provisionvia the admin panel. The auth-worker forwards to the native server's/_admin/provision/{pubkey}with the PSK header. The server creates the pod directory, writes a WAC.aclgranting the pubkey owner access, and runsgit init -b main. -
Export data from CF tier. Use the R2 API or
wrangler r2 object getto download all objects under the user's R2 prefix ({pubkey}/). Each object maps to an LDP resource. -
Import data to native tier.
PUTeach resource to the native pod URL using NIP-98 auth. ACL sidecars must be transferred separately. If the native pod is git-enabled, each PUT creates a commit. -
Update WebID. The user's WebID profile card must update
pod_base_urlfrom the CF pod URL to the native pod URL. Verifiers following the WebID will then resolve to the native tier. -
Decommission CF pod (optional). Remove or tombstone the R2 prefix. The pod-worker will return 404 for that pubkey.
- There is no automated bulk migration tool today. Each resource must be individually PUT to the native tier.
- Git history starts fresh at migration time. The CF tier has no version history to carry over.
- NIP-05 resolution may need reconfiguration if the user's name was registered
in the forum's D1/KV store and the native pod now serves its own
/.well-known/nostr.json(see ADR-086).
Both tiers use NIP-98 Schnorr signatures for authentication. The signature is self-contained -- it covers the URL, HTTP method, and optional body hash. Each tier verifies independently from the same secp256k1 pubkey. No token exchange, no shared session store, and no cross-tier RPC is required (ADR-093 section 2.2).
The same passkey-derived private key signs requests to both tiers. From the user's perspective, authentication is seamless across tiers.
- solid-pod-rs README -- full crate documentation and feature list
- ADR-087 -- CF Workers portable cores (wasm32/Tokio gap)
- ADR-089 -- Git-pods unavailability on CF Workers
- ADR-093 -- Native pod mesh: hybrid two-tier architecture
- ADR-086 -- NIP-05 pod federation
- agentbox.toml -- pod adapter and git configuration