Thread

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.