NIP-34: send patches and issues to repos not yet on Nostr

[DanConwayDev]

Allow contributors to share patches and issues without requiring maintainers to first create a Nostr repository announcement.

Motivation:

• Aligns with the permissionless philosophy of Nostr.
• Provides a way to contribute when the author doesn't have — or can't create — an account on the centralized git platform chosen by maintainers.
• Allows contributors who want a repository moved to Nostr to:
  1. Demo it to maintainers using their own data and community.
  2. Build community support by encouraging other community members to comment on, review, and interact with the issues/patches and to create their own issues/patches.

Once this community support is achieved and demonstrated and the repo moves to Nostr, the first issues / patches shouldn't be disconnected or unavailable. The retired-clone tag is intended to make it easier for clients to find and display this content.

[DanConwayDev]

I thought about changing ["clone" "<clone-url>",...] to multiple ["c" "<clone-url>"] in the announcement event. This would allow clients to go from a patch or an issues created with the i tag to nostr repositories associated with the clone url.
This would be a breaking change, but maybe worth it if we are already doing the PR breaking change?

[TheAwiteb]

I thought about changing ["clone" "<clone-url>",...] to multiple ["c" "<clone-url>"] in the announcement event. This would allow clients to go from a patch or an issues created with the i tag to nostr repositories associated with the clone url. This would be a breaking change, but maybe worth it if we are already doing the PR breaking change?

I don't think we have to change it. This will make it complicated, it will require me to check for every repository if it have an i-issue and i-patch, I think retired-clone is better, so I have to search for issues and patches by the clone url if it's there.

[DanConwayDev]

@fiatjaf @dluvian @Silberengel @chebizarro @Pleb5

[Silberengel]

Isn't this use case covered by the fact that you don't need to be a maintainer, to issue a repo announcement?

[TheAwiteb]

Isn't this use case covered by the fact that you don't need to be a maintainer, to issue a repo announcement?

You don't need a repo to make a patch or issue. This PR cover a case where the repo you want to contribute to it doesn't announced itself on nostr but it did later.

So, patches and issues that has been created before the announcement can be linked to the repo later.

[Silberengel]

Oh, okay.

We actually struggle with all three maintainers having a repo announcement, so that we don't see the issues posted to someone else's announcement.

Is there a way to associate announcements?

[TheAwiteb]

Is there a way to associate announcements?

No, but you can make a patch and an issue for multiple announcements. You can also query for all announcements in a client that supports it. https://n34.dev support multiple announcements.

[DanConwayDev]

Isn't this use case covered by the fact that you don't need to be a maintainer, to issue a repo announcement?

According to nip34 creating a repo announcement shows "willingness to receive patches, bug reports and comments in general" for that repository. Its misleading to issue a repository announcement if you aren't claiming to be a maintainer.

#1966 suggests adding a new tag so its not always the case:
"By doing so the author asserts themsevles as a maintainer and expresses a willingness to receive patches, bug reports and comments in general, unless t tag personal-fork is included.".

Imo it feels more direct to tag the current 'source of truth' for a repository. If thats a centralised git repository URL then great. If that is one or a number of nostr git repository annoucements then all the better.

[DanConwayDev]

Is there a way to associate announcements?

You associate the announcements by each listing the other maintainers in the maintainers tag.

When sending a patch, issue, PR, etc clients should tag announcement of the selected maintainer, and the announcement of any of the maintainer they list.
When fetching patches, issues, PRs, etc, clients should list any item that tags either the selected maintainer's announcement, or any of the maintainers they list, who also list them.
Imo this is how multiple maintainers should be supported.