Skip to content

feat: co-host the Pacto Nostr relay (--profile relay)#5

Open
RonTuretzky wants to merge 1 commit into
RonTuretzky/integrate-covenant-pactfrom
RonTuretzky/host-pacto-relay
Open

feat: co-host the Pacto Nostr relay (--profile relay)#5
RonTuretzky wants to merge 1 commit into
RonTuretzky/integrate-covenant-pactfrom
RonTuretzky/host-pacto-relay

Conversation

@RonTuretzky

Copy link
Copy Markdown
Contributor

Stacked on #3 (base branch is RonTuretzky/integrate-covenant-pact); retarget to main after #3 merges.

Summary

  • Adds an opt-in nostr-rs-relay service to the compose stack (docker compose --profile relay up -d --build), pinned to the same 0.9.0 tag pacto-dev-env uses. relay.pacto.chat (the relay the pacto daemon config points at) doesn't resolve yet, so this gives the Pacto network an actual home for it — inside the same attested TEE as the bot.
  • docker/Dockerfile.relay builds from the pinned upstream tag and bakes in docker/relay-config.toml, so the artifact is Phala-compatible (no bind mounts) and the policy is auditable; --config is passed explicitly so a broken config fails fast instead of nostr-rs-relay's silent fall-back to upstream defaults.
  • docker/phala-compose.yaml gets a commented-out service block mirroring the pacto-bot-api pattern, with digest-pinning instructions (only a literal sha256 digest is covered by the attested compose_hash) and the dstack-gateway wss:// endpoint.
  • Docs: new "Hosting the Pacto Nostr Relay" section in CLAUDE.md (local + Phala setup, custom-domain via dstack-ingress TLS-in-CVM, event-kind policy), README bullet, .env.example pointer, and an in-network relays hint in pacto-bot-api.toml.example.

Event-kind policy note

event_kind_allowlist ships commented out. The kinds Pacto uses today (from pacto-app's nostr-sdk usage) are 0, 7, 9, 14, 15, 16, 443, 444, 445, 1059, 30078 — but pacto-dev-env's own relay config puts the allowlist under an [events] section that nostr-rs-relay silently ignores (and the sqlite path under a nonexistent [database] path), so that allowlist has never actually been enforced in the dev environment. Worth a follow-up fix in pacto-dev-env; here it stays off until the kind set is confirmed.

Test plan

  • docker compose --profile relay --profile pacto config validates
  • Image builds; NIP-11 info doc served with the baked-in config ("name": "Pacto relay", version 0.9.0)
  • WebSocket handshake (101) + REQEOSE round-trip; bogus EVENT rejected with invalid: Event invalid id
  • sqlite lands in /var/lib/nostr-relay (the relay-data volume) as uid 1000
  • Container logs at INFO (RUST_LOG baked in; upstream default is errors-only)
  • Malformed config.toml → container exits 1 with a parse error (no silent defaults)
  • Phala: build/push linux/amd64, digest-pin, uncomment service + volume, verify wss://<app-id>-7000.<gateway-domain>.phala.network from a Nostr client

Adds an opt-in nostr-rs-relay service (pinned to 0.9.0, same as
pacto-dev-env) to the local compose stack and, commented with
digest-pinning instructions, to the Phala compose. The relay policy
(docker/relay-config.toml) is baked into the image via
docker/Dockerfile.relay so the same artifact runs on Phala and is
auditable; --config is passed explicitly so a broken config fails fast
instead of silently reverting to upstream defaults.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant