Moves Kind:1 definition to NIP-10 #1076
Conversation
… is mandatory to work with Kind 1s.
|
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
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. |
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:
etc.. Right now we are not even debating those things because there is no good place to put them. With a specific NIP for |
|
@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. |
| Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds: | ||
| Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, especifies the `kind:1` text note for social media applications. | ||
|
|
||
| This NIP defines one basic kind: |
There was a problem hiding this comment.
| This NIP defines one basic kind: | |
| #### Profile Metadata (Kind 0) |
|
|
||
| - `0`: **metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete older events once it gets a new one for the same pubkey. | ||
| - `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those. |
There was a problem hiding this comment.
#### Text Notes (Kind 1)
Social media is a core use-case of Nostr, and kind 1 text notes are the way to make a basic "post". See (NIP-10)[./NIP-10.md] for the full specification of text notes.
#### Other Stuff
Nostr can support many other use-cases by using additional kinds. See the [full list of kinds] (./README.md#event-kinds) or consider proposing your own.There was a problem hiding this comment.
Social media is a core use-case of Nostr
I don't think we should say that. It's detrimental to the plurality of Nostr. We already lost a lot of people who think we only care about social media. Notes are already in the name of the protocol. People already get it. We don't need to make such statements (on which kinds are more core than others) in any other NIP.
There was a problem hiding this comment.
Other Stuff
I also don't like this separation. It creates a sense of second-class citizen if you are not a kind1 client/dev. Again, it's already in the name, there is no need to repeat it everywhere.
And this comes from a kind1 dev. I am happy to be the privileged one here, but I don't think insisting on this segregation is good for Nostr.
|
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 |
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. |
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 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 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 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. |
Today there are more clients that don't support |
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 |
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. |
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.
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. |
If lots of implementations are doing that, as you claim, then that is now the protocol.
You see it purely as a "tweet", but implementations are using it as a generic short message or comment.
Then make it optional. No tag means Twitter clone. Or some different tactic. |
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.
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 clien A3DB ts and will likely stop using both of them.
Old clients are not expecting the tag. So, it still breaks backward compatibility. |
Leaving NIP-01 in a |
|
Frankly the |
|
I'm with @vitorpamplona in that If many different non-twitter-like apps start using Adding a generic comment kind with a |
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. |
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. |
|
"Social" does not require small, unformatted plain text notes in thread form with replies. Chat apps don't use Kind 1 and I would say that are way more "Social" than Twitter clients. Removing kind 1 doesn't make anything less social. |
Kind 1 was the first event type meaningful to end-users, and it is still the most common. The basic interoperability it affords is powerful. Any basic client knows how to render any kind 1 note for any Nostr-based application. Filtering out irrelevant notes via tags is easy, as is directing users to relevant 3rd-party clients to view special content those Kind 1 notes may be responding to. As long as Kind 1 is fundamental, any users can tune into the network's social "buzz." You can't get that anywhere else on the internet. |
None of that makes kind 1 mandatory. It should be optional. Those who agree with you are free to implement that kind in their clients. Those who do not, are free to not even care about it. Freedom tech is about that. |
|
I get it. But this is too pedantic for me to comment on. Oops, I just commented. |
There was a problem hiding this comment.
Having thought more about this proposal, and the discussion around it, I can see the value in grouping the Kind 1 definition with the spec for threads, replies, and mentions.
I think it would be valuable to include @arthurfranca's suggestion of a k tag specifying the note kind to which a Kind 1 comment is replying, if relevant.
|
|
||
| `e` and `p` tags can be used to define note threads, replies and mentions. | ||
|
|
||
| Markup languages such as markdown and HTML SHOULD NOT be used. |
There was a problem hiding this comment.
This is a good clarification, since there seems to be some disagreement among clients over whether to use Markdown in Kind 1 notes.
There was a problem hiding this comment.
There are lots of issues in kind 1 notes. For instance, there is a new client that is pasting base64 images right into the text to avoid using an image server. The .content looks like this:
Lorem ipsum....
data:image/svg+xml;base64,PD94bWwg..[10000 chars later]..go8L3N2Zz4K
Lorem ipsum....
In that case, clients are supposed to parse the data:image/svg+xml;base64, segment into an image.
There was a problem hiding this comment.
Maybe the Kind 1 spec should be updated to allow only human-readable text and embed codes for other Nostr events. Anything else seems rather egregious. Updating the spec in that regard might be the work of another PR, though.
Ideally clients would simply reject notes like the example you gave, but that requires the clients to parse the .content of each note, which is likely impracticable for some.
There was a problem hiding this comment.
Yeah, we can keep adding more guidance in the NIP so people know what's expected and what isn't. There is a lot to add. The more specific, the better it gets for interoperability.
Then people who want new formats can easily just add a new kind for those formats.
There was a problem hiding this comment.
In that case, clients are supposed to parse the
data:image/svg+xml;base64,segment into an image.
Was that the problem with that weird note that crashed your client? The image section looked really odd...
There was a problem hiding this comment.
Well, this one doesn't crash but it was a VERY long note.
Co-authored-by: Michael J <37635304+buttercat1791@users.noreply.github.com>
Thinking about it, this does have appeal @vitorpamplona @staab @alexgleason. For better or worse, many non-twitter-like clients are using
Yeah this could work. We could keep Examples:
When there is sufficient buy-in, |
|
Please check #1233. It leaves |
|
I think this needs to be updated or closed. |
|
I really hope this will be merged. |
|
@fiatjaf Can we just go ahead and merge this one? Or was there something concrete that is being waited on? |
10.md
Outdated
| This NIP defines `kind:1` as a simple plaintext note. | ||
|
|
||
| ## Abstract | ||
| This NIP describes how to u F438 se "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event. | ||
|
|
||
| The `.content` property contains some human-readable text. | ||
|
|
||
| `e` and `p` tags can be used to define note threads, replies and mentions. | ||
|
|
||
| Markup languages such as markdown and HTML SHOULD NOT be used. |
There was a problem hiding this comment.
I feel like this could be cleaned up. It sort of jumps back and forth between the kind 1 basic definition and threading details.
|
Can we add a reference to NIP-22 (generic comment), after NIP-10? Seems like only listing a microblogging NIP is counterproductive. |
|
I have been convinced this is a good move and that we should merge it. Any counter-arguments, @alexgleason @jb55 @pablof7z @v0l @utxo-one @fabianfabian @rabble? I am a kind 1 maximalist myself (in this specific sense: https://fiatjaf.com/cd8ce2b7.html), so I certainly empathize with @fabianfabian and @alexgleason's concerns, but I don't think this change hurts that position at all. |
|
On Fri, Dec 20, 2024 at 05:55:09AM -0800, fiatjaf_ wrote:
I have been convinced this is a good move and that we should merge it. Any counter-arguments, @alexgleason @jb55 @pablof7z @v0l @utxo-one @fabianfabian @rabble?
seems fine to me
|
Seems fine, my concern was mostly with Vitor's comments about when to use kind1 but the NIP change itself looks ok. |
|
@fiatjaf shall we merge this? |
|
I'm merging this, it seems to be overwhelmingly popular. Comments regarding k tags or adding references to NIP 22 should be handled in a separate PR. |
Co-authored-by: Michael J <37635304+buttercat1791@users.noreply.github.com>
This addresses a dev confusion that
kind:1s are mandatory: Sincekind:1s are currently defined in NIP-01 and NIP-01 is mandatory, people assume a Client's support forkind:1is also mandatory.This PR transfers the definition of
kind:1to NIP-10, which was already aboutkind:1markers, creating a home for all thingskind:1.This was originally on #963