capsite: more public-origin candidates: syndicate, peers

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

social-coop-checklist.md

@@ -88,12 +88,22 @@ sit under each goal.
               keypair, HTTP Signatures), so `Update`/`Delete` arrive
               instead of being polled for. Needs a public HTTPS origin
               whose hostname is its identity; choose it once.
-              Candidate: `pesos.madmode.com`. It names the purpose
+              Candidates (user's call), each a possible single public
-              rather than the protocol or the server, and it can be
+              origin for all the caches (diigo, zotero, fedi), with
-              the one public origin for all the caches (diigo, zotero,
+              routes or a front worker dispatching by path over service
-              fedi), with routes or a front worker dispatching by path
+              bindings:
-              over service bindings. The follower actor would be
+              - `pesos.madmode.com`: names the purpose, but one
-              something like `@pesos@pesos.madmode.com`.
+                direction only (elsewhere → my site).
+              - `syndicate.madmode.com`: covers both directions, PESOS
+                and POSSE.
+              - `peers.madmode.com`: names the caches as peers of each
+                other, for if-this-then-that interactions between them
+                (a favourite becomes a diigo bookmark, a zotero item
+                becomes a post). Those need *write* authority, which
+                no cache holds today: each would be a new, narrowly
+                minted capability, not a widening of the read tokens.
+              The follower actor's handle follows the hostname
+              (e.g. `@dckc@peers.madmode.com`).
         - [ ] 8-iii. Neither reaches favourites, bookmarks, or
               mentions: those stay on the client API (or the server's
               account archive).