Deprecates git replies in favor of NIP-22

[vitorpamplona]

No description provided.

[fiatjaf]

@DanConwayDev

[dluvian]

I agree.
I use nip22 in Gitplaza and Gitworkshop uses kind 1 but it's a key priority to switch to nip22: https://gitworkshop.dev/r/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qqtva5hgam0wf4hx6r0wq2r9ayq/issues/note1smqtj4vfkqt0ldcrhlqgp4y72sgxua8z66pjj5gecdznuj2dhehscse0lt

Does anyone even use this GitReply event?

[cypherhoodlum]

Does anyone even use this GitReply event?

I'm literally testing the NIP-34 replies right now on the Nestr client but our working implementation is handled very differently (using Martti Malmi's irisdb-hooks). I thought I'd test if NIP-34 could work for us too but if this is going to get deprecated then I won't bother testing it. The main reason we'd switch is to be more interoperable. We also have pull requests which is not specified in NIP-34 at all. PRs have almost identical structure to issues but should have a different kind number imo.

[cypherhoodlum]

The only problem I see with NIP-22 in this use case is that markdown is the standard format of git replies and that is not allowed in kind 1111 event .content.

[vitorpamplona]

On that point, I think content restrictions on NIP-22 will have to be per scope. The comment kind must always follow the formatting requirements of the scope they are being applied to.

[vitorpamplona]

Check this out: #1797

[AsaiToshiya]

Check this out: #1797

LGTM.

[DanConwayDev]

nip10 threading applies throughout nip34 and not just to the reply kind. I'll review this PR tomorrow including the impact on the rest of nip34.

…

-------- Original Message --------

On 20/02/2025 15:03, AsaiToshiya wrote: > Check this out: [#1797](#1797) LGTM. — Reply to this email directly, [view it on GitHub](#1744 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3MDZJYP4SFNDYROJBZDNK32QXVDJAVCNFSM6AAAAABWRFOWCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZRG43DKNZQGU). You are receiving this because you were mentioned.Message ID: ***@***.***> [AsaiToshiya]AsaiToshiya left a comment [(nostr-protocol/nips#1744)](#1744 (comment)) > Check this out: [#1797](#1797) LGTM. — Reply to this email directly, [view it on GitHub](#1744 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3MDZJYP4SFNDYROJBZDNK32QXVDJAVCNFSM6AAAAABWRFOWCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZRG43DKNZQGU). You are receiving this because you were mentioned.Message ID: ***@***.***>

[dluvian]

We should deprecate nip10 all throughout. Use e for parent and E for root instead of these marker e tags which make lazy loading impossible

[DanConwayDev]

The main reason we'd switch is to be more interoperable. We also have pull requests which is not specified in NIP-34 at all.

The primates for a pull request style workflow are there in nip34. You can see how the ngit git remote helper is intended to be used with this workflow at https://gitworkshop.dev/quick-start

…

-------- Original Message --------

On 20/02/2025 22:52, Dan Conway wrote: nip10 threading applies throughout nip34 and not just to the reply kind. I'll review this PR tomorrow including the impact on the rest of nip34. -------- Original Message -------- On 20/02/2025 15:03, AsaiToshiya wrote: >> Check this out: [#1797](#1797) > > LGTM. > > — > Reply to this email directly, [view it on GitHub](#1744 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3MDZJYP4SFNDYROJBZDNK32QXVDJAVCNFSM6AAAAABWRFOWCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZRG43DKNZQGU). > You are receiving this because you were mentioned.Message ID: ***@***.***> > > [AsaiToshiya]AsaiToshiya left a comment [(nostr-protocol/nips#1744)](#1744 (comment)) > >> Check this out: [#1797](#1797) > > LGTM. > > — > Reply to this email directly, [view it on GitHub](#1744 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3MDZJYP4SFNDYROJBZDNK32QXVDJAVCNFSM6AAAAABWRFOWCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZRG43DKNZQGU). > You are receiving this because you were mentioned.Message ID: ***@***.***>

[mikedilger]

I say we keep git replies since they are markdown and nip22 comments are not. BUT maybe the tags could be more like nip22, I dunno.

[dluvian]

We're not keeping git replies. No one uses them. I say we use nip22 and don't stress about markdown.

[cypherhoodlum]

You can see how the ngit git remote helper is intended to be used with this [PR] workflow

Wow that is not accessible at all and doesn't leverage Nostr. Working on fixing this 👍

[cypherhoodlum]

I say we use nip22 and don't stress about markdown.

I agree. Kind 1 clients can choose to display or hide events based on the NIP-22 tags. If a client doesn't support displaying the root event (context for the comment) then it's trivial to hide the comment entirely to avoid contextless "spam" which probably contains formats like markdown in the .content that the client is not expecting.

[DanConwayDev]

Wow that is not accessible at all and doesn't leverage Nostr. Working on fixing this 👍

Not sure what you mean? the PR is entirely on nostr in patch event(s).

[cypherhoodlum]

I'm sure I'm missing something then, ignore me. We'll be doing PRs very differently on our project anyway to keep the github-like UX. No patches.

[DanConwayDev]

ACK

nip10 threading applies throughout nip34 and not just to the reply kind. I'll review this PR tomorrow including the impact on the rest of nip34.

I've reviewed the impact of nip22 on the rest of nip34 and concluded that its best to use nip22 comments here but not to apply the threading style to patch and status events as its a breaking change. I came to this conclusion by drafting the changes that would be needed - #1799 includes this if you are interested.

[vitorpamplona]

Replaced by #1799

[vitorpamplona]

@DanConwayDev I am confused about this statement. Are you saying we should merge this or #1799?

[DanConwayDev]

I'm saying we should merge this and not #1799 so we minimised breaking changes.

I've implemented nip22 for gitworkshop.dev to reflect this PR (see git issue on gitworkshop). Are there any clients left using kind 1 or the legacy kind for git replies? Has amethyst updated?

Let's go ahead and merge this and discuss if we need furture changed in the #1799 thread.

[vitorpamplona]

Nice, I will switch on Amethyst too

[staab]

Either PR seems fine to me, but regarding plaintext I've drafted #1800. Hopefully this can thread the needle between rich text and plain text.

[DanConwayDev]

can we merge this?