RFC: atproto-backed Conference and Community Directory (events ↔ people ↔ packages)

[farisaziz12]

Summary

Add a Conference and Community directory to npmx that links events, people (maintainers), and packages using atproto identities (DIDs) as the underlying data layer.

Conferences publish structured event records from their atproto accounts. People optionally publish appearance records. npmx materializes a browsable graph on-demand by resolving signed atproto records and npm registry data, then caching the derived view:

events ↔ people ↔ packages

This turns npmx into a discovery layer for open-source communities, beyond code artifacts.

This issue is being spawned from the original idea posted in the Discord here. This also would not have been possible without significant support from @Nadjaroemer, therefore consider this RFC owned by the both of us :)

---

Motivation

Open-source ecosystems are social systems. Packages are maintained by people, and those people show up at conferences, community meetups, workshops, podcasts, panels, and other events. Today, that social layer exists, but package infrastructure does not model it. One of the main reasons people attend conferences is to connect with maintainers and learn about how the ecosystem is moving, and learn from it! The aim of this proposal is to have npmx help surface those connections.

This matters significantly for attracting new contributors to open source packages. If npmx can show “who maintains this” and “where they show up publicly”, it lowers the barrier to learning, networking, and eventually contributing.

I've even heard of an instance where, at an NG (Angular) conference, the Angular team themselves were present at a booth, sat down with a potential contributor for a live onboarding where they picked a new issue, worked on it together till it was shipped. Newcomers should be able to more easily find these incredible opportunities

---

Goals

• Conference/Meetup Organizers can authenticate with atproto and publish identity-backed organization plus event records
• SEO-friendly routes for organizers and events
• Queryable relationships between:
  • events (conferences, meetups)
  • people (maintainers, contributors)
  • packages
• Browsing experiences:
  • from a package page, see relevant events and appearances
  • from a person page, see packages and upcoming appearances
  • from an event edition page, see appearing people and represented packages (derived)
• Organizers can publish and update their own event data

---

Non-goals

• Ticketing, scheduling systems, or replacing conference websites
• Real-time attendance tracking
• Mandatory user tracking or precise location storage
• Automatic scraping of all conference sites

---

Proposed UX

Package page

On a package page like @tanstack/react-query, show an Events section near Maintainers/Provenance:

• upcoming events where a maintainer appears (opt-in appearances)
• represented events derived from maintainer appearances
• links to event pages and person pages

Person page

Add an “Events” page for a user:

• /~:username/events lists upcoming and past appearances (opt-in)

Event pages

For each event edition (example: “ZurichJS 2026”):

• location, dates, website link
• people appearing (only opt-in/confirmed appearances in the canonical list)
• packages represented (derived from maintainer appearances)

---

Terminology

• Event: a single occurrence with dates(one day or multiple), location and type (conference, meetup) and format (online, in_person, hybrid)
• Organization: an organizing body, hosting events, with a one-to-many relationship with events (e.g., ZurichJS)
• Actor: an identity backed by atproto DID, can be an org or person
• Person: an actor representing an individual maintainer/contributor
• Appearance: an opt-in public record by a person indicating participation in an event
• Representation: derived relationship, a package is represented at an event if a maintainer appears there

---

Design overview

Identity model

All actors are atproto identities (DIDs).

• Organizer accounts publish canonical event metadata (e.g. event title, date range, location, list of represented maintainers, either via speaking or attending)
• People publish opt-in appearance records
• npmx resolves and joins records on-demand to produce derived views

---

Data model (conceptual)

Core entities

• Organizer (actor DID)
• Event (organizer DID plus event slug plus date range)
• Person (actor DID)
• Package (npm package name plus registry metadata)
• Appearance (person DID → edition)
• Location (city, country)
• PackageClaim (person DID ↔ package, opt-in, role = maintainer | contributor)
• Representation (derived: edition ↔ package)

Relationship rules

• Appearance is explicitly published by a person (opt-in)
• Representation is derived:
  • if a person appears at an event
  • and that person is a maintainer of a package (as currently inferred)
  • then that package is “represented” at that edition

Contributors can appear, but do not create representation by default. Maintainers do.

---

Graph model

graph TD
  O[Organization] --> E[Event]
  P[Person] --> A[Appearance]
  A --> E
  P --> PC[Package Claim]
  PC --> N[Package]
  P --> M[Maintainer Of]
  M --> N
  E --> R[Representation]
  R --> N

Loading

Future extension: personalized discovery (optional)

Opt-in feature:

• infer relevant events from a user’s dependency graph
• notify when maintainers of dependencies appear at nearby events

