nips
nips copied to clipboard
nostr-protocol
Moves Kind:1 definition to NIP-10
This addresses a dev confusion that kind:1s are mandatory: Since kind:1s are currently defined in NIP-01 and NIP-01 is mandatory, people assume a Client's support for kind:1 is also mandatory.
This PR transfers the definition of kind:1 to NIP-10, which was already about kind:1 markers, creating a home for all things kind:1.
This was originally on #963
Doesn't really matter, but I lean towards not changing it. I believe the NIPs should be somewhere between a cold specification and a For Dummies book. This is a little bit too unbalanced on the cold specification side IMO, especially putting it into the underbaked NIP-10. The social media use-case is core, and although we want readers to understand that "other stuff" has limitless possibilities, I think dropping text notes from NIP-01 will actually create more confusion than it aims to solve.
And actually, kind 1 Notes are the "N" in "Nostr". It would be a disservice not to include it in NIP-01. What might make more sense is to add an "Other Stuff" section to NIP-01 that clarifies that there are use-cases other than social media.
What I see is quite the opposite: confused people in hackathons trying to force everything into a kind:1 post because the spec leads them to believe that is how it should be done: They must start by coding a kind1. Which leads them to build things that break clients out there:
- That's why we have bots transferring info in Kind1s.
- That's why we get kind1 replies to non-kind1 types: a mistake I made myself many times.
- That's why we get website reviews as kind1 posts.
- We even had git implementations transferring git payloads as kind1s.
- We have had public DMs coded as kind1s with p-tags
Tutorials out there might start with building kind1 clients, the spec doesn't need to.
We should encourage people to create their own kinds.
Acknowledged, but moving it to NIP-10 deemphasizes it too much. Kind 1 events should still be defined in NIP-01. NIP-01 is mandatory, but the text itself can explain that kind 1 notes are not mandatory, despite being "core" to the protocol.
We should just update NIP-01 itself to clarify its usage. We could have a "Social Media" and "Other Stuff" subheadlines explaining this.
We should just update NIP-01 itself to clarify its usage.
I have a lot of things to say to clarify the usage of Kind 1s. But if we keep everything on NIP-01, the kind 1 definition will be bigger than the rest of the other sections. It doesn't really make much sense.
How about we cite kind1s in NIP-01, but direct people to NIP-10 if they want more details about kind1s?
For instance, I'd like to clarify if:
- kind1s can accept any
nostr:uriinside of their content. - kind1s can develop it's own mini-markdown format.
- kind1s can have special tags just for them
- kind1s can be embedded on themselves
- kind1s can be private
- kind1s can be subscribed to
- kind1s can have machine code or they must always have human-readable code
- kind1s can be the reply for other kinds
- kind1s can be used for DMs
- kind1s should preview images or not
- kind1s should preview URLs or not
- kind1s can use IPFS content or not
- kind1s can have HTML and javascript sections inside of them or not
etc..
Right now we are not even debating those things because there is no good place to put them. With a specific NIP for kind:1, kind 1 clients can converge into that NIP for their things instead of bugging everyone in Nostr by changing the main NIP or creating new NIPs for every kind1 detail out there.
@vitorpamplona That sounds reasonable to me. I like the direction with NIP-10. With NIP-01, just remember that N and OS exist alongside each other, N is not part of OS. Both should have sufficient emphasis in NIP-01 even if they're not thoroughly defined there.
@alexgleason, see if this recent change is enough. I added kind:1/NIP-10 as an example of how other NIPs should be used to define event kinds.
Yeah, I'm with Vitor, I think kind 1s are not exactly central to nostr, in that you can use nostr without using kind 1. Kind 1s do have a privileged position, in that they are the most basic and widely supported kind, and therefore most likely to be seen. But putting them in NIP 10 really cleans up the categories for me. Maybe we need a GETTING_STARTED.md?
- That's why we get kind1 replies to non-kind1 types: a mistake I made myself many times.
Why do you think this is a mistake? I see this as one of the few ways how nostr can grow and how people can discover the Other Stuff.
Why do you think this is a mistake?
Old kind 1 apps are not ready to render replies to new kinds, which breaks their experience. That's the reason why almost every NIP has to build its own re-implementation of kind:1 if they want replies. It sucks for composability but it keeps devs happy and NIPs bottled within themselves, which is simpler to understand and implement.
On Amethyst, I just have one base short note implementation and just extend it with a new kind number for every separate NIP that needs it.
Why is it that the Nostr protocol has existed for almost two years, but even the basic protocol description is still in draft state?
For what it's worth, Kind 1 makes sense to me as a reference implementation. NIP-01 describes the basic protocol flow, the event shape, a metadata event type, and an event type for simple human-readable content.
Most clients seem to treat NIPs as feature specifications, so if two clients implement the same NIP, we expect them to have feature compatibility. Removing Kind 1 from NIP-01 leaves us with a minimum feature specification (since NIP-01 is the only mandatory NIP) that doesn't support any human-readable content. I think that is a mistake.
The discussion in this thread about clarifying what exactly Kind 1 events are expected to support is likely to be fruitful, as are the points about emphasizing that Nostr is more than just Kind 1 text notes. However, a basic definition for events that contain human-readable text is, and should remain, a fundamental part of the protocol definition.
Removing Kind 1 from NIP-01 leaves us with a minimum feature specification (since NIP-01 is the only mandatory NIP) that doesn't support any human-readable content.
Today there are more clients that don't support kind:1 than clients that support it. Kind:1s are only relevant to Twitter-like apps. Virtually nothing else needs it. Kind1s are NOT simple text notes for all apps. They are specifically designed to be posts in Twitter-like clients. Many nips have to re-implement kind:1 for these exact reason.
Kind:1s are only relevant to Twitter-like apps. Virtually nothing else needs it. Kind1s are NOT simple text notes for all apps.
I'm relying on Kind 1 in Corny Chat to allow users to associate and verify ownership of their npub without using a NIP07 extension. Corny Chat is not a Twitter-like app. It's because Kind 1 is a simple text note that common input clients implement that I chose to depend on Kind 1 for this.
I'm relying on Kind 1 in Corny Chat to allow users to associate and verify ownership of their npub without using a NIP07 extension. Corny Chat is not a Twitter-like app. It's because Kind 1 is a simple text note that common input clients implement that I chose to depend on Kind 1 for this.
You are free to continue to do so. Moving kind 1 to NIP-10 doesn't change anything for you. Clients that cannot work with Kind:1 will not be able to login into your system either now or after this change anyway.
Also, kind:1 is not made for that. You should look at kind:27235 from NIP-98, kind:22242 from NIP-42 or https://github.com/nostr-protocol/nips/pull/1042. Those are authenticating kinds.
Many nips have to re-implement kind:1 for these exact reason.
Redefining the same thing over and over, but with a different id, is a protocol anti-pattern.
It is the most essential kind and should merely have a mechanism (tag?) for identifying the use case or client.
Redefining the same thing over and over, but with a different id, is a protocol anti-pattern.
Sure, but that's the thing: They are not exactly the same thing. They are generally semantically different. Every NIP adds and removes certain characteristics to their version of kind1s. Those additions and removals do break existing clients if made it in the kind:1.
It is the most essential kind
Kind:1 is not and will never be an "essential kind". There is just no use for it in the majority of Nostr applications.
and should merely have a mechanism (tag?) for identifying the use case or client.
That will break backwards compatibility since stale clients will not be up-to-date with the new tags that mark separate use cases. I don't mind breaking backwards compatibility when needed, but a lot of people here will disagree with me.
Sure, but that's the thing:
If lots of implementations are doing that, as you claim, then that is now the protocol.
Kind:1is not and will never be an "essential kind". There is just no use for it in the majority of Nostr applications.
You see it purely as a "tweet", but implementations are using it as a generic short message or comment. Users don't necessarily want to use 5 different clients for managing our messages.
That will break backwards compatibility
Then make it optional. No tag means Twitter clone. Or some different tactic.
If lots of implementations are doing that, as you claim, then that is now the protocol.
Yep, and there is a point to be made that it should be like that. There are benefits to it: simplicity, completeness/full compliance, and isolation of concerns to name a few.
You see it purely as a "tweet", but implementations are using it as a generic short message or comment. Users don't necessarily want to use 5 different clients for managing our messages.
They shouldn't use it for that. Otherwise, unrelated short messages start to pop up in every twitter feed out there without any context. Historically, we know users are going to be mad at both clients and will likely stop using both of them.
Then make it optional. No tag means Twitter clone. Or some different tactic.
Old clients are not expecting the tag. So, it still breaks backward compatibility.
Then make it optional. No tag means Twitter clone. Or some different tactic.
Old clients are not expecting the tag. So, it still breaks backward compatibility.
Leaving NIP-01 in a draft state that can change with little warning is more harmful to compatibility than requiring developers to filter out certain tags when querying relays for notes.
Frankly the draft doesn't mean much. All these NIPs are just describing the behavior out there and not the opposite. If there is consensus in a change and enough implementations supporting it, it will be modified, no matter if it is marked as draft or final.
I'm with @vitorpamplona in that kind:1 should be just for twitter-like clients and this should be made clear on this repo.
If many different non-twitter-like apps start using kind:1 for comments or other things, the feed in the future will be full of garbage.
Adding a generic comment kind with a k tag set to the referenced event kind could be a solution. So if my client supports say kind:30023 events, I can fetch them and also the generic comment kind events with k tag set to "30023".
Adding a generic comment kind with a
ktag set to the referenced event kind could be a solution. So if my client supports saykind:30023events, I can fetch them and also the generic comment kind events withktag set to"30023".
That would be an elegant solution, as it would allow you to move Kind 01 out, or to define it's use case more narrowly, while leaving one "generic note for human reading" in, and give the current Kind 01 co-opters a new, widely-accepted note type to move to.
So other stuff like Flare should not be using kind:1 for comments? That's just destroying nostr's network effect for no good reason.
So other stuff like Flare should not be using kind:1 for comments? That's just destroying nostr's network effect for no good reason.
Using Kind:1 as replies to other kinds is irrelevant to the debate about moving Kind1 to NIP-10 or not. Even if everybody ends up using Kind:1 for replies, it is still not mandatory to be implemented. It's just another kind.
Forcing clients that don't implement kind1 to do so is just wrong.
Forcing clients that don't implement kind1 to do so is just wrong.
Just make it clear in NIP-01 that Kind 01 implementation isn't mandatory for conforming to NIP-01.
Forcing clients that don't implement kind1 to do so is just wrong.
Just make it clear in NIP-01 that Kind 01 implementation isn't mandatory for conforming to NIP-01.
So, are we going to have a default mandatory label at the top and then lots of exceptions in the middle of the texts for the stuff that isn't?
Why not just move it to a place designed for it and then if people want to debate if Kind:1 should be used for replies or not they can do it over there and stop polluting the main protocol with their stuff.
Forcing clients that don't implement kind1 to do so is just wrong.
Just make it clear in NIP-01 that Kind 01 implementation isn't mandatory for conforming to NIP-01.
So, are we going to have a default mandatory label at the top and then lots of exceptions in the middle of the texts for the stuff that isn't?
Why not just move it to a place designed for it and then if people want to debate if
Kind:1should be used for replies or not they can do it over there and stop polluting the main protocol with their stuff.
In fact, I think that having Kind 0 (basic metadata) and Kind 1 (basic human-readable text) be mandatory makes perfect sense for a protocol that describes itself as "The simplest open protocol that is able to create a censorship-resistant global 'social' network once and for all."
Human beings talking to each other is a fundamental part of being "social."
So, DM clients now MUST implement kind 1 to be called Nostr Clients? Must Gitworkshop now offer Kind 1 support to their users? Must Shopstr be forced to implement twitter-like threads?
It doesn't make any sense. The world does not revolve on Kind:1.
So, DM clients now MUST implement kind 1 to be called Nostr Clients? Must Gitworkshop now offer Kind 1 support to their users? Must Shopstr be forced to implement twitter-like threads?
It doesn't make any sense. The world does not revolve on Kind:1.
Kind 1 notes are perfect for adding comment functionality to other feature sets. That's what makes Nostr so powerful, it adds a social component to everything. PR comments on a Git app? Kind 1. Discussions or product reviews on Shopstr? Kind 1.
If users want a traditional, asocial, one-way app experience, they can go back to Web 2.0–it's quite mature. Taking the social component out of the core of the protocol removes Nostr's key value proposition.