kingofalldata.com: namespace routing — blocked on DNS, SSL, Sponsors API token

[koad]

Status

Home page is live with correct copy (Mercury spec applied), Iris strategic position in meta/manifest, PWA service worker + icons shipped.

Namespace cards in hero (koad.kingofalldata.com, juno.kingofalldata.com) are present in the UI but point to dead links — subdomain routing is not built yet.

What's needed to complete Phase 1

Per 2026-04-03-juno-mvp-spec.md, these are koad-provided dependencies before namespace routing can ship:

1. Wildcard DNS — *.kingofalldata.com pointing to dotsh (Vultr, Toronto)
2. Wildcard SSL — cert for *.kingofalldata.com (nginx config is ready in config/nginx.stanza)
3. GitHub Sponsors API token — needed for the namespace provisioning flow (sponsor → OAuth → API check → namespace created)
4. SSH access confirmation for dotsh — need ~/.koad-io/bin/dotsh wrapper or equivalent

What Vulcan will build once unblocked

• koad:io-router subdomain detection — hostname → namespace resolution
• Namespace pages: profile, /keys (plaintext, stable format for Dark Passenger), /trust
• GitHub OAuth + Sponsors API verification → namespace provisioning
• MVP Zone gate at /mvp
• koad and Juno namespaces live and populated from entity repos

Repo

github.com/koad/kingofalldata-dot-com — branch main

— Vulcan

[koad]

Routing Architecture Decision (2026-04-06)

Namespace model

Path-based for users:
```
kingofalldata.com/koad
kingofalldata.com/juno
kingofalldata.com/sally
```

Subdomain for koad's kingdom only:
```
downloads.kingofalldata.com ✓ koad's kingdom
nightly.kingofalldata.com ✓ koad's kingdom
juno.kingofalldata.com ✓ koad's kingdom entity
sally.kingofalldata.com ✗ not koad's kingdom → wildcard redirects home
```

Wildcard redirect

*.kingofalldata.com → 301 → kingofalldata.com (bare domain, not www)

Any unclaimed or external subdomain bounces to home. Good funnel — visitor sees the brand site.

No wildcard DNS for namespaces

Original blocker (wildcard DNS for namespace routing) is removed. Namespaces are path-based. No per-namespace DNS or SSL management needed.

Reserved slugs

Any subdomain claimed by koad's kingdom must also be reserved as a path on the Meteor router (to prevent collision). One reserved list covers both.

Custom domains

Users who want subdomain routing bring their own domain. We provide the routing endpoint, they manage DNS. We can support it but don't need to provision it.

Niche domains

Separate domains (e.g. agentdir.com) can use subdomain-style namespace routing — that's the value prop of those domains specifically.

[koad]

Namespace Route & Identity File Convention (2026-04-06)

Human-facing: namespace page

kingofalldata.com/koad

This is what humans share. A profile page. Links to everything below.

Machine-facing: convention-based file resolution

kingofalldata.com/koad.png      ← avatar + encoded context bubble, named after namespace
kingofalldata.com/koad.json     ← structured profile
kingofalldata.com/koad.gpg      ← public keys

No discovery protocol needed — the convention IS the protocol. Machines know the pattern and skip the page.

Why koad.png not avatar.png

Downloaded files must survive. avatar.png collides when you download multiple entities. koad.png is unambiguous — the namespace is the filename.

Subdomain API (machine use)

koad.kingofalldata.com/profile.json
koad.kingofalldata.com/keys.gpg

Valid, useful for structured API access. Not the sharing URL — humans don't use this.

Guidance

• Humans share: kingofalldata.com/koad
• Machines resolve: kingofalldata.com/koad.png, .json, .gpg
• The namespace page links to all identity files
• No registration, no discovery protocol — URL convention is self-describing

[koad]

Namespace Identity Stack — Complete Convention (2026-04-06)

kingofalldata.com/koad          ← profile page (human shares this)
kingofalldata.com/koad.png      ← avatar + encoded context bubble
kingofalldata.com/koad.json     ← structured profile
kingofalldata.com/koad.gpg      ← public keys
kingofalldata.com/koad.atom     ← unified social feed

koad.atom — sovereign social feed

Each namespace publishes an Atom feed at /{namespace}.atom. The feed aggregates all posts from all platforms — whatever the owner chooses to include.

For the publisher:

• One canonical feed URL that outlives every platform
• Mercury publishes to Twitter, Nostr, etc. and updates the .atom
• Platform dies, subscribers don't lose you — the URL is permanent
• The .atom is the canonical record; platform posts are distribution

For the reader:

• Subscribe to peers' feeds in any Atom/RSS reader
• No algorithm, no platform account, no registration
• A sovereign social graph = a list of .atom URLs

For the ecosystem:

• Every koad:io namespace automatically has a feed address
• Follow the whole entity team by subscribing to 8 URLs
• Feed content is owner-curated — publish what you want, omit what you don't

Mercury implication

Mercury's primary output is koad.atom. Publishing to external platforms is distribution, not the record. The atom file is what persists.

cc: koad/mercury — Mercury needs a skill to maintain and update the .atom file as part of every publish workflow.