here it is nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z : it's not interning them as 5 byte serial references in the event storage but there is a graph table (bidirectional) that lets you search that way. i should make a todo to have it switch out the pubkeys in events for the serials. here is the explanation of it and how it works:
PubkeyEventGraph (peg) - Lines 595-610
// PubkeyEventGraph creates the reverse edge: pubkey_serial -> event_serial with event kind and direction
// This enables querying all events related to a pubkey, optionally filtered by kind and direction
// Direction: 0=is-author, 2=p-tag-in (pubkey is referenced by event)
//
// 3 prefix|5 pubkey serial|2 kind|1 direction|5 event serial
var PubkeyEventGraph = next()
Key structure:
[3: "peg"][5: pubkey_serial][2: kind][1: direction][5: event_serial]
↓ ↓ ↓ ↓
Unique ID for Event kind Relationship Event ref
this pubkey (uint16) type (byte) (uint40)
Total: 16 bytes per edge
The Direction Byte
This is the key insight—it encodes the relationship type between pubkey and event:
| Direction | Meaning | Query Use Case |
|-----------|-----------|------------------------------------------------------|
| 0 | is-author | "Find all events this pubkey authored" |
| 2 | p-tag-in | "Find all events that mention/reference this pubkey" |
How It Works With EventPubkeyGraph (epg)
These are bidirectional edges—two indexes that mirror each other:
EventPubkeyGraph (epg): event_serial → pubkey_serial
"Given an event, find related pubkeys"
PubkeyEventGraph (peg): pubkey_serial → event_serial
"Given a pubkey, find related events"
Example: If Alice (pubkey serial #42) posts event #1000 that mentions Bob (pubkey serial #99):
Indexes created:
epg entries (event → pubkey):
[epg][1000][42][kind 1][direction 0] ← Alice is author
[epg][1000][99][kind 1][direction 1] ← Bob is referenced (p-tag-out)
peg entries (pubkey → event):
[peg][42][kind 1][direction 0][1000] ← Alice authored event 1000
[peg][99][kind 1][direction 2][1000] ← Bob is mentioned in event 1000
Why Pubkey Serials Instead of Hashes?
Notice it uses pubkey_serial (5 bytes) not pubkey_hash (8 bytes). This requires two additional indexes:
// PubkeySerial: pubkey_hash → serial (lookup serial for a pubkey)
// 3 prefix|8 pubkey hash|5 serial
// SerialPubkey: serial → full 32-byte pubkey (reverse lookup)
// 3 prefix|5 serial -> 32 byte pubkey value
★ Insight ─────────────────────────────────────
- Serials save space: 5 bytes vs 8 bytes per edge × millions of edges = significant savings
- Kind in the key enables efficient filtering: "Find all kind 1 events mentioning pubkey X" is a single range scan
- Direction ordering matters: [pubkey][kind][direction][event] means you can scan "all kind 3 events where X is author"
without touching "events mentioning X"
─────────────────────────────────────────────────
Query Examples
"All events authored by pubkey X":
Start: [peg][X_serial][0x0000][0][0x0000000000]
End: [peg][X_serial][0xFFFF][0][0xFFFFFFFFFF]
↑
direction=0 (is-author)
"All kind 1 events mentioning pubkey X":
Start: [peg][X_serial][0x0001][2][0x0000000000]
End: [peg][X_serial][0x0001][2][0xFFFFFFFFFF]
↑ ↑
kind=1 direction=2 (p-tag-in)
"All events where pubkey X is either author OR mentioned":
// Two range scans, union results:
Scan 1: [peg][X_serial][*][0][*] ← authored
Scan 2: [peg][X_serial][*][2][*] ← mentioned
This graph structure is designed for social graph traversal—finding followers, mentions, interactions—without decoding full
events.