Description
Currently landregistry exposes HTTP endpoints for reading and managing lands:
- `GET /api/v1/lands` — list all lands (SQLite direct, Pantheon auth)
- `GET /api/v1/lands/{slug}` — get single land (SQLite direct, Pantheon auth)
- `PATCH /api/v1/lands/{slug}` — update land fields (SQLite direct, admin only)
- `DELETE /api/v1/lands/{slug}` — delete + trigger teardown (SQLite + Wind)
These use Pantheon token validation for auth, while the NATS paths use Mycelium account permissions. This mixes two auth models.
**Options:**
1. Move all to NATS taproot (`tap.landregistry.lands.list`, `.get`, `.update`, `.delete`) — auth handled purely by NATS account permissions via Mycelium. Dogfood the framework.
2. Keep HTTP for external/dashboard reads, NATS for internal mutations only.
3. Keep HTTP but remove Pantheon auth, rely on network-level access control.
**Considerations:**
- Pantheon handles identity (who is this user), Mycelium handles connectivity (what can this NATS account do). These are different concerns.
- HTTP is easier for dashboards and debugging (`curl`). NATS taproot is better for service-to-service.
- DELETE already has a NATS equivalent (`tap.landregistry.lands.*.delete`), so the HTTP DELETE is redundant like POST.
- Moving reads to NATS means any consumer needs a NATS connection, which may not suit all use cases (e.g. external monitoring).
Nebula's reasoning: This is an architectural decision with clear options laid out. Medium priority — the dual HTTP/NATS interface works today but adds maintenance burden and auth complexity. Note that #57 (remove HTTP POST) is a concrete first step that can be implemented independently regardless of how this broader question is resolved, since the POST endpoint is already unused in production. Resolving #59 (Pantheon vs Mycelium auth responsibilities) first would help inform the decision here. Title and description are thorough and well-organized.