URI Scheme for git object ids?

Has there been any discussion of how one might represent a git object id as a urn or uri?

It's clear that 'git:' is registered with IANA as a URI prefix for locations of git repos.

I was wondering if there was any existing use of something like:

'gitoid:${type}:${hash type}:${hash of git object}' ?

So for example:

gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64

which could be used to communicate generic git object ids.

Ed

Ed Warnicke <hagbard@gmail.com> writes:

I do not see why the object type should be there. Once you locate the object whose object name (in sha1) is 261eeb..., the object should be able to identify itself as a blob (or whatever type it is).

Aren't there already folks who are exchanging git objects over torrent or something? What do they use to identify what each node offers and what participants want?

Junio,

That's the kind of feedback (and pointers) I was hoping for :)

So is it fair to say you are suggesting:

1. Talk to 'torrent or something' folks to see if they have a scheme in use

and

2.  If not, 'gitoid:${hashtype}:${hashvalue} - like:
     gitoid:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64
     would be a better choice

Ed

On Tue, Mar 1, 2022 at 11:40 AM Junio C Hamano <gitster@pobox.com> wrote:

On Tue, Mar 01, 2022 at 11:35:52AM -0600, Ed Warnicke wrote:

This sounds similar to what git over ipfs folks wanted to do, but they ran into obvious scaling problems. It works fine for small repositories with a few dozen commits, but once we're talking millions, the process of doing anything with such remote starts taking hours and days.

If you're interested in a decentralized forge solution, then Radicle has the closest to something that is working. You just have to ignore all the crazy cryptoblarf web3 stuff.

-K

Konstantin,

I suspect you read a bit more into my question than I intended :) I do appreciate the breadth of your thought about it though :)

Mostly, I'm just looking for a way to express the git object id as a uri scheme so completely outside-of-git things can refer to it clearly (ie, know to prepend the object header before hashing to see if the contents match).

Definitely not thinking of any vaguely web3 ideas :)

Ed

On Tue, Mar 1, 2022 at 11:53 AM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

On Tue, Mar 01, 2022 at 11:58:01AM -0600, Ed Warnicke wrote:

Ah. Sorry, my perception is understandably tainted in the past few days.

Okay, I understand -- so for purposes like adding to sigstore or other supply chain tracking systems?

-K

Exactly... anybody who wants to be able to say "This is a git object id for a thing" rather than "this is a random sha1" (or perhaps someday, sha256), and more importantly... if presented with say... the same contents outside of a git repo repeat the computation of the git object id and see that it's referring to the contents they have in their hands.

That had been my original thought around including the 'object type' (gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64) because if presented with an array of bytes outside of a git repo, if I want to know whether or not it matches the git oid, I need to know what git object type to put in the git header prepended to the contents.

I have a tendency to generalization though, and so its'1 good to get feedback from folks closer to git as to whether that makes sense or not.

As a side note: in case I'm being unclear: there is no conceivable universe in which I'm advocating for git to change anything it does around this conversation. I'm just seeking 'advice'. Among the space of valid advice being: "don't reinvent the wheel, these folks already have a perfectly serviceable wheel"

Ed

On Tue, Mar 1, 2022 at 12:30 PM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: