NIP-22: Format should follow scope

[vitorpamplona]

This adds some flexibility in formatting styles for NIP-22. Since this NIP is always used inside a scope (another NIP), formatting rules SHOULD be defined by that NIP.

Examples:

• If the Comment is replying to a markdown-based NIP, it should allow markdown.
• If the Comment is replying to an asciidoc-based NIP, it should allow asciidoc.

[staab]

NACK, comments should be plain text. I don't really see the use case for this either except for arbitrary consistency.

[staab]

Nevermind, I just read the linked nip. I guess this is fine, although I still don't like it.

[cypherhoodlum]

LGTM.

[staab]

Ok, thinking about this more, I think a separate kind should be used for non-plaintext comments. This new heuristic is overly rigid — what is it about the parent's content type that implies its comments should be formatted in a particular way? A pretty straightforward counter example is blog comments. The desire to use markdown in comments on a markdown post has nothing to do with the fact that the blog post uses markdown, only on the desire of users to use markdown in comments. The two things are totally orthogonal.

In fact, the purpose of NIP 22 comments is really to have a generic way of commenting on "anything". Changing how it behaves based on context is really an overloading of the kind, and increases the scope of implementation. Right now we have exceptions for kind 1 replies, it would not be unreasonable to make exceptions for git issue replies. So for the git issue comments I would suggest adding a "git issue comment" NIP. We have plenty of kinds.

[vitorpamplona]

what is it about the parent's content type that implies its comments should be formatted in a particular way?

Not necessarily the content type, but the NIP related to the scoped event. The important part for NIP-22 is that Apps only download NIP-22 comments related to their use case. If the App already support special formats, the app can just apply that to the comment as well. No one will make a NIP-22 client that must render all content types. That doesn't make any sense. So, to me it is fine to have content rules match the scope/use case.

[staab]

If the App already support special formats, the app can just apply that to the comment as well.

Yes, but it's wrong to say a priori that certain types of comments don't make sense. I could imagine a use case where comments are pulled out of context as a way of discovering new content types. Such a client would have to support all content types.

Also, I agree with this:

Not necessarily the content type, but the NIP related to the scoped event.

Which reinforces my point — comment content type shouldn't be determined by parent content type, but by NIP.

[dluvian]

I'm with staab on this. Better to define new kinds for different formats. I'll make Gitplaza fetch plain-text and markdown comments but only write markdown comments

[vitorpamplona]

The issue with different kinds is that now we have to deal with replies to replies of different kinds. If my client accepts kind1-like and markdown posts (like we do), I can reply with both kinds of comments. But can I reply by changing the kind of the parent reply? Or would a markdown reply to a kind1-reply start a new thread and the kind1-reply is then the ROOT scope for the markdown reply?

[dluvian]

New comments inherit the root tag of the parent, so every comment in a thread has the same root tag. That's what I was told in the original nip22 PR when I had concerns about not always being able to identify the root.

[staab]

The issue with different kinds is that now we have to deal with replies to replies of different kinds.

Yeah, I think we would have to pick a content type and stick to it, with the expectation that other reply kinds wouldn't likely be seen. Supporting multiple kinds for a single thread just seems like a bad idea.

[vitorpamplona]

Supporting multiple kinds for a single thread just seems like a bad idea.

Agree, but how would you know which thread uses which kind? Also, can we have two kinds reply to the same root and follow their own reply chain from there? I think that is inevitable to happen if we have multiple comment kinds.

Imagine a comment kind that forces 240 max chars and another one that doesn't. Since the root's NIP is doesn't define the content format, both comment kinds can be used for any root. But some apps will only see some replies.

Now scale that to 20 or so comment kinds.

[staab]

Right, I'm saying that kind 1111 plain-text comments should be used by default, unless specified otherwise. In this case, it sounds like the git folks want issue comments to use markdown. So that NIP should define kind xxxx comments, which use markdown and are only used for git issues. This breaks the cool discoverability stuff that kind 1111 gets us, but avoids making everyone support n different content types in comments.

[vitorpamplona]

So, in that case, should each Markdown-based comment use a separate kind, or should we copy NIP-22, change the kind number and content rules, and publish as a new NIP so that all Markdown-based comments use the same kind?

[fiatjaf]

Does this mean that if I'm commenting on an HTML webpage the comment should be in HTML?

[fiatjaf]

My understanding is that comments are just comments, they don't "belong" to the original document in any way.

It's like you publish an article in your blog written in reStructuredText and someone comments about it on HackerNews, in plaintext. You don't necessarily even know about that comment, it's just people commenting.

Same thing on Nostr. You say anything in any kind, you're subject to having people comment about it. These comments should be plaintext because, really, they're just comments, they're not some treatise that would benefit from special notation or markup.

And being plaintext we gain the benefit of being able to show them in any client really easily, and increase discovery of the thing that is being commented about.

[staab]

I would say probably its own kind, since it doesn't make sense to partition discoverability arbitrarily by content type. That also allows the NIP to do a deeper integration with comments by prescribing more stuff comments might do. It's a trade-off between easy discoverability and simple comments, and more finely tuned comments.

If I were the git folks, I would use plaintext rather than markdown and support basic formatting, including code fencing (still plaintext-enough), and url parsing. It doesn't seem like there's much else you would need on a regular basis.

[vitorpamplona]

I would use plaintext rather than markdown and support basic formatting, including code fencing (still plaintext-enough)

Would that be a new kind or still NIP-22? I don't think there is going to be extra tags for git stuff. So that's going to be the only change.

--

