Self-hosted (Tier 2) publishing to Bluesky doesn't work off the loopback origin

[jpdevries]

Summary

Share to Bluesky (shipped in v0.5.0, #33) renders on the self-hosted Rex app, but a real publish only completes when the instance is reached at http://127.0.0.1:3000. A self-hoster hitting their box at its real address (LAN IP, Tailscale hostname, a reverse-proxied domain) can't complete OAuth sign-in.

Why

The publish feature is entirely client-side (browser → PDS); the Rust backend is not involved. The OAuth client_id is chosen by origin in packages/shared/src/contexts/BlueskyAuth.tsx:

Origin	client_id	Real publish
127.0.0.1 / [::1]	spec loopback client	✅
localhost	— (warns, bails; spec requires 127.0.0.1)	❌
any other origin	falls back to hosted https://pantryhost.app/client-metadata.json	❌ redirect_uri mismatch

The hosted client metadata's redirect_uris list only pantryhost.app / my.pantryhost.app, so the AT authorization server rejects a redirect back to a self-hosted address.

There's a getProdClientId() override, but it only reaches the browser via VITE_ATPROTO_CLIENT_ID at build time (Tier 1's Vite build). The Rex/app path reads process.env.ATPROTO_CLIENT_ID, which Rex does not inline into the client bundle — the same limitation that forced the dry-run flag onto a <meta> channel in _document.tsx.

What it would take (no Rust)

1. A runtime channel so ATPROTO_CLIENT_ID reaches the Rex client — a <meta name="atproto-client-id"> tag in packages/app/pages/_document.tsx, mirroring the atproto-publish-dry-run fix; getProdClientId() reads it browser-side.
2. The self-hoster serves their own client-metadata.json at a public HTTPS URL whose redirect_uris include their instance's callback (AT OAuth requires the client_id to be a publicly-resolvable HTTPS document). Needs docs + ideally a helper to generate the metadata.

Until then, document that self-hosted publishing works via http://127.0.0.1:3000 on the box itself, and defaults to safe dry-run everywhere else.

Related

Cross-device publish-state reconcile: #36

[jpdevries]

Design update — three tracks, one now implemented:

Track C (shipped as #38): hosted-origin publish broker. The self-hosted page opens a popup on my.pantryhost.app/publish-broker, where OAuth works natively. The popup holds the session (tokens/DPoP keys never leave that origin), the user reviews the exact record and confirms inside the popup with the requesting origin displayed, the write goes browser → PDS, and only receipts return (targetOrigin-locked). One request per popup lifetime prevents payload swapping. This unblocks LAN/Tailscale/plain-HTTP self-hosters without credential custody or any Rust changes — at the cost of an availability/trust dependency on the hosted origin.

Why not the alternatives considered: a token hand-off deliberately defeats DPoP key origin-binding and turns the hosted origin into an open token faucet for arbitrary requester origins; a server-side relay requires holding users' write-capable PDS sessions, which SOVEREIGNTY.md rules out.

Track A (open): own-domain OAuth for self-hosters with a public HTTPS front door (reverse proxy, Tailscale Funnel, CF Tunnel) — needs the ATPROTO_CLIENT_ID meta channel in _document.tsx (the dry-run-flag pattern) plus docs for hosting your own client-metadata.json. Fully sovereign; blocked on nothing, just unbuilt.

Track B (open): app passwords for fully-LAN instances — works from any origin (plain XRPC + CORS, no public client needed) but trades away granular scopes and needs a credential-storage decision (client-side is a smell; server-side finally touches Rust).

Recommended posture: C is the default bridge; A documented for the sovereignty-minded; B only if demand shows up.

[jpdevries]

Two-path resolution now complete:

1. Broker (default) — shipped in fix(publish): fetch Bluesky CDN photos via PDS sync.getBlob (CORS) #42/feat(publish): proxy cross-origin recipe photos via feed box #43. Off-loopback origins publish through a my.pantryhost.app/publish-broker popup; the browser still writes to the user's own PDS. Verified end-to-end from a Tailscale origin (real publish + photo blob + unpublish).
2. Sovereign (own OAuth client) — feat(atproto): OAuth sovereignty for self-hosters (own client-metadata.json) #44. A self-hoster serves their own client-metadata.json (with their origin in redirect_uris) and sets ATPROTO_CLIENT_ID; OAuth then completes directly against their instance with no pantryhost.app dependency. This adds the runtime atproto-client-id meta channel prong Show HN post #1 called for, plus a generator + docs (docs/self-hosted-oauth.md) for prong Submit to awesome-selfhosted #2.

App-password path (option B) remains intentionally out of scope — OAuth from day one.

Leaving open until #44 merges.

[jpdevries]

Shipped in v0.7.0 (#44 merged, tagged, deployed to the Mini). Both publish paths are live: the pantryhost.app broker (default, zero-config) and the sovereign own-client-metadata.json path (ATPROTO_CLIENT_ID + docs/self-hosted-oauth.md). App-password path (option B) intentionally out of scope.