clone

nostr relays on demand at <name>.bind.ws: claim one with your key, pay in zaps past the free allowance

docs, landing: custom domains, and the one-time zone setup for the host

Dami committed cdd2497
commit
cdd249726732c33037e592d6bc975f7d9c5cd06b
parent
bbfe3e4718ce79b2f3c96d15a1f3fc6112e39ab2
author
Dami <dami.etoile@gmail.com>
4 files changed, +40 -0
Mdocs/00-getting-started.md6++++++
Mdocs/01-relay-configuration.md2++
Mdocs/11-hosting-bindws.md31++++++++++++++++++++++++++++++
Msrc/landing.ts1+
M docs/00-getting-started.md +6 -0
M docs/01-relay-configuration.md +2 -0
M docs/11-hosting-bindws.md +31 -0
@@ -57,6 +57,37 @@ Nothing else is required: no origin, no certificates, no servers. An idle relay
5757 - The `usage` table grows one row per relay per month. No cleanup is needed.5858 - To take a relay down as the operator, use the owner's typed-name `deleterelay` call or the console.5959 60+## Custom domains61+62+Owners can put a relay under a hostname they control, such as `relay.example.com`, through [Cloudflare for SaaS custom hostnames](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/). The feature is off until the one-time setup below is done; the console says so until then.63+64+How it works, from the [docs](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin/): the customer's hostname CNAMEs to a name in your zone, so their traffic enters your zone, and a Worker route that matches any host sends it to the Worker. The Worker sees the customer's hostname in `Host`, looks it up in the `HOSTS` KV namespace to find the relay name, and forwards to that object exactly as it does for `<name>.<domain>`. Inside the object nothing changes; the URLs it prints already follow the request host. Certificates use [HTTP validation](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/http/), which Cloudflare completes on its own once the CNAME resolves to you, so the owner has one DNS record to create. [Hostname validation](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/) happens the same way; the optional TXT record the console also shows lets an owner activate the hostname before switching DNS.65+66+One-time setup, in this order:67+68+1. **Enable Cloudflare for SaaS** on the zone: dashboard, your zone, SSL/TLS, Custom Hostnames, Enable. Non-enterprise zones enter payment details; the first 100 hostnames are free ([enable](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/enable/), [plans](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/plans/)).69+2. **Create the fallback origin record**, originless and proxied, in the zone's DNS ([worker as origin](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin/)):70+71+ | Record | Name | Value | Proxy |72+ |---|---|---|---|73+ | `AAAA` | `fallback` | `100::` | on |74+75+ Then on the Custom Hostnames page set **Fallback Origin** to `fallback.<domain>` and wait for it to read Active. The wildcard placeholder records from the DNS section above are not enough here: the fallback origin must be a record of its own.76+3. **Create the CNAME target** owners will point at, proxied ([getting started, step 2](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#2-optional-create-cname-target)):77+78+ | Record | Name | Value | Proxy |79+ |---|---|---|---|80+ | `CNAME` | `customers` | `fallback.<domain>` | on |81+82+ `CNAME_TARGET` in `wrangler.jsonc` must match: `customers.<domain>`.83+4. **Routes.** `wrangler.jsonc` declares a `*/*` route on the zone next to the wildcard, which is what makes custom hostname traffic reach the Worker. Deploy once after the change and confirm in Workers Routes that the zone lists `*/*` for `bindws-relay`. If wrangler refuses the pattern, add it by hand on that page: route `*/*`, Worker `bindws-relay`.84+5. **KV namespace.** `npx wrangler kv namespace create HOSTS` and put the id in both `kv_namespaces` entries of `wrangler.jsonc` (the repo carries the bind.ws one).85+6. **API token.** My Profile, API Tokens, Create Token, Custom token: permission **Zone, SSL and Certificates, Edit**, zone resources limited to your zone. Store it as a secret: `npx wrangler secret put CF_API_TOKEN`. `ZONE_ID` in `wrangler.jsonc` is the zone the hostnames are created in (the same id the routes use). Without the secret the console reports custom domains as not enabled and the methods answer `unsupported:`.86+87+The Worker calls three endpoints with that token: [create](https://developers.cloudflare.com/api/resources/custom_hostnames/methods/create/), [get](https://developers.cloudflare.com/api/resources/custom_hostnames/methods/get/) and [delete](https://developers.cloudflare.com/api/resources/custom_hostnames/methods/delete/) under `/zones/<zone>/custom_hostnames`. A hostname is ready when the API reports `status: active` and `ssl.status: active` ([check when ready](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#check-when-a-custom-hostname-is-ready)). Deleting a relay removes its hostnames from Cloudflare and KV; transferring keeps them. Do not let an owner add the zone's own apex as a custom hostname; the relay refuses anything under `<domain>`.88+89+Locally, `wrangler dev` has no custom hostname traffic; the KV binding exists so tests can seed a mapping.90+6091 ## Local development6192 6293 ```
M src/landing.ts +1 -0