nip34: personal fork tag change

[fiatjaf]

@DanConwayDev let me know please if this hurts your work too much. I just think it's more elegant to not reuse the "t" tag when we can do something like this.

[DanConwayDev]

I can see your adversion to a canonical "t" tags is consistant with your NIP-51 comment "To me sets with canonical names are an antipattern" but I thought using a single item array tag was an antipattern?

The rationale for the use of a "t" tag is that it clients that don't 'support' it (ie hide peronal-forks from standard repository listings / search results) are likely to display the tags and thus degrades somehat gracefully by giving the user a clue that they are not the maintainer repository. This was the case with NostrHub.io @alexgleason.

It would degrade even more gracefully if we justed used another kind number. This would take more work for clients to support pushing to it though. maybe this is better?

The other rationale for a "personal-fork" explictly listed in the commit message 2aaba90839443dded18afb10adea5806904ea04f is that it can be used to to maintain a patched version of a dependancy; useful not least in build processes. There may be other reasons we haven't though of yet so maybe the laungage should be more open ended?

Practically speaking, I think we are early enough to make this breaking change without too much bother but breaking changes are always annoying. I dont think @TheAwiteb, @chebizarro or @dluvian have implemented it yet.

Anyone using the ngit v2.x that pushes a PR to a repository that doesnt list grasp servers, or the grasp servers aren't accepting the ref for whatever reason will create an announcement using the existing ["t","personal-fork"] tag version, but their are hardly any events like this out there.

[fiatjaf]

but I thought using a single item array tag was an antipattern?

No, why would it be?

The rationale for the use of a "t" tag is that it clients that don't 'support' it (ie hide peronal-forks from standard repository listings / search results) are likely to display the tags and thus degrades somehat gracefully by giving the user a clue that they are not the maintainer repository.

Yes, I thought of this, it's good, but still I thought it wasn't worth it. Maybe it is ok.

It would degrade even more gracefully if we justed used another kind number. This would take more work for clients to support pushing to it though. maybe this is better?

I like this more, then we can have other tags like point from where such repo was originally forked (with an "a" tag?) and ignore fields like "name", "description", "maintainers", "web". And clients that want can display a list of personal forks of any given repo.

[fiatjaf]

OK, now I'm thinking (sorry for not thinking this before, it hadn't occurred to me that this personal fork thing was even necessary so I missed that you had added it).

I hate the idea of having to click "clone" on GitHub in order to send a patch, I think it's an awful antipattern, why are we replicating that here?

When I first saw the idea of Grasp and thought that it would allow PRs to be made in a nice way I thought users would be able to seamlessly push a branch to a grasp server without having to announce a repository, the grasp server would just host that branch in a special "pull request" temporary area.

Can we do that? It's the same as the repository state flow:

1. you make a branch locally
2. then you create the PR event and push it to the grasp server
3. then you push that branch, the grasp server accepts that branch and that branch only based on your PR event
4. the person receiving the PR fetches that special branch from your grasp server

What am I missing?

[DanConwayDev]

That is the happy path. But what happens if the repository announcement doesnt list grasp servers, or the grasp servers they list are offline, or dont accept your ref for some reason? this provides an alternative submission path.

[DanConwayDev]

Actually, its a slightly diffeent flow you outlined.

1. You generate a draft PR event with a server hint as a clone tag.
2. push your commit to refs/nostr/<draft-event-id> at that server, if it fails, go back to step 2 and chose another server from the announcement event, or fallback to your own server / do the personal-fork announcement so you can push it there.
3. push the event to all suitable relays whilst also pushing the ref to the rest of the grasp servers.
4. person receiving fetches from repo grasp servers / clone tag server(s)

[fiatjaf]

So what I'm suggesting is just that you push to your own server (or to the server receiving the PR or whatever server, it shouldn't matter), but skip publishing a repository announcement. Maybe push it to refs/nostr/event-id at /<npub>/<pr>/<event-id>.git instead of to <npub>/<identifier>.git, so there is clear differentiation and the pushes can be handled differently.

[dluvian]

Practically speaking, I think we are early enough to make this breaking change without too much bother but breaking changes are always annoying. I dont think @TheAwiteb, @chebizarro or @dluvian have implemented it yet.

We should also be breaking the ["t", "root"] in patches. We should be using different kinds.