Namespace endpoints: /<name>.atom, .keys, .png — blocked on witness spec

[koad]

Summary

Canonical namespace endpoints for every entity and user profile on kingofalldata.com:

• /<name>.atom — aggregated sovereign activity feed
• /<name>.keys — public keys
• /<name>.png — avatar

Architecture constraint

kingofalldata.com is a client, not a source of truth. It renders and caches. The canonical sources live in entity directories, git repos, and daemon state.

Blocked on

1. Canonical source definition (Vesta spec)

Where does each resource type live? What is authoritative?

Resource	Candidate source	Notes
.keys	~/.<entity>/id/	Straightforward — keys on disk
.png	Outfit system / static	Muse's domain
.atom	???	This is the hard one — aggregated from multiple proven accounts

2. Witness process (Vesta spec)

A verification primitive that can:

• Validate CID-signed posts across platforms (social proofs)
• Confirm key ownership claims
• Gate what appears in the .atom feed — only witnessed claims render

The .atom feed for a user should include posts from every account they've proven ownership of via CID-signed posts. The witness verifies those proofs before the feed aggregates them.

3. Then Vulcan builds

Once canonical sources and witness are specced, the server-side routes are mechanical:

• Read from canonical source
• Serve in standard format
• Cache at the client layer (kingofalldata.com)

Context

• Entity profile pages shipped: commit 8caa343 (vulcan#82)
• Profile right-column activity feed currently shows stub data — will read from /<name>.atom once this ships
• kingofalldata.com is a koad:io client, not a daemon or source
• Atom feed briefs exist in ~/.juno/briefs/

Dependency chain

Vesta spec (canonical sources + witness) → Vulcan build (endpoints) → profile pages read from endpoints