[{"data":1,"prerenderedAt":281},["ShallowReactive",2],{"docs-navigation":3,"docs-search-sections":57,"docs-nav":261},[4],{"title":5,"path":6,"stem":7,"children":8},"Documentation","\u002Fdocs","docs\u002Findex",[9,10],{"title":5,"path":6,"stem":7},{"title":11,"path":12,"stem":13,"children":14,"page":-1},"Nostrfi Relay","\u002Fdocs\u002Frelay","docs\u002Frelay\u002Findex",[15,16,26,30,39,48],{"title":11,"path":12,"stem":13},{"title":17,"path":18,"stem":19,"children":20,"page":25},"Concepts","\u002Fdocs\u002Frelay\u002Fconcepts","docs\u002Frelay\u002Fconcepts",[21],{"title":22,"path":23,"stem":24},"Relay role and architecture","\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role","docs\u002Frelay\u002Fconcepts\u002Frelay-role",false,{"title":27,"path":28,"stem":29},"Current limitations","\u002Fdocs\u002Frelay\u002Flimitations","docs\u002Frelay\u002Flimitations",{"title":31,"path":32,"stem":33,"children":34,"page":25},"Operations","\u002Fdocs\u002Frelay\u002Foperations","docs\u002Frelay\u002Foperations",[35],{"title":36,"path":37,"stem":38},"Development operation","\u002Fdocs\u002Frelay\u002Foperations\u002Fdevelopment-operation","docs\u002Frelay\u002Foperations\u002Fdevelopment-operation",{"title":40,"path":41,"stem":42,"children":43,"page":25},"Reference","\u002Fdocs\u002Frelay\u002Freference","docs\u002Frelay\u002Freference",[44],{"title":45,"path":46,"stem":47},"Protocol support","\u002Fdocs\u002Frelay\u002Freference\u002Fprotocol-support","docs\u002Frelay\u002Freference\u002Fprotocol-support",{"title":49,"path":50,"stem":51,"children":52,"page":25},"Security","\u002Fdocs\u002Frelay\u002Fsecurity","docs\u002Frelay\u002Fsecurity",[53],{"title":54,"path":55,"stem":56},"Trust and data","\u002Fdocs\u002Frelay\u002Fsecurity\u002Ftrust-and-data","docs\u002Frelay\u002Fsecurity\u002Ftrust-and-data",[58,62,67,73,76,81,86,91,96,101,106,111,116,119,124,129,134,139,142,147,152,157,162,167,172,177,182,187,192,195,200,205,210,215,220,223,228,233,238,241,246,251,256],{"id":6,"title":5,"titles":59,"content":60,"level":61},[],"Nostrfi product documentation, guides, and reference material.",1,{"id":63,"title":5,"titles":64,"content":65,"level":66},"\u002Fdocs#documentation",[5],"Nostrfi documentation provides comprehensive guidance for understanding,\nevaluating, integrating, operating, and troubleshooting Nostrfi products.",2,{"id":68,"title":69,"titles":70,"content":71,"level":72},"\u002Fdocs#available-documentation","Available documentation",[5,5],"Nostrfi Relay documentation — architecture, protocol support, operations, security, and limitations All documentation is clearly labelled with its product, owner, and last review\ndate. Relay documentation reflects the current prototype status.",3,{"id":23,"title":22,"titles":74,"content":75,"level":61},[],"What role a Nostr relay performs and how Nostrfi Relay is structured.",{"id":77,"title":78,"titles":79,"content":80,"level":66},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#what-a-relay-does","What a relay does",[22],"A Nostr relay is a server that stores signed events and serves them to clients\nover WebSocket connections. Clients publish events to relays and subscribe to\nevent feeds from relays. Each client chooses which relays to connect to and can\nconnect to multiple relays simultaneously. The relay does not hold users' private keys. Clients sign events locally and\nsend the signed event to the relay. The relay verifies the signature before\nstoring or serving the event.",{"id":82,"title":83,"titles":84,"content":85,"level":66},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#system-architecture","System architecture",[22],"Nostrfi Relay is a single-process Go application. One HTTP server exposes both\nthe NIP-11 information document and a WebSocket endpoint. Nostr client\n    | HTTP GET with Accept: application\u002Fnostr+json\n    | WebSocket: EVENT, REQ, CLOSE, AUTH, NEG-*\n    v\nRelayHandler\n    |-- connection authentication and subscriptions (in memory)\n    |-- live event fan-out (in process)\n    |-- NIP-11 response\n    +-- Negentropy sessions (in memory)\n             |\n             v\n       RelayService\n             |\n             v\n      DuckDBRepository\n        db\u002Frelay.db",{"id":87,"title":88,"titles":89,"content":90,"level":66},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#components","Components",[22],"",{"id":92,"title":93,"titles":94,"content":95,"level":72},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#entry-point","Entry point",[22,88],"cmd\u002Frelay\u002Fmain.go loads configuration, opens the DuckDB database, wires the\nrepository, service, and handler, and listens on port 8080. SIGINT or\nSIGTERM starts a five-second graceful HTTP shutdown before the database is\nclosed.",{"id":97,"title":98,"titles":99,"content":100,"level":72},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#handler","Handler",[22,88],"The handler owns WebSocket upgrades, connected-client tracking,\nper-connection subscriptions, authentication identity, Negentropy sessions,\nNostr message parsing, signature verification, and synchronous live fan-out\nto matching subscriptions.",{"id":102,"title":103,"titles":104,"content":105,"level":72},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#service","Service",[22,88],"The service layer defines the boundary between transport logic and storage.",{"id":107,"title":108,"titles":109,"content":110,"level":72},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#persistence","Persistence",[22,88],"A DuckDB repository stores events in two tables: events (identity, author,\ntimestamp, kind, content, signature, d tag, expiration) and tags (indexed\ntag name and first value keyed by event ID).",{"id":112,"title":113,"titles":114,"content":115,"level":66},"\u002Fdocs\u002Frelay\u002Fconcepts\u002Frelay-role#scaling","Scaling",[22],"The design is single-instance. Connected clients, subscriptions,\nauthentication, live broadcasts, and Negentropy sessions are local to one\nprocess. Horizontal scaling requires architectural work.",{"id":12,"title":11,"titles":117,"content":118,"level":61},[],"A self-operable Nostr relay — architecture, protocol support, operations, security, and limitations.",{"id":120,"title":121,"titles":122,"content":123,"level":66},"\u002Fdocs\u002Frelay#overview","Overview",[11],"Nostrfi Relay is a Nostr relay implementation written in Go. It speaks the\nNostr WebSocket protocol and implements a range of NIPs (NIP-01, 02, 09, 11,\n17, 22, 28, 40, 42, 70, 71, 77). The relay accepts signed events, serves filtered history, distributes live\nevents to active subscriptions, persists events in a local DuckDB database,\nand publishes a configurable NIP-11 relay information document. Prototype status. This relay is a prototype. It has not been deployed as a\npublic production service. Advertised NIP-11 limits are not enforced by the\nrequest path. Do not operate it as a public relay without completing the\nproduction-readiness checklist.",{"id":125,"title":126,"titles":127,"content":128,"level":66},"\u002Fdocs\u002Frelay#what-it-does","What it does",[11],"Accepts signed events and returns NIP-01 OK responsesServes stored events for REQ filters followed by EOSE and supports CLOSEBroadcasts matching newly accepted events to active subscriptionsPersists events and indexed single-letter tags in a local DuckDB databaseApplies replaceable and parameterized-replaceable event semanticsPublishes a configurable NIP-11 relay information documentIssues NIP-42 authentication challenges per WebSocket connectionRestricts NIP-70 protected-event publication to the authenticated authorRestricts kind 1059 gift-wrap reads to an authenticated recipient or authorSupports expiration filtering, deletion requests, and Negentropy sessions",{"id":130,"title":131,"titles":132,"content":133,"level":66},"\u002Fdocs\u002Frelay#source","Source",[11],"The relay source repository is at\ngithub.com\u002Fnostrfi\u002Frelay.",{"id":135,"title":136,"titles":137,"content":138,"level":66},"\u002Fdocs\u002Frelay#next-steps","Next steps",[11],"Relay role and architectureProtocol supportDevelopment operationTrust and dataCurrent limitations",{"id":28,"title":27,"titles":140,"content":141,"level":61},[],"Known limitations of the Nostrfi Relay prototype.",{"id":143,"title":144,"titles":145,"content":146,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#prototype-limitations","Prototype limitations",[27],"The relay is a prototype. The following limitations are known and must be\nunderstood before any deployment. The relay's intended operating model is a public reusable relay: general-purpose\ninfrastructure open to any Nostr client or user, not limited to Nostrfi's own\nproducts or team. The limitations below are what currently stand between the\nprototype and that goal; several earlier limitations have since been resolved\nand are noted as such rather than removed, so links to this page stay valid.",{"id":148,"title":149,"titles":150,"content":151,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#unenforced-limits","Unenforced limits",[27],"Resolved. Advertised NIP-11 limits (max message length, subscription and\nfilter counts, content length, tag count, timestamp bounds, proof-of-work,\nand auth requirements) are now enforced on the request path, not just\nadvertised. See the source repository's README.md for the exact behavior\nand defaults for each limit.",{"id":153,"title":154,"titles":155,"content":156,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#tag-fidelity","Tag fidelity",[27],"Stored tags retain only their first two fields, so events read from storage do\nnot preserve full multi-field tags. Markers, relay hints, and other trailing\nvalues are not reconstructed. This remains open.",{"id":158,"title":159,"titles":160,"content":161,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#no-tls","No TLS",[27],"The relay application itself still provides no native TLS — that boundary is\ndeliberate, not a gap: TLS termination is treated as a deployment-layer\nresponsibility. A documented, exercised TLS-terminating reverse-proxy overlay\nnow exists (Caddy, via docker-compose.tls.yml in the source repository) for\noperators who need it.",{"id":163,"title":164,"titles":165,"content":166,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#websocket-origins","WebSocket origins",[27],"Resolved. The WebSocket origin policy is now configurable, with a fail-closed\nproduction mode: an internet-facing deployment must set an explicit\nallow-list or the relay refuses to start. A permissive development mode\nremains available and is the default.",{"id":168,"title":169,"titles":170,"content":171,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#single-instance","Single-instance",[27],"The design is single-instance. Connected clients, subscriptions, authentication,\nlive broadcasts, and Negentropy sessions are local to one process. No\ninter-instance event bus or shared connection state exists. Horizontal scaling\nrequires architectural work. This remains open.",{"id":173,"title":174,"titles":175,"content":176,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#no-backup-or-retention-policy","No backup or retention policy",[27],"Resolved. A versioned schema-migration runner, a background worker that\npurges expired events (and their tags) on a configurable interval, and\n-backup\u002F-restore flags using DuckDB's native export\u002Fimport (with an\nintegrity-verified manifest) all now exist. Deletion and replacement on the\nexisting delete\u002Freplace code paths still do not remove associated tag\nrows, which can create orphaned index data over time — that specific gap\nremains open, tracked separately from the retention work above.",{"id":178,"title":179,"titles":180,"content":181,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#no-health-or-metrics","No health or metrics",[27],"Resolved. \u002Fhealthz and \u002Freadyz endpoints exist, and \u002Fmetrics exposes\nPrometheus-format metrics (connections, messages by type, rejections by\nreason, subscriptions, query latency, events stored, and save failures) with\ncardinality-bounded labels. An initial, explicitly provisional dashboard and\nalert set is documented, pending a formally approved service-level\nobjective. Distributed tracing remains open.",{"id":183,"title":184,"titles":185,"content":186,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#authentication-gaps","Authentication gaps",[27],"Resolved. The NIP-42 relay tag is now validated against the relay's\nconfigured canonical URL (not just checked for presence), and authentication\nevents outside a configurable freshness window are rejected. Authentication\nsessions are still not durable across connections.",{"id":188,"title":189,"titles":190,"content":191,"level":66},"\u002Fdocs\u002Frelay\u002Flimitations#no-production-readiness-claim","No production-readiness claim",[27],"The relay has not been deployed as a public production service. Most of the\nproduction-readiness checklist in the\ndevelopment operation guide\nis now complete; load-testing and threat-modeling remain open.",{"id":37,"title":36,"titles":193,"content":194,"level":61},[],"How development operation differs from production operation for Nostrfi Relay.",{"id":196,"title":197,"titles":198,"content":199,"level":66},"\u002Fdocs\u002Frelay\u002Foperations\u002Fdevelopment-operation#current-runtime","Current runtime",[36],"The source expects Go 1.25 with toolchain 1.25.12. Running the relay starts\none HTTP server, listening at the configured server.listen_addr (default\n:8080), and opens the DuckDB file at the configured storage.db_path\n(default db\u002Frelay.db). go run .\u002Fcmd\u002Frelay A Dockerfile and docker-compose.yml exist, and CI publishes versioned\nimages to ghcr.io\u002Fnostrfi\u002Frelay on every build (GitVersion-driven semver,\nsha-\u003Cshortsha>, and latest). A documented, exercised TLS-terminating\nreverse-proxy overlay (docker-compose.tls.yml, using\nCaddy) and a rollback recipe against those\npublished tags also exist — see the source repository's README.md\n\"Deployment\" section. TLS is not implemented in the application itself; that\nboundary is deliberate, not a gap — see the\ntrust and data page.",{"id":201,"title":202,"titles":203,"content":204,"level":66},"\u002Fdocs\u002Frelay\u002Foperations\u002Fdevelopment-operation#configuration","Configuration",[36],"config.yaml contains the NIP-11 relay information object (name,\ndescription, operator public key, contact, advertised software URL,\nsupported NIPs, and advertised relay limitations), plus operational\nsettings: resource limits, NIP-42 auth binding, WebSocket origin policy,\nretention, server listener and shutdown timeout, and the database path. See\nthe source repository's README.md \"Configuration\" section for the full\nreference and current defaults — every setting is configurable, with\ndefaults matching what used to be hardcoded. If the file is absent, code defaults supply basic identity and NIP values.\nLOG_LEVEL accepts debug, info, warn, or error; the default is\ninfo. The limitation fields in config.yaml are included in the NIP-11 response but\nare not applied to connections or messages unless the corresponding\nenforcement exists. Enforcement now covers message size, subscription and\nfilter counts, content length, tag count, timestamp bounds, proof-of-work,\nand auth requirements — operators should still confirm against the source\nREADME.md rather than assume a field is active.",{"id":206,"title":207,"titles":208,"content":209,"level":66},"\u002Fdocs\u002Frelay\u002Foperations\u002Fdevelopment-operation#storage-lifecycle","Storage lifecycle",[36],"Schema changes are applied by a versioned migration runner, recorded in a\nschema_migrations table; a migration failure aborts startup rather than\nserving traffic against a partially-migrated schema. A background worker\ndeletes events whose NIP-40 expiration has passed (and their tag rows) on a\nconfigurable interval, then runs DuckDB's checkpoint and vacuum. -backup\nand -restore flags on the relay binary export and import the database\nusing DuckDB's native tooling, with a row-count manifest verified at restore\ntime. Deletion and replacement on the existing delete\u002Freplace code paths still\ndo not remove associated tag rows, which can create orphaned index data over\ntime — this remains open and is tracked separately from the storage-lifecycle\nwork above.",{"id":211,"title":212,"titles":213,"content":214,"level":66},"\u002Fdocs\u002Frelay\u002Foperations\u002Fdevelopment-operation#logging-and-observability","Logging and observability",[36],"Logs are structured JSON on standard output. \u002Fhealthz reflects process\nhealth only; \u002Freadyz verifies the database is reachable. \u002Fmetrics\nexposes Prometheus-format metrics: connections, messages by type, rejections\nby reason, subscriptions, query latency, events stored, and save failures,\nwith cardinality-bounded labels. Negentropy reconciliation logging is at\nDebug and no longer includes the raw payload value. There is still no\ndistributed tracing.",{"id":216,"title":217,"titles":218,"content":219,"level":66},"\u002Fdocs\u002Frelay\u002Foperations\u002Fdevelopment-operation#production-readiness-checklist","Production-readiness checklist",[36],"Define public, private, or product-specific relay policy and ownership. Make listener, public relay URL, data path, and shutdown settings explicit. Put authenticated TLS termination in front of the service (via a\ndocumented, exercised reverse-proxy overlay — the relay itself still\nnever terminates TLS directly). Enforce message, connection, subscription, filter, event, and time limits. Add connection and publication rate limits plus resource backpressure. Restrict and test the WebSocket origin policy. Add liveness, readiness, metrics, dashboards, and alerting (an initial,\nexplicitly provisional dashboard\u002Falert set — a formal service-level\nobjective has not been approved yet). Distributed tracing remains open. Establish schema migrations, backup, restore, retention, and purge jobs. Define moderation, abuse response, legal requests, and operator access. Load-test expected event volume, database growth, queries, and fan-out. Threat-model untrusted JSON, large events, connection floods, and metadata. Add release packaging, dependency scanning, and a deployment runbook\n(CI runs govulncheck on every build; a finding fails the build). html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"id":46,"title":45,"titles":221,"content":222,"level":61},[],"Which NIPs the relay implements and the limits of that evidence.",{"id":224,"title":225,"titles":226,"content":227,"level":66},"\u002Fdocs\u002Frelay\u002Freference\u002Fprotocol-support#advertised-nips","Advertised NIPs",[45],"The relay advertises NIPs 1, 2, 9, 11, 17, 22, 28, 40, 42, 70, 71, 77 in its\ndefault configuration. \"Covered\" below means a relevant automated integration\ntest exists and passed at the reviewed revision; it does not imply exhaustive\nconformance to every requirement in that NIP. NIPImplemented behavior observedEvidence and qualification01Signed event publication; OK; REQ; EVENT; EOSE; CLOSE; live matching; common filtersCovered. ID and author filters use exact equality; prefix-filter behavior is not implemented. Stored tags lose fields after the first value.02Kind 3 contact lists use replaceable-event behaviorCovered for replacement of an older list.09Kind 5 requests delete same-author targets addressed by e or a; deletion request remains storedCovered. No tombstone prevents later re-publication.11HTTP relay information document with CORS headers and configurable metadataCovered. Limit values are advertised but not enforced.17Kind 10050 storage and authenticated access control for kind 1059 gift wrapsCovered for recipient access and unauthenticated denial.22Kind 1111 comments and upper\u002Flower-case indexed tag filteringCovered for storing and finding a comment by E and e.28Kinds 40–44; latest kind 41 retained per referenced channelCovered. Moderation events are stored but not enforced.40Expiration stored; expired records omitted from queries; already-expired events rejectedCovered. Expired rows are hidden rather than purged.42Challenge on connection and signed kind 22242 authenticationCovered with NIP-70. Relay URL value and authentication-event time are not validated.70--tagged events require authentication as the event authorCovered for unauthenticated, matching-author, and different-author publication.71Kinds 21 and 34235 can be stored and queried; addressable replacement rules apply to kind 34235Covered for normal and addressable video events.77NEG-OPEN, NEG-MSG, NEG-CLOSE, NEG-ERR; reconciliation over timestamp\u002FID vectorsCovered for a client missing two of five events. Sessions are connection-local.",{"id":229,"title":230,"titles":231,"content":232,"level":66},"\u002Fdocs\u002Frelay\u002Freference\u002Fprotocol-support#general-event-semantics","General event semantics",[45],"Kinds 0, 3, and 10000–19999 are treated as replaceable by author and kind.Kinds 30000–39999 are treated as parameterized replaceable by author, kind,\nand d tag.Kind 41 receives special replacement behavior keyed by its e tag.Only tags with a one-character alphabetic name are indexed. Only the tag name\nand first value are stored.Query results exclude expired records and are ordered by newest timestamp\nthen ID, unless requested for Negentropy.",{"id":234,"title":235,"titles":236,"content":237,"level":66},"\u002Fdocs\u002Frelay\u002Freference\u002Fprotocol-support#conformance-work-still-needed","Conformance work still needed",[45],"Test the complete NIP-01 message grammar, malformed input, filter prefixes,\nlimits, duplicate events, and concurrent subscription behavior.Preserve every tag field exactly through a storage round trip.Validate NIP-42 relay URLs and freshness.Decide and document gift-wrap read\u002Fwrite, retention, and operator-access\npolicy.Run a compatibility suite against the Nostr clients and SDKs the product line\nintends to support.",{"id":55,"title":54,"titles":239,"content":240,"level":61},[],"What data and metadata a relay operator can observe and the security implications. The relay's intended operating model is a public reusable relay, so the trust\nboundaries below apply to any connecting client or user, not only to Nostrfi's\nown products or team.",{"id":242,"title":243,"titles":244,"content":245,"level":66},"\u002Fdocs\u002Frelay\u002Fsecurity\u002Ftrust-and-data#data-and-trust-boundaries","Data and trust boundaries",[54],"Event signatures are verified before storage; the relay does not hold user\nsigning keys.DuckDB contains event envelopes and content and must be treated as user data.Gift-wrap content may be encrypted, but its event envelope and recipient tag\nremain visible to the operator.Authentication and subscription authorization live only in process memory.The application provides no TLS; a production deployment needs a trusted edge\nor equivalent transport termination.Logs include authenticated public keys and Negentropy message payloads.",{"id":247,"title":248,"titles":249,"content":250,"level":66},"\u002Fdocs\u002Frelay\u002Fsecurity\u002Ftrust-and-data#what-an-operator-can-observe","What an operator can observe",[54],"The relay operator can observe: Connection metadata (IP address, timing, connection duration).All published event envelopes, including event content, author pubkey,\ntimestamps, signatures, and tag values.Gift-wrap metadata and ciphertext (kind 1059 events are access-controlled in\nthe application but exist unencrypted at the database-envelope level).Authenticated public keys after NIP-42 authentication.Subscription filters and query patterns.Negentropy reconciliation messages. The relay does not require users' private keys. It does, however, store public\nevent content and metadata. Operators should treat all stored data and\nconnection metadata as observable. A production deployment needs a threat model\ncovering resource exhaustion, hostile events, WebSocket origins, metadata\ndisclosure, moderation, database access, retention, deletion, logging, and\nabuse response.",{"id":252,"title":253,"titles":254,"content":255,"level":66},"\u002Fdocs\u002Frelay\u002Fsecurity\u002Ftrust-and-data#authentication-limitations","Authentication limitations",[54],"Authentication validates the event signature and challenge, but the supplied\nrelay tag is currently checked only for presence, not for the correct relay\nURL. Authentication sessions are not durable across connections.",{"id":257,"title":258,"titles":259,"content":260,"level":66},"\u002Fdocs\u002Frelay\u002Fsecurity\u002Ftrust-and-data#websocket-origin-policy","WebSocket origin policy",[54],"All origins are currently accepted during WebSocket upgrade. A production\ndeployment should restrict and test the WebSocket origin policy.",[262],{"title":5,"path":6,"stem":7,"children":263},[264,265],{"title":5,"path":6,"stem":7},{"title":11,"path":12,"stem":13,"children":266,"page":-1},[267,268,271,272,275,278],{"title":11,"path":12,"stem":13},{"title":17,"path":18,"stem":19,"children":269,"page":25},[270],{"title":22,"path":23,"stem":24},{"title":27,"path":28,"stem":29},{"title":31,"path":32,"stem":33,"children":273,"page":25},[274],{"title":36,"path":37,"stem":38},{"title":40,"path":41,"stem":42,"children":276,"page":25},[277],{"title":45,"path":46,"stem":47},{"title":49,"path":50,"stem":51,"children":279,"page":25},[280],{"title":54,"path":55,"stem":56},1786197334658]