Summary
Implement Simplex-inspired ephemeral storage model where events are automatically deleted after a configurable retention period. This makes relays cheaper to run and supports use cases where permanent storage isn't needed.
Motivation
- Lower storage costs for relay operators
- Support "inbox-style" relays that only hold recent events
- Clients already manage local storage, so ephemeral relays can coexist with archival relays
- Aligns with Nostr's flexibility - users choose their relay mix
Proposed Features
1. Retention mode presets
Simple config option for relay operators to choose their storage model:
[retention]
mode = "ephemeral" # archival | normal | ephemeral | custom
| Mode |
Behavior |
archival |
Store events indefinitely (current default) |
normal |
~1 year retention, profiles/relay lists longer |
ephemeral |
21-day retention (Simplex-style) |
custom |
Use per-kind settings below |
2. Custom per-kind retention (when mode = "custom")
[retention]
mode = "custom"
default_days = 21
kind_0 = 90 # profiles
kind_1 = 21 # notes
kind_4 = 7 # DMs
kind_10002 = 90 # relay lists
3. Advertise retention in NIP-11 response
Add retention field to existing NIP-11 relay info so clients know the policy:
{
"retention": [
{"kinds": [0, 10002], "time": 7776000},
{"kinds": [1, 4], "time": 1814400}
]
}
Implementation Notes
Existing infrastructure to build on:
cleanupExpiredEvents() in store.zig - extend to check idx:created against TTL
- Background cleanup thread already runs hourly
idx:created index enables efficient age-based lookups
- NIP-11 already implemented in
nip11.zig - just add retention field
References
- Simplex SMP servers - 21-day message retention model
- NIP-40 (expiration tag) - already supported
Summary
Implement Simplex-inspired ephemeral storage model where events are automatically deleted after a configurable retention period. This makes relays cheaper to run and supports use cases where permanent storage isn't needed.
Motivation
Proposed Features
1. Retention mode presets
Simple config option for relay operators to choose their storage model:
archivalnormalephemeralcustom2. Custom per-kind retention (when mode = "custom")
3. Advertise retention in NIP-11 response
Add
retentionfield to existing NIP-11 relay info so clients know the policy:{ "retention": [ {"kinds": [0, 10002], "time": 7776000}, {"kinds": [1, 4], "time": 1814400} ] }Implementation Notes
Existing infrastructure to build on:
cleanupExpiredEvents()instore.zig- extend to checkidx:createdagainst TTLidx:createdindex enables efficient age-based lookupsnip11.zig- just add retention fieldReferences