feat: co-host the Pacto Nostr relay (--profile relay)#5
Open
RonTuretzky wants to merge 1 commit into
Open
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #3 (base branch is
RonTuretzky/integrate-covenant-pact); retarget tomainafter #3 merges.Summary
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.relaybuilds from the pinned upstream tag and bakes indocker/relay-config.toml, so the artifact is Phala-compatible (no bind mounts) and the policy is auditable;--configis passed explicitly so a broken config fails fast instead of nostr-rs-relay's silent fall-back to upstream defaults.docker/phala-compose.yamlgets a commented-out service block mirroring thepacto-bot-apipattern, with digest-pinning instructions (only a literal sha256 digest is covered by the attestedcompose_hash) and the dstack-gatewaywss://endpoint..env.examplepointer, and an in-networkrelayshint inpacto-bot-api.toml.example.Event-kind policy note
event_kind_allowlistships commented out. The kinds Pacto uses today (from pacto-app's nostr-sdk usage) are0, 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 configvalidates"name": "Pacto relay", version 0.9.0)REQ→EOSEround-trip; bogusEVENTrejected withinvalid: Event invalid id/var/lib/nostr-relay(therelay-datavolume) as uid 1000config.toml→ container exits 1 with a parse error (no silent defaults)wss://<app-id>-7000.<gateway-domain>.phala.networkfrom a Nostr client