Also, there is nothing "plaintext" about kind1-like posts. We already need to render users, hashtags, links, nip-19 quotes, preview items, etc.

[staab]

Would that be a new kind or still NIP-22?

If they want discoverability, NIP 22. If they want something suited to the use case, a different kind.

@cypherhoodlum feel free to take none of this conversation seriously, you do what makes sense to your use case and the specs will follow.

[vitorpamplona]

discoverability

I have no idea what this means. NIP-22 is not a "discoverability" kind. It is as "discoverable" as any other kind. There is nothing special about it.

[staab]

Generic comments with k tags mean that you can ask for comments to any other kind (that they're used for). This is a way to discover root kinds that you didn't know to ask for. Coracle does this, and attempts to load a NIP 89 handler for the parent note. Same reason for the alt tag. It's good to allow people to stumble on new content types (i.e. kinds by the way) and learn how to use them. I'm not saying anyone has to use or not use comments for that reason, but that discoverability is one thing they're trading off.

[vitorpamplona]

Right, but you can do that with reactions, zaps, chat kinds, and virtually any other event kind. There is nothing special about NIP-22.

And new kinds do hurt that discoverability on your side (your user can't see what's happening on Git), not on the git side. For the Git users, it doesn't really matter.

I do expect to have many new kinds over time (hundreds) if breaking off is the way to go forward on this because every little thing, like code fencing, will generate a new kind.

[pablof7z]

NACK. Comments should always just be plain text.

Perhaps for what you want to address here it would be better to have a kind:1111 in plain text that quotes an event of whatever kind. The kind:1111 could have some context like you would do when sharing something, and then the kind:xxxx would have the media type.

For example, if you fiatjaf writes something horrible as a long-form I could reply with it:

{
    "kind": 1111,
    "A": "30023:pubkey:d",
    "K": "30023",
    ...
    "content": "This is why you're wrong and Milei is not a shitcoiner nostr:naddr1...."
}

The other alternative would be to use the tagging structure of NIP-22 in a different kind, say for example if I want to reply to an Olas post with another picture I could post a kind:20 with the "E", "K" and all that jazz.

[mikedilger]

NACK, they should be plaintext

[1l0]

IMHO, you guys should implement like this for specifying root events:

["e","-"]

This way, any kind could be used for replies with reply tags:

["e","123..."]
["E","123..."]

Problem solved. No kind-1111 in this world.

[AsaiToshiya]

IMHO, you guys should implement like this for specifying root events:

["e","-"]

This way, any kind could be used for replies with reply tags:

["e","123..."]
["E","123..."]

Problem solved. No kind-1111 in this world.

What kind should we use for a plain-text comment?

[1l0]

What kind should we use for a plain-text comment?

Of course, kind-1.

[AsaiToshiya]

What kind should we use for a plain-text comment?

Of course, kind-1.

I feel like it goes back to the beginning of NIP-22 on #1233.

[fiatjaf]

The other alternative would be to use the tagging structure of NIP-22 in a different kind, say for example if I want to reply to an Olas post with another picture I could post a kind:20 with the "E", "K" and all that jazz.

Or you do just this:

{
    "kind": 1111,
    "A": "30023:pubkey:d",
    "K": "30023",
    ...
    "content": "This is why you're wrong and Milei is not a shitcoiner I just published a picture of me with him that proves it: nostr:nevent1...."
}

But the nevent1 points to a kind:20.

[fiatjaf]

IMHO, you guys should implement like this for specifying root events:

["e","-"]

Something like this was suggested by @arthurfranca before, but it's a very bad breaking change because now all non-updated clients are publishing exclusively non-root notes.

Also there is an argument to be made that comments are different from replies in theory (although in practice they end up being almost the same thing): replies are made targeting the person who posted something, you want them to see it, comments are a thing on their own, standalone, almost self-sufficient: my comment is me saying something about that other thing, not a direct reply to that other person.

[1l0]

it's a very bad breaking change

Yes. If that spec is implemented for existing root kinds, it will likely be in the hard fork. However, it may still be usable for new kinds even now.

comments are different from replies

Fair enough.

[DanConwayDev]

NACK. I agree with @fiatjaf's rationale:

Does this mean that if I'm commenting on an HTML webpage the comment should be in HTML?

Why shouldn't git clients elect to render markdown in git related 1111 comments? Users are going to use markdown syntax (eg ticks for code) in replies regardless of whether the client they reply with supports it.

We shouldn't use a seperate kind for git comments to support markdown. This would prevent them from being shown in many other clients by default. All comments are social and deserve to be seen by interested users.

Comments related to other stuff should not be siloed by default. Clients should be able to curate experiences by opt-out of showing comments related to certain kinds, or explicitly specify the kinds they are interested in but this shouldnt be the default.

[cypherhoodlum]

I do expect to have many new kinds over time (hundreds) if breaking off is the way to go forward on this because every little thing, like code fencing, will generate a new kind.

The way we currently handle this on our client is by using Martti Malmi's draft NIP-116 that tackles the very issue of having to reserve a new kind number for every little thing. This is nice especially when discoverability of the new thing can be limited. But it's a pain to fetch these events from everyone. The adoption of this spec is also very limited currently. Not to mention Martti's irisdb-hooks actually use kind:30078 with paths even if the NIP-116 spec says kind:30079 🤷

[arthurfranca]

I took a break off nostr but I couldn't resist saying that the solution is right there.

[staab]

I've drafted #1800 to reflect my understanding of the status quo. Hopefully this clarification can satisfy the git use case, since it does include support for things like backticks, just not for links/tables etc.