Continue reading on Unthread

ahh gotcha. so first, being honest: i don't think a specific threat model drove this. per-doc verification wasn't reverse-engineered from an attack we were trying to stop, it just fell out of how the model came together. so i don't want to overstate it as the reason.

that said, there is at least one concrete case where it does buy you something. if someone steals your atproto creds / app password but not the access to your web server, domain-only verification lets them mint fake docs under your already-verified domain and readers trust them. no 404 catches it, because the record can render directly (some reader that render articles themselves may never hit the live page at all if domain was already "verified"). per-doc verification means the attacker also has to edit the live site to add the backlink, so it's two keys instead of one.

in all honesty this is a narrow attack vector, and probably not worth the whole design on its own. it's more a nice property that came from this vs something the model was built around. the way i'd frame it: domain verification is a one-time trust bootstrap, and per-doc verification just keeps each doc anchored to something the web-server operator controls too.

---

one more thing worth adding: even setting the security case aside, publishers aren't the only party this model has to serve, so the loose-docs and efficiency points aren't just nice-to-haves.

• efficiency (link points to doc → direct fetch, no pub → path → pagination dance) is mostly a reader-app concern, and it shapes how the whole ecosystem consumes docs.
• loose docs matter to authors who aren't a publication at all. (like this unthread) verifying "the pub" doesn't cover a doc that has no pub.

so even if the security argument alone didn't land, the model still has to hold for readers, reader-app devs, and standalone authors, not just the person running the publication.