Moves Kind:1 definition to NIP-10

[vitorpamplona]

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

[alexgleason]

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.

[alexgleason]

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.

[vitorpamplona]

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.

[alexgleason]

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.

[vitorpamplona]

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?

[vitorpamplona]

For instance, I'd like to clarify if:

• kind1s can accept any nostr:uri inside 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.

[alexgleason]

@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.

[vitorpamplona]

@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.

[alexgleason]

Something like this?

[alexgleason]

Suggested change

	This NIP defines one basic kind:
	#### Profile Metadata (Kind 0)

[alexgleason]

#### 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.

[vitorpamplona]

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.

[vitorpamplona]

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.

[staab]

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?

[fabianfabian]

• 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.

[vitorpamplona]

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.

[buttercat1791]

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.

[vitorpamplona]

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.

[vicariousdrama]

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.

[vitorpamplona]

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 #1042. Those are authenticating kinds.

[SilberWitch]

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.

[vitorpamplona]

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.

[SilberWitch]

Sure, but that's the thing:

If lots of implementations are doing that, as you claim, then that is now the protocol.

Kind:1 is 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.

[vitorpamplona]

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.

[buttercat1791]

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.

[vitorpamplona]

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.

[arthurfranca]

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".

[SilberWitch]

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".

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.

[fabianfabian]

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.

[vitorpamplona]

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.

[SilberWitch]

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.

[vitorpamplona]

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.

[buttercat1791]

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.

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."

[vitorpamplona]

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.

[buttercat1791]

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.

[vitorpamplona]

"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.

[buttercat1791]

"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.

[vitorpamplona]

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.

[mikedilger]

I get it. But this is too pedantic for me to comment on. Oops, I just commented.

[buttercat1791]

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.

[buttercat1791]

This is a good clarification, since there seems to be some disagreement among clients over whether to use Markdown in Kind 1 notes.

[vitorpamplona]

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.

[buttercat1791]

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.

[vitorpamplona]

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.

[SilberWitch]

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...

[vitorpamplona]

Well, this one doesn't crash but it was a VERY long note.

[arthurfranca]

@buttercat1791: 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.

Thinking about it, this does have appeal @vitorpamplona @staab @alexgleason. For better or worse, many non-twitter-like clients are using kind:1 events for comments.

@vitorpamplona: 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.

@buttercat1791: 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.

Yeah this could work. We could keep kind:1 as an essential part of nostr (a way to add comments to any event) if clients add a k tag to them.

Examples:

• Root kind:1 (not replying/commenting) => ["k", ""] // empty string
• kind:1 replying to another kind:1 event => ["k", "1"]
• kind:1 commenting on a kind:30023 blog post => ["k", "30023"]

When there is sufficient buy-in,
twitter-like clients could download them with { "kinds": [1], "#k": ["", "1"] }
and blogs could download events using two filters { "kinds": [30023] }, { "kinds": [1], "#k": ["30023"] }

[arthurfranca]

Please check #1233. It leaves kind:1+NIP-10 alone for microblogging only and adds a generic comment kind for other use cases with an easier than NIP-10 thread logic.

[SilberWitch]

I think this needs to be updated or closed.

[AsaiToshiya]

I really hope this will be merged.

[SilberWitch]

@fiatjaf Can we just go ahead and merge this one? Or was there something concrete that is being waited on?

[staab]

I feel like this could be cleaned up. It sort of jumps back and forth between the kind 1 basic definition and threading details.