Considerations

A few things to think through so this doesn’t get noisy, stale, or gamed over time.

Freshness and “stale directory” prevention

• Organization activity requirement: an organization should publish at least one event per year to remain discoverable in the main directory.
  • If inactive, it can be moved to an “inactive” state (still accessible via direct link in order to not create link rot via external references, but not promoted in browse/search).
• Event expiry: events should automatically move from “upcoming” to “past” once the end date passes, and eventually collapse behind pagination or filters.
• Appearance expiry: appearances should be time-bounded to the event date range, and not linger as “upcoming” if the event record changes or disappears.

Note:

I'd love to implement this with the support of @Nadjaroemer and whoever else would be keen to iterate/ideate over what the final implementation could be. While I, @farisaziz12 am new to atproto based integrations and Nuxt overall, I have written up the proposal to the best of my knowledge on how the system/repo currently works. Would love some feedback and feel free to point out any misunderstandings so that we can evolve the RFC into a state we are happy to break it down and implement.

Additional information

• Would you be willing to help implement this feature?

Final checks

• Read the contribution guide.
• Check existing issues.

[Tobbe]

• Organizer accounts publish canonical event metadata (e.g. event title, date range, location, list of represented maintainers, either via speaking or attending)

"either via speaking, attending or sponsoring" maybe? The NG booth story made me think of "sponsoring" as separate from speaking and attending. Even if "speaking" is technically more like a subset of "attending", which "sponsoring" would also be.

Core entities

• Organizer (actor DID)
• Event (organizer DID plus event slug plus date range)

"location" might be worth to include in Event here as well. I think location is really important.

How do we want to handle remote/virtual events vs IRL-events? And there are also the hybrid events, where some speakers are doing remote talks, or where one day is IRL and other is fully remote for everyone etc

Over all I'm really excited about this proposal! Well done with the writeup @farisaziz12 and @Nadjaroemer 👏

[ElianCodes]

First of all, this is an amazing idea and I'm all for it. I do have some notes and questions, feel free to ask further:

Questions & Considerations

Trust & Abuse Prevention

• How do we prevent fake organizer accounts or fake “appearance” records from visibility?
• Is there any verification or reputation layer planned for organizers?
• Can maintainers dispute or flag incorrect representations of their packages at events?

atproto Dependency & Lock-in

• Do we envision supporting additional identity providers later (e.g. GitHub, email-verified, OAuth)?

Data Freshness & Staleness

• What happens if:
  • an event record disappears?
  • an organizer becomes inactive?
  • a DID rotates or an identity is abandoned?
• Is there a cleanup mechanism for outdated appearances or stale representations?

Privacy & Consent

• Can people limit visibility of appearances (e.g. show upcoming only, hide past events)?
• Can people opt into partial visibility (e.g. appear without a public profile)?

UX & Noise Control

• How do we avoid overwhelming package pages with noisy or low-signal event listings?
• Will events be ranked or filtered (by relevance, proximity, recency, popularity)?

Moderation & Disputes

• What’s the moderation model for false claims or spammy stuff?
• Can organizers remove or flag appearances that are incorrect?
• Is there an appeal flow if someone is wrongly associated with an event or package?

Event Modeling

• How do we model:
  • virtual vs IRL vs hybrid events?
  • speaking vs attending vs sponsoring vs booth presence?
  • multi-day events with different formats per day (for instance JSNation vs React Summit or VueJS Amsterdam vs JSWorld)?

MVP Scope

• What’s the smallest viable version that could ship?
  • Only events + people?
  • No derived package representation at first?
  • Manual verification for early organizers?
• What’s explicitly out of scope for v1 to avoid scope creep?

[Nadjaroemer]

Wow @Tobbe and @ElianCodes these are amazing comments and thoughts! Thank you for taking the time! This is an exciting chance to connect OSS contributors and grow the network and it would be wonderful to have many people involved in making it happen.

[Tobbe]

Can maintainers dispute or flag incorrect representations of their packages at events?

I think only allowing package maintainers (as indicated by GitHub, GitLab etc) to add package representation at events would solve this, right?

atproto Dependency & Lock-in

• Do we envision supporting additional identity providers later (e.g. GitHub, email-verified, OAuth)?

Maybe we can lean on @orta's https://keytrace.dev for identity

Data Freshness & Staleness

• What happens if:

  • an event record disappears?
  • an organizer becomes inactive?
  • a DID rotates or an identity is abandoned?

• Is there a cleanup mechanism for outdated appearances or stale representations?

