NIPs by PolleramaCommunity NIPs, surfaced by trustConnect
← Back to NIPs
npub10npj3gydmv4...

Relay Connection Limits

Published Jul 12, 2026

NIP-65535

Relay Connection State (LIMITS)

Original PR source: https://github.com/vitorpamplona/nips/blob/4b9718ff34f47ebc4445752bb7990b055b90bb18/22.md

draft optional

Relays can tell a Client, at any moment, what the Client is currently allowed to do on this connection — instead of the Client discovering it one rejection at a time.

["LIMITS", { <limit_properties> }]

When it is sent

The relay SHOULD send a LIMITS message upon connection, and again any time the Client's rights change (payment received, session state change, etc.).

The relay MUST send a LIMITS message after responding OK true to a [NIP-42](42.md) AUTH event, even if nothing changed. This gives Clients a deterministic re-evaluation point:

connect → await LIMITS → (AUTH → await LIMITS)? → act

Each LIMITS message is a complete statement of the connection's current state and replaces any previous one. A property absent from the payload means the relay declares no constraint for it.

Access properties (authoritative)

  • can_read: <true|false>, If false, Clients MUST NOT send REQ messages.
  • can_write: <true|false>, If false, Clients MUST NOT publish events.
  • auth_for_read: <true|false>, If true, authenticating via [NIP-42](42.md) may change can_read and/or the read limits below.
  • auth_for_write: <true|false>, If true, authenticating via [NIP-42](42.md) may change can_write and/or the write limits below.

Client guidance: if can_read or can_write is false and the corresponding auth_for_* is not true, the Client SHOULD remove the relay from its read or publish pool for the rest of the session rather than retrying. If auth_for_* is true, the Client MAY authenticate proactively and wait for the follow-up LIMITS before proceeding.

Transport properties (advisory)

The relay enforces its limits regardless; these exist so Clients can pre-filter and shape their request loops instead of learning limits through rejections. Clients SHOULD respect them to avoid wasted round-trips.

  • max_message_length: <int>, Maximum length of any websocket message. Clients SHOULD crop/chunk REQ filters and withhold oversized events accordingly.
  • max_subscriptions: <int>, Maximum concurrent subscriptions. Clients SHOULD pool or multiplex their subscriptions to fit.
  • max_filters: <int>, Maximum filters per REQ. Clients SHOULD chunk larger requests.
  • max_limit: <int>, Maximum limit honored per filter. Clients SHOULD clamp limit to this value and paginate with since/until for additional results.
  • max_event_tags: <int>, Maximum .tags length of a published event.
  • max_content_length: <int>, Maximum .content length of a published event.

What this NIP intentionally does not cover

This NIP does not attempt to encode relay policy (accepted event kinds, proof-of-work requirements, rate limits, required tags, etc.). Event acceptance policies vary too widely across relay implementations to be collapsed into a single LIMITS payload; relays SHOULD continue to communicate policy decisions per-event via OK and CLOSED messages.

Relationship to NIP-11

[NIP-11](11.md)'s limitation object is a static, best-effort document describing the relay in general. LIMITS is live and per-connection: it reflects what this Client, in its current authentication and session state, can do right now — something a static document cannot express. Where the two disagree, LIMITS wins for the duration of the connection.