From 2a28b7dbf2b341c670beabb923f9e45a5a92104f Mon Sep 17 00:00:00 2001 From: JP Hastings-Spital Date: Fri, 7 Aug 2026 07:45:38 +0100 Subject: [PATCH] chore: beans for did:web self-serve, record endpoints, provide-on-upload --- ...vertise-instance-endpoints-in-devatfsserver.md | 10 ++++++++++ ...idweb-resolution-documents-from-atfs-itself.md | 15 +++++++++++++++ ...announce-new-uploads-to-the-dht-immediately.md | 10 ++++++++++ 3 files changed, 35 insertions(+) create mode 100644 .beans/ATFS-89ku--advertise-instance-endpoints-in-devatfsserver.md create mode 100644 .beans/ATFS-l16z--serve-didweb-resolution-documents-from-atfs-itself.md create mode 100644 .beans/ATFS-zkf8--announce-new-uploads-to-the-dht-immediately.md diff --git a/.beans/ATFS-89ku--advertise-instance-endpoints-in-devatfsserver.md b/.beans/ATFS-89ku--advertise-instance-endpoints-in-devatfsserver.md new file mode 100644 index 0000000..023d1be --- /dev/null +++ b/.beans/ATFS-89ku--advertise-instance-endpoints-in-devatfsserver.md @@ -0,0 +1,10 @@ +--- +# ATFS-89ku +title: Advertise instance endpoints in dev.atfs.server +status: todo +type: feature +created_at: 2026-08-07T06:45:38Z +updated_at: 2026-08-07T06:45:38Z +--- + +An ordered endpoints list (base URLs) in the record, purely app-facing: apps discovering dev.atfs.server records get where-to-POST directly, no DID resolution needed (parallel to dev.atfs.file's providers). Server tolerates-and-ignores it today; lexicon + README + record.Server struct when implemented. Feeds the did:web self-serve doc's serviceEndpoint too. diff --git a/.beans/ATFS-l16z--serve-didweb-resolution-documents-from-atfs-itself.md b/.beans/ATFS-l16z--serve-didweb-resolution-documents-from-atfs-itself.md new file mode 100644 index 0000000..bcfe6e3 --- /dev/null +++ b/.beans/ATFS-l16z--serve-didweb-resolution-documents-from-atfs-itself.md @@ -0,0 +1,15 @@ +--- +# ATFS-l16z +title: Serve did:web resolution documents from atfs itself +status: draft +type: feature +created_at: 2026-08-07T06:45:38Z +updated_at: 2026-08-07T06:45:38Z +--- + +When serviceDid is a did:web, atfs should serve GET /.well-known/did.json itself — identity from the record, serviceEndpoint from the (planned) endpoints field — so a properly-deployed instance becomes a resolvable atproto service with zero external setup. + +Security questions JP wants thought through before building (2026-08-06): +- [ ] Does atfs need the domains it answers on preconfigured (hostname allowlist interplay)? Serving a did.json for a domain we merely *received* a Host header for could let an unrelated domain pointing at us mint an identity we never claimed. +- [ ] What happens on local/non-public installations — did:web requires real HTTPS at exactly the claimed hostname, which the plain-HTTP LAN transport can never satisfy; should the handler refuse/warn when the serviceDid's domain cannot possibly match? +- [ ] Should the served doc be constrained to exactly serviceDid's domain (never synthesized for other Hosts)? diff --git a/.beans/ATFS-zkf8--announce-new-uploads-to-the-dht-immediately.md b/.beans/ATFS-zkf8--announce-new-uploads-to-the-dht-immediately.md new file mode 100644 index 0000000..74f6411 --- /dev/null +++ b/.beans/ATFS-zkf8--announce-new-uploads-to-the-dht-immediately.md @@ -0,0 +1,10 @@ +--- +# ATFS-zkf8 +title: Announce new uploads to the DHT immediately +status: todo +type: bug +created_at: 2026-08-07T06:45:38Z +updated_at: 2026-08-07T06:45:38Z +--- + +Found reviewing the first-upload path: provideAll runs at startup and on the 12h ticker only, so a fresh upload isn't DHT-discoverable for up to 12h (direct-connect Bitswap still works). The uploadBlob path should trigger a provide of the blob's fetchable root after indexing. -- 2.51.2