social-events.md (6778B)
1 # Public Social Event Substrate 2 3 Status: active implementation contract 4 5 Scope: public Radroots social Nostr event models, codecs, and deterministic conformance vectors in 6 this repository. 7 8 ## Purpose 9 10 The public social event substrate extends the Radroots event family beyond profile, farm, listing, 11 and trade workflows while keeping relay runtime behavior, application projections, moderation 12 services, and private Field business documents outside this repository's event-contract boundary. 13 14 The target implementation is standards-first and Radroots-named. Event models live in 15 `radroots_events`, canonical encode/decode behavior lives in `radroots_events_codec`, and 16 deterministic fixtures live under `contracts/conformance`. 17 18 ## Implementation Inventory 19 20 The repository implements public social support for kind `1` `RadrootsPost`, kind `1111` 21 `RadrootsComment`, kind `7` `RadrootsReaction`, generic `RadrootsList` entries, listing draft kind 22 `30403` through `RadrootsListing`, articles, generic public file metadata, calendar date events, 23 calendar time events, reposts, generic reposts, calendar collections, RSVP events, and reports. 24 25 The closeout contract requires: 26 27 - complete model and codec coverage for the approved public social event families 28 - kind and tag constants for the approved NIP surface 29 - `RadrootsPost` preservation for optional social metadata 30 - strict NIP-22 `RadrootsComment` behavior without legacy `e_root` or `e_prev` fallback tags 31 - strict NIP-25 `RadrootsReaction` behavior where empty content is a valid like 32 - explicit optional `published_at` support for NIP-99 listing parity 33 - NIP-65 relay-list validation evidence through `RadrootsList` 34 - conformance vectors and canonical-event witnesses for every new or upgraded social event family 35 36 ## Approved Event Families 37 38 The MVP public social substrate includes: 39 40 - `RadrootsPost` for ordinary NIP-01 kind `1` notes plus optional Radroots social metadata 41 - `RadrootsArticle` for NIP-23 kind `30023` long-form content 42 - generic public `RadrootsFileMetadata` for NIP-94 kind `1063` 43 - `RadrootsCalendarDateEvent` for NIP-52 kind `31922` 44 - `RadrootsCalendarTimeEvent` for NIP-52 kind `31923` 45 46 The production-v1 public social substrate includes: 47 48 - `RadrootsRepost` for NIP-18 kind `6` 49 - `RadrootsGenericRepost` for NIP-18 kind `16` 50 - `RadrootsCalendar` for NIP-52 kind `31924` 51 - `RadrootsCalendarEventRsvp` for NIP-52 kind `31925` 52 - `RadrootsReport` for NIP-56 kind `1984` 53 - listing draft kind `30403` validation through `RadrootsListing` 54 - relay-list kind `10002` validation through `RadrootsList` 55 56 ## Contract Decisions 57 58 `RadrootsPost` remains compatible with ordinary kind `1` text notes. Content-only notes must remain 59 valid. Optional farm or address references, media metadata, geohash, topics, and quote references 60 must be preserved when present and must use serde defaults so existing simple JSON fixtures remain 61 valid. 62 63 `RadrootsComment` uses strict NIP-22 semantics. The target and scope model must support event-id, 64 address, and external roots or parents through `E`/`e`, `A`/`a`, and `I`/`i` tags with matching 65 `K`/`k` kind metadata. Canonical encode and decode must reject ordinary kind `1` short text note 66 targets; kind `1` replies belong to NIP-10 text-note reply semantics instead. Canonical decode must 67 reject legacy `e_root` and `e_prev` fallback tags. 68 69 `RadrootsReaction` uses strict NIP-25 semantics. Empty content, `+`, `-`, emoji, and custom reaction 70 content are valid when the target tags are valid. Missing targets remain invalid. 71 72 `RadrootsReport` intentionally tightens NIP-56 for the Radroots type: a reported pubkey `p` tag is 73 required for a valid report, including event and file or blob reports. 74 75 Generic public `RadrootsFileMetadata` remains separate from private `RadrootsFarmFileMetadata` even 76 though both use kind `1063`. The public generic model must cover the current simple NIP-94 tags, 77 including URL, MIME type, SHA-256 hash, original hash, size, dimensions, blurhash, thumbnail, image, 78 summary, alt text, fallback, `magnet`, `i`, and `service`. 79 80 `RadrootsCalendarDateEvent`, `RadrootsCalendarTimeEvent`, and `RadrootsCalendar` use NIP-52 81 description content. Optional `description` data is encoded as event content and empty content 82 decodes to no description. Calendar date events use lowercase `d` for the replaceable identifier and 83 optional uppercase `D` tags for covered all-day dates. Calendar time events require at least one 84 uppercase `D` tag so timestamped events retain a deterministic calendar-date anchor across codecs. 85 86 Product routing uses surface-specific kind classifiers rather than a broad public-social set. Home, 87 Events, Market, Map, and Profile public-content candidates are explicit. Active listing kind `30402` 88 can appear in public product surfaces, but listing draft kind `30403` is limited to draft-owner 89 contexts. Report kind `1984` is a moderation/admin candidate, not normal feed content. Relay and HTTP 90 auth kinds are transient and excluded from durable social and farm-ops candidate sets. Private farm 91 operations candidates include the farm workspace manifest, farm CRDT change envelope, farm file 92 metadata, and the supported NIP-29 group event subset. 93 94 `RadrootsListingDraft` and `RadrootsRelayList` are not separate model types in the target contract. 95 Listing draft kind `30403` is represented through `RadrootsListing`, and NIP-51 standard and 96 list-set entries, including NIP-65 relay metadata kind `10002`, are represented through 97 `RadrootsList`. 98 99 ## Exclusions 100 101 This substrate does not include `RadrootsFeedItem`, `RadrootsMapPin`, NIP-72 community events, 102 checkout or payment events, or public task, harvest, work-session, approval, or other Field business 103 document event types. 104 105 Task records, work sessions, harvest records, approvals, and similar Field business objects remain 106 CRDT document semantics carried inside the CRDT change envelope unless a later contract explicitly 107 promotes them. 108 109 ## Consumer Boundary 110 111 The public social surface is event and codec substrate first. Consumer packages may wrap these 112 models and codecs, but this repository owns only the core Rust contracts and deterministic 113 conformance evidence. Package-specific operation maps, bindings, and generated artifacts are outside 114 this contract boundary. 115 116 ## Conformance Boundary 117 118 Every new social codec and every upgraded existing social codec must have deterministic valid and 119 invalid conformance vectors before closeout. Upgraded vectors must include the strict comment, 120 reaction, listing, farm, list, and list-set behavior whose public contract changes during the 121 refactor. 122 123 Social vectors are repo-owned and synthetic. They must not depend on application relay state, local 124 databases, external services, root fixture catalogs, or ambient machine state.