I'd put all of this in the "future me problem" bucket (future me always hates past me 😅)

Privacy & Consent

• Can people limit visibility of appearances (e.g. show upcoming only, hide past events)?
• Can people opt into partial visibility (e.g. appear without a public profile)?

I must be missing something here. And I'm generally not very privacy concerned. But I'm thinking of this entire feature akin to announcing on bsky that I'll attend a conference. If I'm not comfortable having this permanently on the internet I wouldn't post it. I'm probably naïve here though, so please help me correct my view :)

How do we avoid overwhelming package pages with noisy or low-signal event listings?

This is a very valid concern. npmx already has a lot going on on the package pages already!

Moderation & Disputes

• What’s the moderation model for false claims or spammy stuff?
• Can organizers remove or flag appearances that are incorrect?
• Is there an appeal flow if someone is wrongly associated with an event or package?

See me previous comment about verifying against GitHub/GitLab/etc. And also, I don't think anyone should be able to add someone else besides themselves as attending events.

The one thing left to solve, that I really don't know how to do, is "fake" attendance. How do we prevent people saying they're attending all-the-events? But again, this is the same as people posting on bsky that they're attending even if they're not

Event Modeling

• How do we model:

  • virtual vs IRL vs hybrid events?
  • speaking vs attending vs sponsoring vs booth presence?
  • multi-day events with different formats per day (for instance JSNation vs React Summit or VueJS Amsterdam vs JSWorld)?

This is what I tried to raise as well. Thanks for putting it in a much more clear bulleted form 😃

MVP Scope

• What’s the smallest viable version that could ship?

  • Only events + people?
  • No derived package representation at first?
  • Manual verification for early organizers?

• What’s explicitly out of scope for v1 to avoid scope creep?

This 👆 Thinking of the MVP is 100% the right thing to do now

[farisaziz12]

• Organizer accounts publish canonical event metadata (e.g. event title, date range, location, list of represented maintainers, either via speaking or attending)

"either via speaking, attending or sponsoring" maybe? The NG booth story made me think of "sponsoring" as separate from speaking and attending. Even if "speaking" is technically more like a subset of "attending", which "sponsoring" would also be.

Core entities

• Organizer (actor DID)
• Event (organizer DID plus event slug plus date range)

"location" might be worth to include in Event here as well. I think location is really important.

How do we want to handle remote/virtual events vs IRL-events? And there are also the hybrid events, where some speakers are doing remote talks, or where one day is IRL and other is fully remote for everyone etc

Over all I'm really excited about this proposal! Well done with the writeup @farisaziz12 and @Nadjaroemer 👏

"either via speaking, attending or sponsoring" maybe? The NG booth story made me think of "sponsoring" as separate from speaking and attending. Even if "speaking" is technically more like a subset of "attending", which "sponsoring" would also be.

For MVP, I’d avoid adding a sponsorship dimension. Three reasons:

• Sponsorship isn’t a person (thought you could argue the same for an event organizing body, but in my experience, it tends to be a consistent core team of sub 5 people). It’s usually a company, and even then it’s represented by multiple people (field marketing, devrel, partnerships, procurement). That immediately raises the question: who’s the “owner” of the relationship and contract on the platform?
• Contacts churn constantly. Sponsorship managers change hands all the time. In practice, organizers fulfill contracts through placements on their sites and assets, and keeping sponsor info accurate and consistent over time becomes ongoing maintenance with low upside.
• It’s not the core value. We can let organizers tag sponsors later if needed, but sponsors don’t feel like what people are actually searching for here. People come looking for maintainers, organizers, and events, not sponsor lists.

Did you see an alternative approach, @Tobbe?

"location" might be worth to include in Event here as well. I think location is really important.

You're spot on! Added this to the issue description, thanks for pointing it out 😊

How do we want to handle remote/virtual events vs IRL-events? And there are also the hybrid events, where some speakers are doing remote talks, or where one day is IRL and other is fully remote for everyone etc

That's a really good point! We could add an event dimension called format: "online" | "in_person" | "hybrid". Imo this should be at the event level, and we don't need to define online vs in-person representation at the speaker/attendee level, given the conference platform should define this, along with all three formats being considered valid "representations" of a maintainer or package. WDYT?

Over all I'm really excited about this proposal! Well done with the writeup @farisaziz12 and @Nadjaroemer 👏

Thank you for your support, time and energy ❤️

[farisaziz12]

