# Musiquay — Feature: Event Roster > From the promoter to the girl pouring beer at the bar, everyone. Well structured, in the same place. Scene police validation. ## Overview The event roster is the feature that turns every show into a **permanent, structured, validated record** of the scene in action. Film has IMDb. Every movie lists every actor, every grip, every caterer. The credits roll and everyone who made it happen is named. The music scene has nothing like this. Shows happen. People work. The night ends. No record exists beyond a poster and some blurry phone photos. The sound engineer who mixed the show, the lighting tech who ran the rig, the door person who worked from 7pm to 2am, the road crew who loaded in at noon — they're invisible. The roster changes that. Every event on Musiquay has a complete, structured list of **everyone who made it happen**. Not just the bands on the poster. Every role, every person, documented and linked to their Nostr identity. And the scene itself validates it. This is the mechanism that turns social activity into professional history. It's the connective tissue between the [event calendar](./FEATURES_CALENDAR.md), the [services marketplace](./FEATURES_MARKETPLACE.md), and the [scene graph](./ARCHITECTURE.md#identity-and-the-scene-graph). It's how Musiquay becomes the definitive record of the music scene. ## Core Concepts ### Validation Without Bureaucracy Musiquay's roster system doesn't require official confirmation to be useful. The system is designed to embrace ambiguity rather than demand certainty. - **Unconfirmed roster entries are still valuable.** A fan adding the lighting tech's name creates structured, queryable data even if the tech never confirms it. "Someone tagged this person as lighting tech" is already more than we had before. - **Confirmation is signal, not gate.** Whether a roster entry has 0 confirmations or 5 attestations, it exists on the protocol and contributes to the scene graph. Confirmation amplifies trust, but absence of confirmation doesn't delete the entry. - **The scene self-corrects.** Obvious errors get flagged. Fabrications get called out. But edge cases and incomplete data don't break the system—they're a natural state of any community-maintained record. This approach recognizes how the music world actually works. Roster details are often incomplete, remembered differently, or documented long after the fact. The system should accommodate this reality, not demand perfection. ### No Business Logic in the Protocol Musiquay event kinds define structure, not behavior. The protocol specifies how to represent a roster, a confirmation, or a setlist—it does not specify what clients should do with that data. - **Confirmation workflows are client-side.** Whether a client shows "pending confirmation" badges, auto-sends notification DMs, or does nothing at all is up to the client developer. - **Aggregation is client-side.** How a client combines the original roster with wiki contributions into a unified view is a presentation choice, not a protocol requirement. - **Reputation systems are client-side.** If a client wants to surface "confirmation rate" or "attestation count," it calculates that from the events. The protocol doesn't define what counts as "reputable." This separation keeps the protocol lean and extensible. New clients can experiment with different UX paradigms without requiring protocol changes. The events are the source of truth; everything else is interpretation. ### The Roster is the Receipt After a show happens, the roster is the definitive record of who was involved. It's film credits for live events. Every role, every person, structured and linked. A typical roster for a mid-sized show might include: | Role | Who | |------|-----| | **Promoter** | The person/company who booked and promoted the event | | **Venue** | The physical space (already a Nostr identity) | | **Door / Box Office** | The person handling admission | | **Bar Staff** | People working the bar | | **Security** | Door security, crowd management | | **Sound — FOH** | Front-of-house engineer | | **Sound — Monitors** | Monitor engineer (if separate) | | **Lighting** | Lighting tech / designer | | **Stage Manager** | Coordinating changeovers, running order | | **Headliner** | The main act | | ↳ *Individual musicians* | Named members and session players | | **Support** | Opening / support acts | | ↳ *Individual musicians* | Named members, fill-ins, guest appearances | | **Backline Tech** | Guitar/drum/keys techs | | **Road Crew** | Load-in, load-out, merch | | **Van Driver** | The person who drove the band and gear | | **Photographer** | Covering the event | | **Filmmaker / Live Stream** | Video recording, streaming | | **Poster / Flyer Designer** | Visual artist who created the event artwork | | **Catering** | Food and drink for artists/crew | | **Van Rental Company** | Company that provided the transport | | **Backline Rental** | Company that provided rental gear | | **PA Rental** | Company that provided the sound system | A festival roster is the same concept, massively expanded — hundreds of participants across multiple stages and days. And it's not just people — **service companies are first-class participants too.** The van rental company, the PA rental house, the catering company, the backline provider — they all have Nostr identities, they all get tagged, they all build roster history. A rental company that's been on the roster for 50 festivals has a reputation that matters. ### Every Role Matters This is not "headliner, support, opener." The roster captures the full depth of work that goes into making music happen live. From the promoter to the girl pouring beer at the bar, from the van driver who got everyone there to the company that rented the PA — **everyone gets a place.** The scene is built by **all** of these people and companies. A sound engineer who's mixed 500 shows has a story to tell. A door person who's worked every Wednesday at a venue for three years is part of that venue's identity. A photographer who's shot every edition of a festival has a body of work tied to that event. A van rental company that's supplied transport for 200 tours has a track record. A catering company that feeds artists at festivals has a reputation. People and organizations alike are Nostr identities. A rental house, a production company, a catering service — they all have pubkeys, they all get tagged on rosters, they all build history. The roster doesn't distinguish between humans and companies as a matter of protocol — they're all participants. The roster makes all of this visible, searchable, and permanent. ### Scene Police Validation This is the crucial social mechanism that makes the roster trustworthy without a centralized authority. **The problem with self-reported credentials:** Anyone can claim they did sound at a famous venue. Anyone can put "tour manager for Band X" on their LinkedIn. There's no verification. The music scene runs on personal knowledge — "yeah, I know they're legit, I've seen them work" — but that knowledge doesn't scale beyond your immediate network. **The roster's solution:** Distributed social validation. 1. **The event creator** (usually the promoter or venue) updates the calendar event with the initial roster, tagging participants by Nostr pubkey and role. 2. **Tagged participants** receive the tag and can **confirm** their involvement. A confirmation is a signed Nostr event — cryptographic proof that this person acknowledges their role. 3. **Other scene members who were there** can publish **attestations** — "I was at this show, can confirm that [pubkey] did FOH." These are independent signed events referencing the roster. 4. **Disputes** are visible too. If someone is incorrectly listed, they can deny their involvement, or others can flag inaccuracies. This creates a **web of social proof** that is nearly impossible to fake at scale. The music scene is small enough — especially at the local level — that bullshit gets called out instantly. If you claim you did sound at a show and you didn't, someone who was actually there will flag it. If a promoter lists a fake roster to inflate their event's prestige, the people who were actually there will correct the record. It's not a centralized verification system. There's no "verified" badge from Musiquay. It's the **scene itself** doing the validation — peer review by the people who were in the room. Think of it like LinkedIn endorsements, except they actually mean something, because the community is small enough that everyone knows everyone, and the protocol makes every claim and counter-claim visible and signed. ### Wiki-Style Open Editing The roster is **open like Wikipedia**. Anyone can contribute, not just the event creator. The event creator (usually the promoter or venue) updates the calendar event with the initial roster. But they don't know everything. They might not know the name of the fill-in drummer. They might forget who did monitors. They might not have tagged the photographer because they didn't hire them — the photographer came independently. So the roster is open: - **Were you at the show and noticed the roster is missing the lighting tech?** Add them. - **Know who designed the poster?** Tag them. - **Were you the session musician who sat in on two songs?** Add yourself. - **Know the van driver's name?** Add them. Contributions from anyone are published as Nostr events that reference the roster. The scene fills in the gaps collectively, exactly like a wiki. And the validation mechanisms still apply — the tagged person can confirm or deny, and scene police validation ensures accuracy over time. This means rosters get **richer over time**. The initial post-show roster might be 15 people. A week later, community contributions have filled it out to 25. A month later, someone remembers the name of the door person and adds them. The record is always growing, always being refined by the people who were there. ### Setlists Every show should have setlists. This is huge — for fans, for the bands, and for the historical record. **What setlists capture:** - The songs played, in order, per artist/band that performed. - Songs **linked to their published tracks on Musiquay** when available. A setlist entry for "Song X" links directly to the track event, connecting live performance to recorded work. - **Featured artists as structured data.** If a guest musician came up for a song, that's not a footnote — it's a tagged, structured feature: "Song X — feat. Artist Y (live)." Both the performing artist and the guest can confirm the feature. - Set length, encore breaks, and any notable moments can be annotated. **Setlists are wiki-style too.** The band can publish their own setlist. Fans who were there can contribute from memory if the band doesn't post one. Band members can confirm or edit fan-submitted setlists. The same scene police validation applies — if someone posts a wrong setlist, people who were actually there will correct it. **The data this creates is incredible:** - **How often does a band play a certain song?** Query all setlists where the band is tagged — instant play frequency analysis. - **When was the last time they played this deep cut?** Searchable history across all shows. - **Which songs always feature guest appearances?** Cross-reference setlist features with artist tags. - **Set evolution over a tour.** Compare setlists across dates to see how the set changed night to night. - **Statistical rarity.** "This song has only been played 3 times in the last 2 years" — fans care about this deeply. - **Live debut tracking.** "First time this song was played live" — significant moments in a band's history, documented and timestamped on the protocol. Setlists bridge the gap between the **recorded music** (tracks on Musiquay) and the **live experience** (calendar events and rosters). A track's page can show: "This song has been performed live 47 times, most recently at [linked event]." An event page shows the full setlist with links to the studio recordings. ## How It Works ### Lifecycle of a Roster ``` ┌─────────────────────────────────────────────────────────┐ │ 1. PRE-EVENT │ │ Calendar event published with initial p tags │ │ (performers, confirmed crew) │ ├─────────────────────────────────────────────────────────┤ │ 2. EVENT HAPPENS │ │ The actual show / festival / event takes place │ ├─────────────────────────────────────────────────────────┤ │ 3. ROSTER PUBLISHED │ │ Event creator updates the calendar event │ │ with known participants and roles │ ├─────────────────────────────────────────────────────────┤ │ 4. COMMUNITY CONTRIBUTIONS (wiki-style) │ │ Anyone can add missing participants, setlists, │ │ corrections. The scene fills in the gaps. │ ├─────────────────────────────────────────────────────────┤ │ 5. CONFIRMATIONS │ │ Tagged participants confirm their involvement │ │ (signed events = cryptographic proof) │ ├─────────────────────────────────────────────────────────┤ │ 6. ATTESTATIONS │ │ Other scene members vouch for participants │ │ ("I was there, can confirm X did monitors") │ ├─────────────────────────────────────────────────────────┤ │ 7. DISPUTES (if any) │ │ Incorrect entries flagged by participants or │ │ witnesses. Visible to all. │ ├─────────────────────────────────────────────────────────┤ │ 8. PERMANENT RECORD │ │ Roster + contributions + setlists + │ │ confirmations + attestations = │ │ the scene's verified history │ └─────────────────────────────────────────────────────────┘ ``` ### Step 1: Pre-Event When a calendar event is published (NIP-52, kind 31923), it already includes `p` tags for confirmed participants — the performing artists, maybe the confirmed sound engineer, the photographer. This is the pre-show lineup. But the pre-event tags are incomplete by nature. You know who's performing. You might not know who's doing monitors or working the door until the night itself. ### Step 2: The Show Happens Real life. Music. People doing their jobs. ### Step 3: Roster Published After the event, the event creator (or a designated person — the stage manager, the venue manager, whoever is responsible) **updates the calendar event** with the full roster. The NIP-52 kind 31923 event is addressable and role-bearing, so the post-show update replaces the pre-show listing with the participants and roles they actually know about. The roster extends the pre-event `p` tags with the fuller picture: who actually did sound, who worked the door, which session musician sat in, who shot photos. But the initial roster is rarely complete — which is why the next step exists. ### Step 4: Community Contributions The roster is open for wiki-style editing. **Anyone can add missing entries:** - A fan who noticed the lighting tech isn't listed can tag them. - A session musician who sat in on two songs can add themselves. - The poster designer who wasn't at the show can tag themselves onto the roster after seeing it. - Anyone who knows the van driver or the catering company can add them. Contributions are separate Nostr events that reference the roster — they don't overwrite the original, they augment it. The client UI aggregates the original roster plus all contributions into a unified view. Tagged participants still confirm or deny (Step 5), and scene police validation still applies. Wiki-style editing makes the roster richer; validation makes it trustworthy. ### Step 5: Confirmations Each tagged participant receives a notification (they're tagged with their pubkey). They can publish a **confirmation event** — a signed Nostr event that says "yes, I was there, I did this role." A confirmation is lightweight but powerful: - It's **cryptographically signed** by the participant's key. Nobody else can forge it. - It's a **public, permanent statement** that this person acknowledges this work. - It **links their identity** to this event in the scene graph. Participants can also **decline** a tag if it's wrong — "I wasn't at this show" or "I wasn't the FOH engineer, I did monitors." ### Step 6: Attestations Beyond self-confirmation, **anyone who was there** can publish attestation events. These are third-party vouches: - "I was at this show. Can confirm [pubkey] did FOH — great mix." - "I was working the festival. [pubkey] handled stage management for the main stage." - "I shot photos at this event. [pubkey] was definitely on sound." Attestations are separate signed events that reference the roster. They create a mesh of social proof around the record. ### Step 7: Disputes The system is transparent about disagreements: - A participant can **deny** a roster entry — "I'm tagged as lighting tech but I wasn't there that night." - A witness can **flag** an inaccuracy — "The roster says X did sound but it was actually Y." - Disputes are visible events on the protocol. They don't delete the original claim — they add context. The scene can see the full picture: the claim, the counter-claim, and who signed each one. This isn't about automated resolution. It's about **visibility**. In a community where reputation matters, having a disputed roster entry is meaningful social information. ### Step 8: Permanent Record Over time, each event accumulates: - The original roster (published by the event creator) - Confirmations from participants - Attestations from witnesses - Any disputes or corrections This composite record becomes the **permanent, socially-validated history** of the event. It exists on the protocol, replicated across relays, cryptographically signed by the people who were there. ## Data Model ### Roster Event (NIP-52 kind 31923) The roster is the calendar event itself, updated post-show with the full participant record. No new kind: the event is addressable, and NIP-52 `p` tags already carry roles. ```json { "kind": 31923, "pubkey": "", "content": "Optional notes about the event — 'Great night, sold out, 3 encores.'", "tags": [ ["d", ""], ["title", "Friday Night at Lux Frágil"], ["start", "1735851600"], ["end", "1735876800"], ["D", "20090"], ["location", "Lux Frágil, Av. Infante Dom Henrique, Lisboa"], ["g", "eyckch"], ["p", "", "wss://relay.musiquay.com", "promoter"], ["p", "", "wss://relay.musiquay.com", "venue"], ["p", "", "wss://relay.musiquay.com", "sound-foh"], ["p", "", "wss://relay.musiquay.com", "sound-monitors"], ["p", "", "wss://relay.musiquay.com", "lighting"], ["p", "", "wss://relay.musiquay.com", "stage-manager"], ["p", "", "wss://relay.musiquay.com", "performer-headliner"], ["p", "", "wss://relay.musiquay.com", "performer-session"], ["p", "", "wss://relay.musiquay.com", "performer-support"], ["p", "", "wss://relay.musiquay.com", "performer-guest"], ["p", "", "wss://relay.musiquay.com", "backline"], ["p", "", "wss://relay.musiquay.com", "road-crew"], ["p", "", "wss://relay.musiquay.com", "door"], ["p", "", "wss://relay.musiquay.com", "bar"], ["p", "", "wss://relay.musiquay.com", "security"], ["p", "", "wss://relay.musiquay.com", "photographer"], ["p", "", "wss://relay.musiquay.com", "filmmaker"], ["p", "", "wss://relay.musiquay.com", "designer"], ["p", "", "wss://relay.musiquay.com", "van-driver"], ["p", "", "wss://relay.musiquay.com", "van-rental"], ["p", "", "wss://relay.musiquay.com", "pa-rental"], ["p", "", "wss://relay.musiquay.com", "catering-company"] ] } ``` **Design notes:** - No `a` tag needed — the roster IS the calendar event. The planned lineup and the actual record share one address; pre-show the event carries confirmed performers, post-show it carries the full roster. - The post-show update **keeps all calendar fields** (title, start/end, `D`, location, geohash) — only the `p` tags are replaced with the full participant record. The event remains a valid NIP-52 calendar event. - The `p` tag's fourth field (role) uses a structured vocabulary of role identifiers. NIP-52 already supports `p` tags with a role field — the roster extends this with a richer, standardized role vocabulary. - A single person can appear multiple times with different roles (e.g., someone who did sound AND played in the support act). - The roster is an **addressable event** — the creator can update it (add forgotten participants, correct roles) and the latest version replaces the previous one. ### Role Vocabulary A standardized but extensible set of role identifiers: | Category | Role IDs | Description | |----------|----------|-------------| | **Organization** | `promoter`, `booking-agent`, `venue`, `label`, `sponsor` | Who made the event happen | | **Sound** | `sound-foh`, `sound-monitors`, `sound-broadcast`, `sound-recording` | Audio engineers | | **Technical** | `lighting`, `stage-manager`, `backline`, `av-tech`, `rigger` | Technical production | | **Performance** | `performer-headliner`, `performer-support`, `performer-session`, `performer-guest`, `performer-dj`, `performer-mc` | Anyone who performed | | **Crew** | `road-crew`, `tour-manager`, `merch`, `van-driver` | Touring and logistics | | **Venue Staff** | `door`, `bar`, `security`, `venue-manager`, `venue-tech`, `catering` | Venue operations and hospitality | | **Documentation** | `photographer`, `filmmaker`, `live-stream`, `journalist`, `reviewer` | Event documentation | | **Creative** | `designer`, `vj`, `visual-artist` | Visual and design contributions | | **Service Companies** | `van-rental`, `backline-rental`, `pa-rental`, `lighting-rental`, `catering-company`, `production-company`, `studio` | Companies and organizations that provided services or equipment | This vocabulary is a convention, not a rigid schema. The community will evolve it. New roles can be added simply by using new role identifiers — no protocol change required. ### Confirmation Event (NIP-32 kind 1985) A participant confirms their roster entry. A NIP-32 label event: the participant labels the roster event address and their own pubkey. ```json { "kind": 1985, "pubkey": "", "content": "Optional comment — 'Great gig, crowd was amazing.'", "tags": [ ["a", "31923::", "wss://relay.musiquay.com"], ["p", ""], ["L", "musiquay.credit"], ["l", "confirmed", "musiquay.credit"], ["role", "sound-foh"] ] } ``` **Label values:** - `confirmed` — "Yes, I was there, this is accurate." - `denied` — "This is incorrect, I was not involved in this role." - `corrected` — "I was there, but my role was different." (The `role` tag carries the correct role.) Kind `1985` is regular, so a person can publish several. Clients SHOULD treat the latest `created_at` for a given `(signer, target, role)` as the current state, tie-broken by lowest event id, and keep the earlier ones visible as history. A denial never removes the roster entry. The confirmation is **signed by the participant's key**. This is cryptographic proof of acknowledgment — nobody can forge a confirmation on someone else's behalf. NIP-32 supports self-reporting (`l` tags on the author's own events) and third-party labeling, so the same kind covers both "I confirm my role" and "I label someone else's role." ### Attestation Event (NIP-32 kind 1985) A third party vouches for a roster entry. Same kind, authored by a witness, targeting the roster address and the participant's pubkey. ```json { "kind": 1985, "pubkey": "", "content": "I was at this show. Can confirm the sound was incredible — [tagged engineer] absolutely nailed the mix.", "tags": [ ["a", "31923::", "wss://relay.musiquay.com"], ["p", ""], ["L", "musiquay.attest"], ["l", "attests", "musiquay.attest"], ["role", "sound-foh"] ] } ``` Attestations are independent events. Anyone can publish one. Their weight comes from the **attestor's own reputation** in the scene graph — an attestation from a well-known promoter carries more social weight than one from an anonymous account, not because the protocol treats them differently, but because the scene does. ### Contribution Event (NIP-22 kind 1111) A community member adds a missing participant to the roster (wiki-style). A NIP-22 comment scoped to the roster event: the content names the participant and role, the `p` tag carries the pubkey. NIP-32 is unsuitable here — a contribution carries values, not labels. ```json { "kind": 1111, "pubkey": "", "content": "Adding the lighting tech — pretty sure this was their first show at this venue.", "tags": [ ["A", "31923::", "wss://relay.musiquay.com"], ["K", "31923"], ["P", ""], ["a", "31923::", "wss://relay.musiquay.com"], ["e", "", "wss://relay.musiquay.com"], ["k", "31923"], ["p", ""], ["p", "", "wss://relay.musiquay.com"], ["role", "lighting"] ] } ``` The contributed participant goes through the same confirmation/attestation flow as any roster entry. The wiki-style contribution is a **suggestion** — the tagged person confirms, and the scene validates. ### Setlist Event (Kind 32213) A setlist for one artist/band at one event. ```json { "kind": 32213, "pubkey": "", "content": "Incredible set. Third encore was unexpected — first time they've played that song in 2 years.", "tags": [ ["a", "31923::", "wss://relay.musiquay.com"], ["p", "", "wss://relay.musiquay.com", "performer"], ["title", "Setlist: Band Name @ Lux Frágil, 2026-03-15"], ["song", "1", "Song Title One", ""], ["song", "2", "Song Title Two", ""], ["song", "3", "Song Title Three"], ["song", "4", "New Unreleased Song"], ["song", "5", "Song Title Five", "", "feat", ""], ["song", "6", "Cover Song Title", "", "cover", ""], ["encore", "1"], ["song", "7", "Deep Cut That Fans Lost Their Minds Over", ""], ["a", ""], ["a", ""], ["a", ""], ["a", ""], ["t", "setlist"] ] } ``` **Setlist design notes:** - **Song-to-track linking:** When a song has a published track on Musiquay, the setlist entry includes the track's address (`32210::` — tracks are addressable, so the address not the event id is the stable link; see [FEATURES_MUSIC.md](./FEATURES_MUSIC.md)). This creates a direct link between live performance and recorded work. A track's page can show: "Performed live 47 times, most recently at [linked event]." - **Indexed track links:** the `song` tag is multi-letter and therefore not indexed by relays, so the setlist also carries one single-letter `["a", ""]` tag per **published** song, in set order. That makes "every live performance of this track" a plain `{"#a":[""]}` query instead of a full scan. Unreleased songs have no `a` tag until the track is published. - **Featured artists:** Guest appearances are first-class data. "Song X — feat. Artist Y (live)" is a structured tag with both the song reference and the guest's pubkey. Both the performing artist and the guest can confirm the feature. - **Encore markers:** Encores are tagged as structural breaks in the setlist. - **Covers:** Songs that are covers can note the original artist. - **Unreleased songs:** Songs not yet published on Musiquay can still appear — they just lack a track event link. When the track is eventually published, the link can be added. - **Wiki-style authoring:** Anyone can publish a setlist — the band, a fan who was there, a crew member. Band members can confirm fan-submitted setlists. Multiple versions may exist; confirmed versions take precedence. ## Scene Police Validation This is where the roster becomes something no centralized platform can replicate. ### Why It Works The music scene is a **high-trust, high-visibility community**, especially at the local level. Everyone knows everyone. If you've been going to shows in a city for a few years, you recognize the sound engineers, the photographers, the door people, the promoters. You know who does what. This social reality is what makes roster validation work: - **Claim something false** → someone who was actually there will see it and flag it. The scene is too small for bullshit to go unnoticed. - **Confirm something true** → multiple people who were there can independently vouch for it. The confirmation count grows organically. - **Dispute arises** → both sides are visible on the protocol. The community can see who's making what claim and judge for themselves. There is no automated resolution. No algorithm deciding who's right. No centralized moderator. The **visibility** of claims and counter-claims is the mechanism. In a community where reputation is everything, having a disputed or unconfirmed roster entry is meaningful information. ### Trust Signals The client UI can surface trust signals without making centralized judgment calls: - **Confirmation count** — how many of the roster's participants have confirmed? - **Attestation count** — how many independent witnesses have vouched? - **Attestor reputation** — are the attestors themselves well-connected in the scene graph? (Not a score — just visibility into who they are.) - **Dispute presence** — are there any denials or corrections? If so, display them. - **Creator reputation** — does the roster creator (promoter/venue) have a history of accurate rosters? None of these are hard verification. They're **social signals** — the same kind of judgment calls people make in real life when deciding whether to trust someone's credentials, now made visible and queryable at scale. ### Anti-Gaming The roster system is resistant to manipulation because: 1. **Confirmations require the participant's private key.** You cannot confirm someone else's roster entry. 2. **Attestations are signed and attributable.** Fake attestations are traceable to the attesting pubkey, which has its own reputation. 3. **The scene graph provides context.** A sound engineer with 200 confirmed roster entries and relationships with dozens of known venues has a credibility profile that's extremely expensive to fabricate. 4. **The community is the arbiter.** In small-to-medium scenes, fabrication is socially costly. People talk. Bullshit travels fast. 5. **History is immutable.** Once confirmations and attestations are published and replicated, they can't be silently removed. The record persists. ## Building the Scene Graph Every confirmed roster entry is a **node in the scene graph** that creates connections and builds history. ### Professional History (IMDb for the Scene) The roster turns every participant's profile into a living CV: - **Sound engineer's profile** → "Mixed 147 shows at 23 venues over 3 years. Confirmed by artists, attested by promoters." - **Photographer's profile** → "Shot 89 events. Work tagged in galleries for 12 festivals." - **Venue's profile** → "Hosted 412 events. Full rosters available for the last 2 years." - **Promoter's profile** → "Organized 67 events across 8 venues. Full cast and crew documented." This history is **earned, not claimed**. It's built event by event, confirmation by confirmation. It cannot be inflated by self-reporting — it requires the participation of others. ### Connection Mapping Rosters create a dense web of "worked together" relationships: - "Engineer X and Artist Y have worked together 12 times across 4 venues." - "Photographer Z has covered every event by Promoter W for the last year." - "These 5 people have been part of the crew for every edition of Festival F." These connections emerge from roster data without anyone explicitly declaring them. The relationships are implicit in the shared event history. ### Discovery Queries The roster feeds discovery across the platform: - "Find FOH engineers who have worked at venues with 500+ capacity in Lisbon." - "Find photographers who have covered shows featuring artists I follow." - "Show me this venue's full crew history — who has worked there most often?" - "Find all events where Engineer X and Artist Y were both on the roster." - "Which sound engineers are most commonly confirmed by artists in the post-punk scene?" This is the professional network the scene has never had — and it builds itself, event by event, from the ground up. ## Integration with Other Pillars ### Calendar Integration The roster is the **post-event state** of the calendar event. - **Before the show:** The calendar event (NIP-52 kind 31923) has `p` tags for confirmed performers and known crew — the advance listing. - **After the show:** The same addressable event is updated with the complete picture — everyone who actually worked the event, including roles that were only filled on the night. - **The planned/actual history is preserved** — the pre-show version remains queryable by event id; clients that fetch the full replacement chain can show both: "Here's what was planned" and "Here's who actually made it happen." Post-event content (photos, reactions, reviews) attaches to the calendar event, creating a rich record of the event from every angle. ### Marketplace Integration The roster is the **reputation engine** that powers the [services marketplace](./FEATURES_MARKETPLACE.md). - A freelancer's marketplace listing ("FOH engineer available") is backed by their roster history. - When someone browses a marketplace listing, they can see: "This engineer has 147 confirmed roster entries, has worked at these venues, has been attested by these promoters." - The marketplace provides the **opportunity**. The roster provides the **proof**. ### Payment Integration Optionally, the roster can link to revenue distribution for the event. - If the event had ticket sales or door revenue, the roster can define payment splits by role. - "Sound engineer for this show" could mean an automatic Lightning payment via the existing payment infrastructure. - A promoter could set up: 5% to FOH, 3% to photographer, X% to each performer — all linked to the roster entries and settled via Lightning. **But this is optional.** The roster's primary value is the **record**, not the money. Payment integration is a powerful addition for events that choose to use it, but the roster stands on its own as a documentation and reputation system even without any financial component. ## NIP Strategy Following the project's reuse-first approach: | Concept | NIP Status | Notes | |---------|------------|-------| | **Participant tagging** | NIP-52 `p` tags with roles | Already exists — the roster extends the role vocabulary significantly | | **Roster event** | NIP-52 kind 31923 | The calendar event is addressable and already carries role-bearing `p` tags; updating it post-show with the full roster is spec-legal. | | **Confirmation** | NIP-32 kind 1985 | Label event by the participant: `a` tag to the roster event, `p` tag to self, namespace + label `confirmed`/`denied`/`corrected`, role in a `role` tag. | | **Attestation** | NIP-32 kind 1985 | Witness labels the roster address and the participant's `p` tag with an attestation label. | | **Contribution** | NIP-22 kind 1111 | Comment scoped to the roster via `A`/`K` tags; content names the participant and role, `p` tag carries the pubkey. NIP-32 is unsuitable here — a contribution carries values (pubkey, role), not labels. | | **Setlist** | Custom kind 32213 | No existing NIP covers setlists. Per-artist song list with track linking and featured artist tagging. | | **Event reference** | NIP-52 `a` tags | Standard mechanism for linking to addressable events | | **Deletion/correction** | NIP-09 | Standard deletion requests; corrections are new events that reference the original | The roster system requires **one custom event kind** (setlist, 32213). The roster itself reuses NIP-52 kind 31923, confirmations and attestations are NIP-32 label events, and contributions are NIP-22 comments. The setlist kind should be proposed as a NIP once the design is validated — the concept has value beyond Musiquay and could serve any Nostr community that organizes events. ## UI Concepts ### Event Page — Post-Show View After a show, the event page transitions from "upcoming event" to "event record": - **Full roster** displayed with all roles, grouped by category (including service companies). - **Confirmation status** visible per entry — confirmed, pending, disputed. - **Attestation count** per entry. - **Setlists** for each performing artist — songs linked to studio tracks where available, featured artists tagged and linked. - **"Add to roster" button** — wiki-style, anyone can contribute missing participants. - **"Add setlist" button** — fans and band members can contribute setlists. - **Post-event content** — photos, reactions, reviews from attendees, all linked to the event. - **Audio/video** if the show was recorded — linked from blossom servers. ### Profile Page — Work History Each participant's profile includes a "Roster" or "Credits" section: - Chronological list of events they've been part of, with roles. - Filterable by role, venue, date range. - Confirmation and attestation counts visible. - Links to the full event record for each entry. - For artists: setlist history — which songs played where, guest appearances given and received. ### Track Page — Live History Each published track gains a "Played Live" section: - Every setlist entry that links to this track, with event date and venue. - Featured guest appearances on this song across all performances. - "First played live" and "most recently played" timestamps. - Play frequency — how often this song appears in setlists relative to total shows. ### Discovery — Reputation at a Glance When viewing a marketplace listing or a profile: - **Roster count** — total confirmed roster entries. - **Venue diversity** — how many different venues they've worked at. - **Peer confirmation rate** — what percentage of their roster entries have been confirmed by others? - **Top connections** — which artists, venues, and promoters appear most often in their roster history? None of this is a "score." It's structured data that people can interpret with their own judgment — the same way you'd evaluate someone's CV, but with cryptographic proof backing every line.