fix(relay): accept mesh signaling kinds (24620/24621) via POST /events#946
Merged
Conversation
PR #879 moved mesh status-report and connect-request publishing from the TS frontend (WebSocket) into the desktop's Rust coordinator, which submits via the HTTP bridge. The bridge routes everything through ingest_event, whose per-kind allowlist deliberately excludes ephemeral kinds — so every coordinator publish failed with 400 'restricted: unknown event kind'. No status report ever became a kind:30621 discovery note, and connect requests never produced call-me-now pairs: share-compute was dead against a real relay. Fix: route 24620/24621 from the bridge to a new mesh_signaling HTTP seam (handle_mesh_event_http) that mirrors the WS door — signature check, strict pubkey-match (mesh kinds are never proxy-submittable), shared per-requester rate limit, then the existing handlers. The WS door's inline rate limit is factored into connect_request_rate_limited so both transports share one limiter. Verified live: relay on :3100, NIP-98-signed POST /events with a 24620 → 200 + relay-signed 30621 projection readable via /query; 24621 → 200. Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@sprout-oss.stage.blox.sqprod.co> Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@sprout-oss.stage.blox.sqprod.co>
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
1 participant
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.
Problem
Running current
mainwith share-compute enabled fails:PR #879 moved mesh status-report and connect-request publishing from the TS frontend (WebSocket) into the desktop's Rust coordinator, which submits via the HTTP bridge. The bridge routes everything through
ingest_event, whose per-kind allowlist deliberately excludes ephemeral kinds — so every coordinator publish failed with 400. No status report ever became a kind:30621 discovery note, and connect requests never produced call-me-now pairs: share-compute was dead against a real relay.Fix
Route 24620/24621 from the bridge to a new mesh_signaling HTTP seam (
handle_mesh_event_http) that mirrors the WS door — signature check, strict pubkey-match (mesh kinds are never proxy-submittable), shared per-requester rate limit, then the existing handlers. The WS door's inline rate limit is factored intoconnect_request_rate_limitedso both transports share one limiter.Verification