Add NIP-74: Nostr Link Lists #1753
Conversation
This NIP defines a standardized format for sharing curated collections of links on Nostr. Key features: - Public link list events (kind:30001) - Rich metadata and internationalization support - Protocol-specific link handling - Complements NIP-51 bookmarks by focusing on public sharing The NIP number 74 was chosen as it represents ASCII 'L' for Links.
|
Why is there no |
- Replace title tag with 'd' tag to follow NIP-51 convention - Update tag description to clarify its purpose - Keep consistent with other list-type NIPs
|
good catch ... I changed the title field to a d field. |
- Update from 30001 (which was previously deprecated) to 30011 - Update all examples and documentation to use new kind number
The '11' in 30011 visually resembles 'll' for 'link list', adding a mnemonic element to the kind number choice.
| ### Tags | ||
|
|
||
| Required tags: | ||
| - `ll` ["list"] - Identifies this as a link list event |
There was a problem hiding this comment.
Why is the ll tag needed? I think event kind is enough.
There was a problem hiding this comment.
Thank you for the feedback! The suggestion to use kind:30001 with a "d" tag is thoughtful, but I believe link lists warrant their own kind number for several important reasons:
-
Distinct Purpose & Evolution: While NIP-51 lists are primarily for personal organization (bookmarks, pins, etc.), link lists serve a fundamentally different purpose. They're designed for public sharing and can evolve into:
- Site navigation systems
- Resource directories
- Content curation tools
- Public profile components
- Community knowledge bases
-
Rich Metadata & Protocol Support: Link lists need specialized handling for:
- Multiple protocol types (http, magnet, ipfs, nostr, etc.)
- Protocol-specific metadata and validation
- Language/internationalization per link
- Direction handling for RTL languages
-
Implementation Clarity: A distinct kind number makes it clear to implementers that:
- This is a public-facing feature (vs. personal lists)
- It requires specific UI/UX considerations
- It needs protocol-aware handling
- It may evolve independently of personal lists
Regarding the ll tag: While the kind does indicate "this is a link list", the tag serves additional purposes:
- Makes it easier to filter/query specifically for link lists
- Allows for future extensions without kind number changes
- Maintains consistency with other NIPs that use identifying tags
The goal is to create a foundation for rich, public link-sharing features that can grow beyond simple lists while maintaining clear separation from personal bookmarking tools.
There was a problem hiding this comment.
And to add a concrete example: One of the implementation I had envisioned is a "Top 8 Nostr Friends" feature (similar to MySpace) where users can showcase their closest connections or most meaningful interactions. This would use the same link list structure but with:
- npub-specific metadata
- Optional interaction-based auto-generation
- Custom display ordering
- Profile-specific metadata (last interaction, relationship, etc.)
This kind of extension demonstrates why having a dedicated kind with additional metadata support is valuable - it allows link lists to evolve from simple URL collections into richer social features while maintaining backward compatibility.
|
I think this is pretty much covered by NIP 51 bookmarks. Given that events are public, they can't not be for public consumption. If someone wants private bookmarks, they should encrypt them into their 10003 event's content. We also have a standard for external content ids which can already be added to any kind of list. |
|
At best this should be just one extra row added to the NIP-51 table. |
|
Thank you for taking the time to review and feedback. It's definitely giving me pause in thinking about the relationship between bookmarks and link lists. The project I've been quietly working on is a link-in-bio" type page. So I might be overly focused on lists of a specific type. That may still be an edge case to most other users of the Nostr protocol. And while there's definitely overlap, I'm seeing some distinct patterns emerge from real-world usage (in nostree.me) and wanted to open the idea up from an edge case to its own NIP:
That said, I completely understand the desire to avoid unnecessary complexity in the protocol. Would it make sense to:
As a "new to Nostr" UX/UI developer, I'm happy to help draft these additions to NIP-51 if that's the preferred approach. My intentions / goal is to support these emerging use cases while maintaining protocol simplicity. |
Consider https://github.com/nostr-protocol/nips/blob/master/39.md
I think this is fair. A new NIP 51 kind could probably be justified. Or, you could imitate coracle's "collections", which use NIP 32 (probably not the best idea though).
Consider https://github.com/nostr-protocol/nips/blob/master/92.md
I do think that's what this spec is mostly in danger of right now. There is a balance between complexity and interoperability. If a spec is too simple, it won't support rich interactions. If a spec is too complex, it won't be interoperable. This is the reason nostr specs are so barebones; you can add whatever fancy meta tags you want, but if no one bothers to implement them because their utility doesn't meet the threshold of development expense or usefulness to interop, then they fail to be any kind of protocol at all. |
what if you want to change the title? |
Best practice is to use a random id for the |
|
Wow these are great insights... Thank you!!! I'm still learning the landscape of the protocol, and the feedback here definitely makes sense. Reading into the suggested NIPs, and also trying to bring value without complexity, I think the best way forward might be:
As a next step, I can draft a simple addition to NIP-51's table for a "curated links" kind that focuses just on the essential metadata (language, direction) while leveraging existing NIPs for the rest. Would that be a helpful contribution? I'm grateful for all the feedback here, and the constructive conversation. As a new to Open Source contributor, I'm excited to be part of the Nostr community, and learning how to participate in a "yes and" way without creating chaos. |
|
In this case wouldn't it be better to make it a normal replaceable event? |
|
Yes, that what I was thinking. That each update would replace the rendition shown, on the users bio. As a regular replaceable event, it would be simpler / fits the use case better - with the idea that users typically want one main link list that they update over time. Would something like this work as an addition to NIP-51? This would give users one update-able link list while still supporting the metadata we need for good i18n support, and follows the sequence of existing list kinds (10000-10004). |
|
The 10005 kind looks good to me.
Why language and direction? Shouldn't that be handled by the website serving the url? It seems like odd metadata to include. |
|
Good question and thank you for asking. My thoughts have been that language/direction metadata might seem redundant at first, but ... I wanted to reflective to real-world experiences with multilingual applications. One of the UX considerations I'm hoping we would cover is the nuance of a global audience mixing their link sources in a single list. And you're right. Websites / browsers handle their own language/direction. By having this metadata at the link level serves a few practical purposes:
I learned this pattern working on a handful of corporate applications - it's particularly helpful when building interfaces that seamlessly mix content in languages like English (LTR) with Arabic (RTL) or if there are links that are English, and Chinese (simplified/traditional), or Japanese. That said, these are optional fields (hence the ? in the spec). Clients can ignore them if they don't need this functionality, but having them available opens up some nice possibilities for more inclusive, global-first applications. |
|
This seems like over-engineering to me. You could make just as strong a case for 1000 other dimensions of what might be behind a link, which gets up back into scope-creep territory again. Maybe these particular pieces of metadata are more important than I think, or maybe they're crucial to your use case. But I would be surprised if the average client adapted its UI to that extra metadata (meaning in practice interoperability wouldn't happen). |
NIP-74: Nostr Link Lists
This NIP defines a standardized format for sharing curated collections of links on Nostr. It formalizes and extends the format originally developed by nostree.me, which has been successfully serving the Nostr community as a "link-in-bio" solution.
Key Features
Distinction from NIP-51 Bookmarks
While NIP-51 bookmarks serve as private reading lists, NIP-74 link lists are designed for public sharing and discovery, enabling users to curate and share collections of resources with their community.
Implementation Status
This format evolved from the proven implementation at nostree.me, which has been serving the Nostr community as a reliable link-sharing platform. The specification has been refined based on real-world usage and community feedback, and is also being implemented by other projects like linktr-nostr, demonstrating its practical utility and growing adoption.
References