From the promoter to the girl pouring beer at the bar, everyone. Well structured, in the same place. Scene police validation.
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, the services marketplace, and the scene graph. It's how Musiquay becomes the definitive record of the music scene.
Musiquay's roster system doesn't require official confirmation to be useful. The system is designed to embrace ambiguity rather than demand certainty.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Every show should have setlists. This is huge — for fans, for the bands, and for the historical record.
What setlists capture:
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:
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.
┌─────────────────────────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────────────────────────┘
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.
Real life. Music. People doing their jobs.
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.
The roster is open for wiki-style editing. Anyone can add missing entries:
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.
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:
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."
Beyond self-confirmation, anyone who was there can publish attestation events. These are third-party vouches:
Attestations are separate signed events that reference the roster. They create a mesh of social proof around the record.
The system is transparent about disagreements:
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.
Over time, each event accumulates:
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.
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.
{
"kind": 31923,
"pubkey": "<event-creator-pubkey>",
"content": "Optional notes about the event — 'Great night, sold out, 3 encores.'",
"tags": [
["d", "<calendar-event-d-tag>"],
["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", "<promoter-pubkey>", "wss://relay.musiquay.com", "promoter"],
["p", "<venue-pubkey>", "wss://relay.musiquay.com", "venue"],
["p", "<foh-engineer-pubkey>", "wss://relay.musiquay.com", "sound-foh"],
["p", "<monitor-engineer-pubkey>", "wss://relay.musiquay.com", "sound-monitors"],
["p", "<lighting-pubkey>", "wss://relay.musiquay.com", "lighting"],
["p", "<stage-manager-pubkey>", "wss://relay.musiquay.com", "stage-manager"],
["p", "<headliner-pubkey>", "wss://relay.musiquay.com", "performer-headliner"],
["p", "<session-musician-pubkey>", "wss://relay.musiquay.com", "performer-session"],
["p", "<support-act-pubkey>", "wss://relay.musiquay.com", "performer-support"],
["p", "<guest-pubkey>", "wss://relay.musiquay.com", "performer-guest"],
["p", "<backline-tech-pubkey>", "wss://relay.musiquay.com", "backline"],
["p", "<road-crew-pubkey>", "wss://relay.musiquay.com", "road-crew"],
["p", "<door-pubkey>", "wss://relay.musiquay.com", "door"],
["p", "<bar-staff-pubkey>", "wss://relay.musiquay.com", "bar"],
["p", "<security-pubkey>", "wss://relay.musiquay.com", "security"],
["p", "<photographer-pubkey>", "wss://relay.musiquay.com", "photographer"],
["p", "<filmmaker-pubkey>", "wss://relay.musiquay.com", "filmmaker"],
["p", "<designer-pubkey>", "wss://relay.musiquay.com", "designer"],
["p", "<van-driver-pubkey>", "wss://relay.musiquay.com", "van-driver"],
["p", "<van-rental-company-pubkey>", "wss://relay.musiquay.com", "van-rental"],
["p", "<pa-rental-pubkey>", "wss://relay.musiquay.com", "pa-rental"],
["p", "<catering-pubkey>", "wss://relay.musiquay.com", "catering-company"]
]
}
Design notes:
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.D, location, geohash) — only the p tags are replaced with the full participant record. The event remains a valid NIP-52 calendar event.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 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.
A participant confirms their roster entry. A NIP-32 label event: the participant labels the roster event address and their own pubkey.
{
"kind": 1985,
"pubkey": "<participant-pubkey>",
"content": "Optional comment — 'Great gig, crowd was amazing.'",
"tags": [
["a", "31923:<event-creator-pubkey>:<calendar-event-d-tag>", "wss://relay.musiquay.com"],
["p", "<participant-pubkey>"],
["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."
A third party vouches for a roster entry. Same kind, authored by a witness, targeting the roster address and the participant's pubkey.
{
"kind": 1985,
"pubkey": "<witness-pubkey>",
"content": "I was at this show. Can confirm the sound was incredible — [tagged engineer] absolutely nailed the mix.",
"tags": [
["a", "31923:<event-creator-pubkey>:<calendar-event-d-tag>", "wss://relay.musiquay.com"],
["p", "<participant-being-vouched-for-pubkey>"],
["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.
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.
{
"kind": 1111,
"pubkey": "<contributor-pubkey>",
"content": "Adding the lighting tech — pretty sure this was their first show at this venue.",
"tags": [
["A", "31923:<event-creator-pubkey>:<calendar-event-d-tag>", "wss://relay.musiquay.com"],
["K", "31923"],
["P", "<event-creator-pubkey>"],
["a", "31923:<event-creator-pubkey>:<calendar-event-d-tag>", "wss://relay.musiquay.com"],
["e", "<roster-event-id>", "wss://relay.musiquay.com"],
["k", "31923"],
["p", "<event-creator-pubkey>"],
["p", "<missing-participant-pubkey>", "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.
A setlist for one artist/band at one event.
{
"kind": 32213,
"pubkey": "<author-pubkey>",
"content": "Incredible set. Third encore was unexpected — first time they've played that song in 2 years.",
"tags": [
["a", "31923:<event-creator-pubkey>:<calendar-event-d-tag>", "wss://relay.musiquay.com"],
["p", "<performing-artist-pubkey>", "wss://relay.musiquay.com", "performer"],
["title", "Setlist: Band Name @ Lux Frágil, 2026-03-15"],
["song", "1", "Song Title One", "<track-address-if-published>"],
["song", "2", "Song Title Two", "<track-address-if-published>"],
["song", "3", "Song Title Three"],
["song", "4", "New Unreleased Song"],
["song", "5", "Song Title Five", "<track-address>", "feat", "<guest-artist-pubkey>"],
["song", "6", "Cover Song Title", "", "cover", "<original-artist-name>"],
["encore", "1"],
["song", "7", "Deep Cut That Fans Lost Their Minds Over", "<track-address>"],
["a", "<track-address-1>"],
["a", "<track-address-2>"],
["a", "<track-address-5>"],
["a", "<track-address-7>"],
["t", "setlist"]
]
}
Setlist design notes:
32210:<publisher-pubkey>:<d-tag> — tracks are addressable, so the address not the event id is the stable link; see 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]."song tag is multi-letter and therefore not indexed by relays, so the setlist also carries one single-letter ["a", "<track-address>"] tag per published song, in set order. That makes "every live performance of this track" a plain {"#a":["<track-address>"]} query instead of a full scan. Unreleased songs have no a tag until the track is published.This is where the roster becomes something no centralized platform can replicate.
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:
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.
The client UI can surface trust signals without making centralized judgment calls:
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.
The roster system is resistant to manipulation because:
Every confirmed roster entry is a node in the scene graph that creates connections and builds history.
The roster turns every participant's profile into a living CV:
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.
Rosters create a dense web of "worked together" relationships:
These connections emerge from roster data without anyone explicitly declaring them. The relationships are implicit in the shared event history.
The roster feeds discovery across the platform:
This is the professional network the scene has never had — and it builds itself, event by event, from the ground up.
The roster is the post-event state of the calendar event.
p tags for confirmed performers and known crew — the advance listing.Post-event content (photos, reactions, reviews) attaches to the calendar event, creating a rich record of the event from every angle.
The roster is the reputation engine that powers the services marketplace.
Optionally, the roster can link to revenue distribution for the event.
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.
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.
After a show, the event page transitions from "upcoming event" to "event record":
Each participant's profile includes a "Roster" or "Credits" section:
Each published track gains a "Played Live" section:
When viewing a marketplace listing or a profile:
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.