09 — A first-party asset origin
Summary
The maintainer proposed publishing pinned JS and brand assets to a static.sgit.ai site. The pack's answer draws one line: yes to the asset origin — but on S3/CloudFront, not GitHub Pages (Pages stamps max-age=600 on everything, unfit for immutable assets), and only as the publish-time source for bundled assets, never as a read-time origin. Today a published vault makes zero requests to SGit-AI infrastructure — structural, not policy; putting first-party JS on the reader's critical path would make static.sgit.ai a beacon receiving a request from every reader of every vault, joining readership to the operator's logs. At publish time the same mirror is safe and strictly better than a public CDN fetch, because the SRI hash decides and a substituted byte fails closed.
Key concepts
- Prefer the third party who cannot correlate — a CDN learns 'somebody loaded swagger-ui'; a first-party origin joins that to our domains, accounts and hub — a zero-knowledge product cannot operate the beacon every reader pings
- Publish-time source, not read-time origin — the fetch happens once on the publisher's machine, hash-verified — every reader-side concern disappears
- A permanent public commitment — URLs baked into folders on hosts you do not control can never change: append-only, never rewritten, indefinitely — the registry-rules discipline applied to an asset bucket
Key ideas
- The line is drawn by whether the consuming page may hold vault key material — sgit.ai and hub.sgit.ai yes, any published vault folder no.
- 'It's just a logo' is exactly how a first-party origin ends up on every reader's critical path.
- Publish the SRI hash next to every asset, so consumers verify the mirror against upstream instead of trusting it.