Agree with all of the points @Tobbe made regarding flagging incorrect packages, atproto dependency lock-in and data freshness. Though I did try to cover the basics of this in the Freshness and “stale directory” prevention section of the issue (thought definitely no extensive enough for the amount of data we expect to go through this system)

As for privacy and consent managment:

I must be missing something here. And I'm generally not very privacy concerned. But I'm thinking of this entire feature akin to announcing on bsky that I'll attend a conference. If I'm not comfortable having this permanently on the internet I wouldn't post it. I'm probably naïve here though, so please help me correct my view :)

I believe this could be a double-edged sword. On the one hand, I agree that if you choose to put yourself out there and go to a conference, you will generally have your name, pic, etc on the conference website and should be happy with your information being permanently on the internet. That being said, everyone has the right to revoke their conference representation. Initially, I thought an organizer would be responsible for listing the GitHub usernames of the speakers at an event, serving as a proxy for consent management. After all, most organizing bodies have T&Cs, privacy policies, etc and abide by them.

Would we feel comfortable letting the organizing body manage these representations, and would someone who chooses to revoke representation contact the organizer? I don't see this happening very often and am concerned about us overcomplicating this technically for a very small edge case.

The one thing left to solve, that I really don't know how to do, is "fake" attendance. How do we prevent people saying they're attending all-the-events? But again, this is the same as people posting on bsky that they're attending even if they're not

As part of MVP, we should focus on speakers and controlled representation. I would postpone self-serve representation to a later stage, because you are right! Someone could technically spam represent themselves at all of the events.

Thank you for raising all of this @ElianCodes! Hopefully I've answered some of it by adding to, not duplicating, @Tobbe's points

[farisaziz12]

MVP

To answer the MVP question:

A small directory that lets orgs publish event editions and people publish appearances, then npmx shows (a) event pages, (b) person appearances.

User Stories

Organizer Stories

• As an organizer, I can publish an event edition record from my atproto identity so it becomes discoverable on npmx.
• As an organizer, I can update an event edition record so dates, location, or links stay current.
• As an organizer, I can add a list of GitHub usernames as tagged speakers/attendees for an event edition so the event page shows who’s expected.
• As an organizer, I can add or remove GitHub usernames after publishing so the list stays accurate.
• As an organizer, I can tag people without needing them to publish anything, but npmx will not treat that as a confirmed appearance.

Person Stories

• As a person, I can view a page showing events where organizers tagged my GitHub username, so I can decide what to do (opt in public appearance or not).
  • my only concern with this is people not reacting to the public appearance request, thus conferences being half misrepresented due to lack of action on the person's part, we could flip this where organizer tagging means auto-opt in and you can explicitly opt out. WDYT @ElianCodes @Tobbe @Nadjaroemer?
• As a person, I can opt out of being listed for a specific event so I’m removed from that event’s tagged list in npmx.
• As a person, I can globally opt out of appearing in organizer-tagged lists so organizers can’t list me via GitHub tags in npmx.

Visitor Stories

• As a visitor, I can view an organizer page to see all editions they published.
• As a visitor, I can browse a directory of upcoming events so I can discover conferences and meetups.

[Tobbe]

Thanks for keeping this issue moving forward @farisaziz12

"list of GitHub usernames", "add or remove GitHub usernames" etc. I think all of those should also support bsky handles, or keytrace identity.

I think we might be putting too much "power" (is that the right word?) in the hands of event organizers. I'd want this system to work without organizers' explicit participation.

I'm also missing the npm(x) package perspective. I want to know what packages are represented at a conference.

