wisp.place-monorepo
Monorepo for wisp.place. A static site hosting service built on top of the AT Protocol. wisp.place
Star 103
Fork 7
Watch

Potential for Static PDS hosting on Wisp? #97

Merged nekomimi.pet
targeting main from byjp.me/wisp.place-monorepo:feat/native-subscribe-repos
Merged opened by and assigned to nekomimi.pet
targeting main from byjp.me/wisp.place-monorepo:feat/native-subscribe-repos

Hey @okami.mom! I've gone a bit wild here, I'd appreciate knowing your thoughts, if you have the time!

As you know I've been building at-sdp for adding read-only atproto PDSes to Wisp static sites. The static parts already work (at://blinkers.dev is hosted on Wisp!) but relays don't know about it, as Wisp can't respond to wss://blinkers.dev/xrpc/com.atproto.sync.subscribeRepos.

I'd hoped to update relays to follow redirects (to a dump bridge service), but Bluesky have bigger fish to fry right now. So… I thought perhaps Wisp might offer the bridging functionality?

/xrpc/com.atproto.sync.subscribeRepos wisp:firehose 200

This PR lets you put the above in your _redirects — it sets Wisp up to play back the atproto records/frames a tool like at-SDP signs and writes into the site (xrpc/_sdp/events/) over wss for a Relay to read, store & forward.

Wisp holds no (new) state or keys for this (the state is all in the site); plus it only kicks in when:

  • the site's owner is a supporter (!)

  • the request came in on a custom domain — relays ban domains by suffix, so if one misbehaving subdomain site got wisp.place banned, every site would go with it

  • stuff handled by at-SDP:

    • the site opts in with the _redirects line above

    • its event log's head.json is valid

Each relay following a static PDS on Wisp holds one mostly idle WebSocket open, which is about about 2 KB of memory in hosting-service, an estimated 50 KB in Caddy, and 10 to 15 MB a month of keepalive traffic.

100 infrequently updated static PDS sites each followed by Bluesky's 2 relays would be about 200 sockets and 2.5 GB a month of traffic.

Things I'm less sure of:

  • I've only run this locally (goat's firehose verifier against a real at-SDP site), not behind your Caddy/CDN set up; this would need WebSocket upgrades pass through those layers for custom domains (a plain GET on an enabled site gets a no-store 426)

  • every dial checks the supporter table uncached; because every relay will redial at roughly the same time after a hosting release you may want me to put a cache in there (I don't know if you ever re-release all sites at once, in which case you might get a thundering herd?)

Thanks for reading this far! Do you think you'd want this in Wisp? I'm not precious about the approach; I'm happy to rework it, discuss it, or for you to close this if it's not a direction you want to take 😊

Commits 0