Background
The most widely used method for managing lists in nostr is via NIP-51: Lists. As a typical example, suppose Alice wants to create and maintain a list of Nostr Developers. Following the NIP-51 specification, she creates a kind 30000 replaceable event with the title: "Nostr Developers". Each item on the list is represented using a p-tag and the pubkey of a nostr developer. Because it is a replaceable event, she can add or remove items on the list whenever she wants.
But suppose she doesn't want to manage this list all by herself. Suppose she wants her trusted community to help her to curate this list. NIP-51 does not (by itself) prescribe how this might work.
Enter: the Decentralized Lists custom NIP. This NIP specifies a method for Alice to create a new list and for members of her trusted community to determine which items belong on the list. The result is a living list, with items that can be added and removed at any time by trusted individuals without Alice's direct involvement. In the following, we walk though the life cycle of a decentralized list, using Nostr Developers as an example.
List Declaration
Creation of a new list is accomplished via publication of a kind 9998 list header event. When Alice decides she wants to establish a new list, she needs only to decide on the list's name (the name of items in the list, in singular as well as plural formats), with an optional description.
{
"kind": 9998,
"tags": [
["names", "nostr developer", "nostr developers"],
["description", "This is a list of developers who build within the nostr ecosystem."],
["required", "p", "name"]
],
"id": "<event_id_of_the_list_of_developers>"
}
The required tag in the above event indicates that the p tag and name tag are expected in any items added to this list (below).
List Item Declaration
Once the list header is published, addition of a list item is accomplished via publication of a kind 9999 list item event. If Alice wants to add Derek Ross to the list of nostr developers, she publishes this event:
{
"kind": 9999,
"tags": [
["z", "<event_id_of_the_list_of_developers>"],
["name", "Derek Ross"],
["p", "3f770d65d3a764a9c5cb503ae123e62ec7598ad035d836e2a810f3877a745b24"]
],
"id": "<event_id_adding_Derek_to_list_of_devs>"
}
The z tag points to the list header. Note she has included the p tag and name tag, both of which are indicated as required by the list header.
List Curation
Decentralized Lists NIP is designed to be compatible with many methods of item curation. However, NIP-25: Reactions and the Trusted Assertions NIP are the suggested methods of curation, and we will use those in our example.
Upvotes / Downvotes
Suppose Bob approves (or disapproves) of Derek being on the list of Nostr Developers. He indicates this preference using a kind 7 note:
{
"kind": 7,
"content": "+", // or "-" to downvote
"tags": [
["e", "<event_id_adding_Derek_to_list_of_devs>"]
]
}
Spam elimination
To eliminate spam from any of the above steps, Trusted Assertions can be used to fetch the rank metric (an integer between 0 and 100) from the authors of all relevant kinds 9998, 9999, and 7 events. Any note authored by someone with a rank score below some cutoff, such as 10 or 20, is simply ignored. On the front end, the user may see that Derek's appearance on this list is endorsed by 10 verified users, with a popup explaining that "verified users" means users whose rank metric is above the selected cutoff.
Trusted Assertions are personalized trust metrics that are currently available for calculation at straycat's Brainstorm, but in the future will be available from multiple Service Providers; you'll even be able to calculate them yourself via open source software if you feel so inclined. If the user has not had Trusted Assertions calculated, the Trusted Assertions of a default npub may be used, as discussed in this article: Integration of NIP-85: Trusted Assertions into Nostr Clients.
DCOSL: a generic lists client
Given the current state of vibe coding, it would probably not be difficult to build all of the above features into a client that would enable users to create, view and manage decentralized lists. An initial implementation should be as clean and simple as possible, without any additional features. However, there is one feature that will be important to add in the future: monetization.
Monetization
Suppose Alice wants a list of Nostr Developers, and she wants it now. Is there a way that she could incentivize members of her trusted community to populate her list for her? Sure, she could post the list header and tell the world how urgent this list is to her. But is there a way to show how badly she wants it? Something she can do that will really grab people's attention?
Of course there is: she can add a bounty. She could, for example, deposit 10,000 sats into escrow and state that any trusted member of her Grapevine who adds an item to this list will get 100 or 1000 or however many sats for each item. And then once the bounty runs out, it runs out.
The system of escrow and payments will require infrastructure that may not yet exist. Perhaps Tim Bouma's Safebox will have a role to play. There are unanswered questions regarding how this would work, so for the time being, an initial implementation of DCOSL should avoid adding monetization or other additional features.
List Curation on Specialized Clients
Once the basic method of decentralized list curation is demonstrated, the number of focused applications will be unbounded. Specialized clients, such as Tunestr, will want to build UX to allow their users to declare and curate lists relevant to the client's area of focus. Imagine establishing a list for "musicians who play Bluegrass, are awesome, but are undiscovered or unappreciated." In other words, the musicians you won't find on Spotify or Google or Grok. If a musician who belongs on the list is not on nostr, the list declaration can specify that the name, url or simply comments tags can be provided in place of the p tag in the kind 9999 list item events. Given a bounty payable only to members of your trusted Grapevine, is it possible that by next morning you will discover one or two or twenty needles in the proverbial haystack? Absolutely.
Are there other ways to curate lists?
Of course there are. One could, for example, create a keyword search for NIP-51 lists and merge them together, using Trusted Assertions to eliminate lists authored by potential spammers. And probably other WoT-related methods that have not even occurred to me. But those methods will be discussed elsewhere.
