RFC: World discovery mechanism after bootstrap removal

[Jing-yilin]

Context

PR #96 implements world-scoped agent isolation — agents discover each other only through World membership, not global bootstrap gossip. After this change, the 5 AWS bootstrap nodes serve only one purpose: World Servers announce themselves so agents can call list_worlds. But since agents no longer query bootstrap for peer discovery, this is a dead path.

We need a replacement for World discovery.

Current State

• Agent-side bootstrap calls removed (PR feat!: world-scoped agent isolation — remove global peer gossip #96)
• World Server still announces to bootstrap via startDiscovery(), but no consumer exists
• join_world now accepts direct address parameter
• 5 AWS EC2 t3.medium nodes (~$200+/month) serving no useful purpose

Requirements

1. World creators can register their World so agents can find it
2. Agents can list available Worlds without knowing addresses in advance
3. Minimal operational cost (ideally zero infrastructure)
4. Works with the world-scoped isolation model (World = visibility boundary)

Proposed Options

Option A: Static World Registry (worlds.json on GitHub Pages)

{
  "worlds": [
    {
      "worldId": "pokemon-arena",
      "name": "Pokemon Battle Arena",
      "type": "programmatic",
      "address": "pokemon.example.com:8099",
      "cardUrl": "https://pokemon.example.com/.well-known/agent.json",
      "description": "Turn-based Pokemon battles",
      "theme": "battle"
    }
  ]
}

• list_worlds fetches https://resciencelab.github.io/DAP/worlds.json
• World registration = PR to add entry to docs/worlds.json
• Zero infrastructure cost (GitHub Pages, already in use for bootstrap.json)
• Git history provides audit trail
• Downside: not real-time, requires manual registration

Option B: Lightweight World Registry API

• Single HTTP endpoint: POST to register, GET to list
• World Server auto-registers on startup (like current bootstrap announce)
• Could be a simple Cloudflare Worker or similar serverless function
• Real-time, automatic
• Downside: another service to maintain (though much simpler than 5 bootstrap nodes)

Option C: Agent Card only (fully decentralized)

• No central registry at all
• Agents discover Worlds through out-of-band sharing (URLs, social, Agent Cards)
• join_world only works with explicit address
• Downside: no list_worlds possible without prior knowledge

Option D: Hybrid (A + B)

• Static worlds.json for curated/verified worlds
• Optional lightweight API for dynamic registration
• Agent Card for direct discovery
• Most flexible but most complex

Questions for Discussion

1. Is real-time registration important, or is static registration sufficient for the current development phase?
2. Should list_worlds continue to exist, or should world discovery be entirely out-of-band?
3. If we keep a registry, should it validate World liveness (health checks)?
4. What happens to the 5 AWS bootstrap EC2 instances — shut down immediately or keep as fallback?

Related

• PR feat!: world-scoped agent isolation — remove global peer gossip #96: feat!: world-scoped agent isolation
• PR feat: add world type system — programmatic & hosted modes #88: feat!: world type system, domain-separated signing, world ledger
• Current bootstrap infra: 5x AWS EC2 t3.medium (us-east-2, us-west-2, eu-west-1, ap-northeast-1, ap-southeast-1)

[Jing-yilin]

@codex Please review the proposed options for World discovery after bootstrap removal. Consider:

1. Scalability: Which option scales best as the number of Worlds grows from 10 → 1000+?
2. Developer experience: What's the lowest-friction way for a World creator to register?
3. Security: How do we prevent spam/malicious World registrations?
4. Cost: Current bootstrap costs ~$200/month for 5 EC2 nodes. What's the most cost-effective replacement?
5. Consistency with design philosophy: We just established that World = isolation boundary. Which discovery mechanism best aligns with this principle?

Also consider:

• The project is in early development (0.x, no users yet)
• We plan to rename DAP → AgentWorldNetwork
• Agent Cards are already served at /.well-known/agent.json by every World Server
• join_world already accepts direct address parameter

Please recommend one option (or propose a new one) with rationale.

[chatgpt-codex-connector]

To use Codex here, create an environment for this repo.