I think, in general, my view has been more from the attendees perspective, while it sounds (sorry if I'm wrong) your view is more from an enthusiastic organizer's perspective (and understandably so!)

And this also goes back to the "sponsor" thing we discussed. I thought of it more as an option in a dropdown. "How are you attending the event?" "Speaker", "Attendee", "Sponsor". And same for packages. The sponsor thing would just let the package maintainer say "This package will be represented by someone speaking at the conference", "This package will be sponsoring the conference, so come find us in the exhibition hall". Something like that.

Maybe we could have users (i.e. someone with an ATProto identity) mark their attendance at an event. And this is visible for everyone. Then we could, for event organizers that support the initiative and who want to spend the time to set it all up, mark users as attending. This would be hidden by default. But if the user themself have marked their attendance they could get some sort of "verified" badge/checkmark.

I know we said we didn't want to crowd the package page, and I still think that's important, but I'd very much would like to somehow be able to see on a package page what events maintainers of that package will be attending.

Love and hugs. I hope this all comes across in the best way possible <3
Might need @ElianCodes to come in and structure this all as a much more clear list of bullet points 😅

[farisaziz12]

"list of GitHub usernames", "add or remove GitHub usernames" etc. I think all of those should also support bsky handles, or keytrace identity.

valid point, we'd have to somehow interlink the GitHub username, bsky handle, or keytrack identity to make sure we can graph the underlying associated packages with the user, right? I'm not sure how to go about this.

I think we might be putting too much "power" (is that the right word?) in the hands of event organizers. I'd want this system to work without organizers' explicit participation.

Right you are! I may have been taking a pessimistic perspective. From my experience, I've seen more admin burden placed on the org end to make sure all the right info is in the right places than placing the participating burden on the participant. We can always evolve how this system works, and let's make sure no singular party gets "too much power" when it comes to how this information is represented. Thank you for calling that out

I'm also missing the npm(x) package perspective. I want to know what packages are represented at a conference.

This is the eventual yes, I was thinking for a V1 to strip out as much as possible, this could be something that comes out in V1.1 but we can definitely add it in scope, it is a matter of when not if

I think, in general, my view has been more from the attendees perspective, while it sounds (sorry if I'm wrong) your view is more from an enthusiastic organizer's perspective (and understandably so!)

You could be right! I'm potentially biased here, so appreciate being grounded. I'm drawing from experience on the attending, speaking, and org angle, but this system is meant for all of us, not some of us. So we need to shape it from that perspective.

And this also goes back to the "sponsor" thing we discussed. I thought of it more as an option in a dropdown. "How are you attending the event?" "Speaker", "Attendee", "Sponsor". And same for packages. The sponsor thing would just let the package maintainer say "This package will be represented by someone speaking at the conference", "This package will be sponsoring the conference, so come find us in the exhibition hall". Something like that.

Maybe we could have users (i.e. someone with an ATProto identity) mark their attendance at an event. And this is visible for everyone. Then we could, for event organizers that support the initiative and who want to spend the time to set it all up, mark users as attending. This would be hidden by default. But if the user themself have marked their attendance they could get some sort of "verified" badge/checkmark.

Imho we could potentially leave this as a stretch goal? We could be overcomplicating it from the start

I know we said we didn't want to crowd the package page, and I still think that's important, but I'd very much would like to somehow be able to see on a package page what events maintainers of that package will be attending.

yes! This is core to the whole proposal. I just want to make sure we can ship this in manageable chunks and not overhaul the UX in one go, but as I said, we can bring this into MVP/V1 scope and find a way to break it down into atomic shippable chunks.

Love and hugs. I hope this all comes across in the best way possible <3

it does and thank you! Love and hugs, all with the best intentions ❤️

[Tobbe]

This is the eventual yes, I was thinking for a V1 to strip out as much as possible, this could be something that comes out in V1.1 but we can definitely add it in scope, it is a matter of when not if

Sounds great! Definitely doesn't have to be part of the MVP

yes! This is core to the whole proposal. I just want to make sure we can ship this in manageable chunks and not overhaul the UX in one go, but as I said, we can bring this into MVP/V1 scope and find a way to break it down into atomic shippable chunks.

Totally on board with not having this be part of the MVP

Quoting myself here

Maybe we could have users (i.e. someone with an ATProto identity) mark their attendance at an event. And this is visible for everyone. Then we could, for event organizers that support the initiative and who want to spend the time to set it all up, mark users as attending. This would be hidden by default. But if the user themself have marked their attendance they could get some sort of "verified" badge/checkmark.

I understand this might sound like overcomplicating things. And I'm happy with making the "verified" stuff a stretch goal.

The only thing I'd like to push for is making this attendee-led vs organizer-led. I think this idea would get much more spread that way, which I hope will encourage more organizers to get on board. And either we trust the good in people + the strong identity tied to all of this to curb abuse. And/or we say we handle any bad actors when/if we see it happen. Or we find a less complicated way to make sure people don't try to game the system.
Also happy to be convinced I'm wrong here 🙂

[orta]

Keytrace claims would be good here at linking atproto accounts to npm logins (which is enough to know all the packages the author has access to, given that that info is public as maintainers in the packuments) 👍🏻

It may also be possible to go from github handle to atproto to npm but that'd need some data backfill, or an API or something, not possible today but maybe in the future

Here's some random notes:

• For meetups, folks have been using community.lexicon.calendar.rsvp - see mine for the atproto london

• I think the underlaying tools for the atmosphere conference 2026 are openmeet? https://platform.openmeet.net/events/atmosphereconf-2026-ohxxfm which I don't think is putting data on the registry (or would be in their attendee list)