Kind 13 (NIP-59 seal) falls through every event classification #4

New issue

Open

opened 2026-05-03 13:41:29 +00:00 by padreug · 0 comments

padreug commented

2026-05-03 13:41:29 +00:00

Owner

Observation

NostrEvent's classification helpers don't categorise kind 13:

# relay/event.py
is_replaceable_event  -> [0, 3, 41] or 10000–19999  -> ✗
is_regular_event      -> 1000–9999                  -> ✗
is_ephemeral_event    -> 20000–29999                -> ✗
is_addressable_event  -> 30000–39999                -> ✗

In _handle_event, kind 13 hits the if not e.is_ephemeral_event: await create_event(e) branch and is stored. So it works correctly today
— it's just stored as an "untyped" event. Per NIP-01 §kinds, kinds in
1000 > kind should still be treated as regular by default, so storage
is correct.

Why file this anyway

Per NIP-59, seals (kind 13) are encrypted inside gift wraps and
should not normally be published to relays. If a misbehaving client
publishes a bare seal, the relay accepts and stores it indefinitely.
Operators may want to:

Optionally reject bare kind 13 events (they have no use on the wire)
Or at least classify them so retention/storage policies can target them

Suggested approach

Either:

Add an is_seal check in _handle_event that rejects bare seals with
a NIP-20 NOTICE, controlled by a new spec flag (rejectBareSeals).
Tighten is_regular_event to include kind in (4, 5, 13) for NIP-01
default classification — purely cosmetic.

Low priority. The is_seal helper was already added in
#PR-feat-nip17-gift-wrap-support so the lookup is cheap.

Out of scope

Deferred from the NIP-17 PR — not a functional bug for gift-wrap traffic.

## Observation `NostrEvent`'s classification helpers don't categorise kind 13: ```python # relay/event.py is_replaceable_event -> [0, 3, 41] or 10000–19999 -> ✗ is_regular_event -> 1000–9999 -> ✗ is_ephemeral_event -> 20000–29999 -> ✗ is_addressable_event -> 30000–39999 -> ✗ ``` In `_handle_event`, kind 13 hits the `if not e.is_ephemeral_event: await create_event(e)` branch and is stored. So it works correctly today — it's just stored as an "untyped" event. Per NIP-01 §kinds, kinds in `1000 > kind` should still be treated as regular by default, so storage is correct. ## Why file this anyway Per NIP-59, seals (kind 13) are encrypted **inside** gift wraps and should **not** normally be published to relays. If a misbehaving client publishes a bare seal, the relay accepts and stores it indefinitely. Operators may want to: - Optionally reject bare kind 13 events (they have no use on the wire) - Or at least classify them so retention/storage policies can target them ## Suggested approach Either: 1. Add an `is_seal` check in `_handle_event` that rejects bare seals with a NIP-20 NOTICE, controlled by a new spec flag (`rejectBareSeals`). 2. Tighten `is_regular_event` to include `kind in (4, 5, 13)` for NIP-01 default classification — purely cosmetic. Low priority. The `is_seal` helper was already added in #PR-feat-nip17-gift-wrap-support so the lookup is cheap. ## Out of scope Deferred from the NIP-17 PR — not a functional bug for gift-wrap traffic.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

aiolabs/nostrrelay#4

No description provided.

Rows
Columns