Perhaps related:

GitWorkshop.dev

Decentralized github alternative over Nostr

Perhaps the site can't render the README because it encounters a similar error when cloning? ``` clone --verbose nostr://npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4c/instablossom?relayhint=nostr.sprovoost.nl Cloning into 'instablossom?relayhint=nostr.sprovoost.nl'... nostr: no updates WARNING: failed to fetch from git.sprovoost.nl error:cannot fetch a specific object from the remote repository; class=Invalid (3) and using alternative protocol git@git.sprovoost.nl:instablossom.git: invalid or unknown remote ssh hostkey; class=Ssh (23); code=Certificate (-17) Error: failed to fetch objects in nostr state event from: git.sprovoost.nl: cannot fetch a specific object from the remote repository; class=Invalid (3) and using alternative protocol git@git.sprovoost.nl:instablossom.git: invalid or unknown remote ssh hostkey; class=Ssh (23); code=Certificate (-17) ```

That error comes from deep inside libgit2:

kmx git

unfortunately the git feature for getting the contents of specific files `git archive` is off by default so it makes getting the README.md challenging. many git server implementations expose raw files in a repo over https using similar APIs. Unfortunately some of them don't allow display directly CORS and other eg github have heavy throttling. until last week I was proxying requests to allow support for git servers without CORs exceptions but I have, perhaps temporarily turned that off so gitworkshop.dev could be entirely statically built. when I wrote the feature it supported (with the proxy): self-hosted: gitea, forgejo and gitlab hosted: github, bitbucket.org, gitlab.org, gitea.com, codeberg.org, sourcehut, launchpad.net feedback welcome on how to proceed with this. I'm thinking about opening a PR for @fiatjaf's song to expose the raw files over https. would you be interested in this @fiatjaf?

So if I understand correctly you're trying to do: ``` git archive --remote https://git.sprovoost.nl/instablossom.git HEAD README.md | tar xO fatal: operation not supported by protocol ```

that was the original idea but because of the lack of support I ended up using apis raw

I use git-http-backend, which doesn't seem to support archive:

Git - git-http-backend Documentation

Why not use a shallow clone (as a fallback)? ``` git clone --depth=1 https://git.sprovoost.nl/instablossom.git ```

Ideally the site should let you browse all files anyway.

Though I suppose for now, since the site _only_ shows a README file, I should probably use something like gitea / forgejo / gitlab anyway. And then only use Git Workshop for issue and PR flow.

Random thought: perhaps in the longer run you could write a Forgejo patch (hopefully accepted by them) that pulls in the issues and pull requests (and release tags) from Nostr. Rorgejo can then do the heavy lifting of e.g. nicely rendering code, blame, search, etc. That doesn't need to be decentralized, since multiple people can host one and point to the same nostr repo.

Instead of running to try to catch up with a bunch of proprietary git servers we should have a standard first, then I would gladly accept it or implement it myself on song. That native git feature you mentioned would be my first candidate for such a standard, but last time I tried to implement it on song I failed.

But if we can't get the archive stuff to work then we could standardize an HTTP API thing that returns raw files maybe.

I switched over to a self-hosted Forgejo (with issues and PRs disabled). Still not seeing a README, but perhaps it takes a while to refresh?

Oh I guess you have to make a new static build now for every new repo? (and subsequent README change)

I considered that and experimented with it. There is a lack of support to do it in the browser. In any case, it is too heavy to do client side. And too slow / bandwidth inefficient to do on demand on the server-side. It could potentially be done as a job run daily but it is ultimately reliatively expensive operation to run give we are just looking for the readme.

Yes, and all refs.

Why not have "git push" post an update Readme as nostr longform note or something like that? (if modified)

The @GitCitadel team suggested displaying a repository nostr wiki page instead of the readme in the git repo. We could definity do that or the `git push` thing but don't we ideally want to support display other files and potentially at other refs? If we end up in a world where users of #GitViaNostr don't just rely on free (beer) and reliable hosting from big players like github, bitbucket, gitlab, etc. But instead use selfhost or #GitViaNostr hosted solutions like 'song' could be then the git servers could serve all files for all refs. That would provide the best UX.

I considered that at the outset before the NIP-34 architecture was established but concluded that trying to shoehorn in a decentralised architecture to a centralised approach. I doubt that a PR to turn off a large chunk of the functionality and replace it with some else would get merge and then we'd need to contend with the legacy code without the benefits.

There is a CORS error. Either I need to turn the proxy back on or your site needs to accept CORS requests for at least https://git.sprovoost.nl/sjors/instablossom/raw/branch/master/README.md I need to find a recommended hosting provider that doesn't require KYC and accepts bitcoin first, as I'm running up against the monthly function invocations allowance for my current provider on the free tier.

I'm going to look to switching hosts and turn the proxy back on because its a bad experience having to wait for things like this. There is also some faffing to do to get the pre-rendering working because the load function is completing before the content is fully loaded, a symptom of the use of websockets in csr instead of APIs.

Aha, I'll add some cors headers tomorrow. Do you have specific ones in mind? I guess just for your domain?

I'm not sure how workable `git archive` is. It doesn't appear to be that stable, its not built into any of the git implementation that work in the browser, and off by default nearly everywhere.

as you can see the HTTP API thing is a bit of a mess but the most common format is`https://<host>/<path/to/repo>/raw/<ref>/<path/to/file>` ```typescript /** most servers will produce a CORS error so a proxy should be used */ export const cloneArrayToReadMeUrls = (clone: string[]): string[] => { const addresses = clone.map(extractRepoAddress) /** * at the time of this commit these urls work for: * self-hosted gitea (or forgejo), gitlab * github.com * bitbucket.org * gitlab.org * gitea.com * codeberg.org (forgejo instance) * sourcehut (git.sr.ht) * launchpad.net * It doesnt work for: * self-hosted gogs (requires branch name repo/raw/master/README.md) * sourceforge.net (

MinGW - Minimalist GNU for Windows / catgets / [e8a4ca] /README

* notabug.org (requires branch name notabug.org/org/repo/raw/master/README.md) */ return [ ...addresses.flatMap((address) => { let prefix = 'raw/HEAD' if (address.includes('sr.ht')) prefix = 'blob/HEAD' if ( address.includes('git.launchpad.net') || address.includes('git.savannah.gnu.org') ) prefix = 'plain' if (address.includes('github.com')) { // raw.githubusercontent.com can be used without CORS error address = address.replace('github.com', 'raw.githubusercontent.com') prefix = 'HEAD' } return ['README.md', 'readme.md'].map( (filename) => `https://${address}/${prefix}/${filename}` ) }), ] } ```

its possibly a bit centralising to just include one domain. Would you be uncomfortable using * for anything under **/raw/*? If so you could limit it to **/raw/**/README.md?

you should try out song: View article → it's @fiatjaf's vision of a minimalist git server implementation to work with #GitViaNostr. Tomorrow's task it to fix the git-remote-nostr so that it works seamlessly with it.

I was thinking that exposing files at exact commits would be simpler, but then I realized that to get the exact commit you would need an API that returns all references and HEAD (separate from the repository state event) and then I realized that to build a GitHub-like way to browse files on gitworkshop you'll also need all these things, plus a history of commits, metadata about all commits and so on, right? Which brings me back to: why not do a full repository clone on the browser and get all that data at once? Is it just the big size of things?

What about doing a `git clone --depth 1`? I don't know how to do that on a JS library in the browser, but should be possible. Seems to be a pure client-side thing since it worked on 'song' (from the CLI) without me having to do anything on the server side.

OK, already answered here: But is it really that slow? It's hard for me to believe it is that slow since on my terminal it runs so fast!

I think it's still quite far from my vision, it's a work in (very slow) progress!

Anyway, I'll wait for your answer regarding the repository metadata required. I can't see a way around that if you want a nice way to browse through the repo and view things in context. But if the goal is just showing a README then that's much simpler.

The strange thing is that I don't see a CORS error when loading my repo page here. It's not even trying to fetch anything from the git.sprovoost.nl domain. But I'll try to allow **/raw/*

We discussed it back in March and here are some numbers for the bitcoin core repo: View quoted note → tbh those numbers are not that big. last time I checked, git implementations in the browser don't support these advanced flags. doing a full clone automatically in the browser is probably a bad idea as it is unfair on those who are bandwidth constrained. But this could be done statelessly on a server fairly quickly. bandwidth on a VPS is probably quite cheap these days so if traffic volumes were low it shouldn't be too expensive. Depending on the bandwidth vs storage costs it could be worth storing a clone of repositories and using that instead. That way it would be easier, or cheaper per interaction, to allow browsing commits, metadata, etc. From a decentralisation point of view, I could build `ngit serve` which could be used instead (even in offline scenarios) instead of the proxy.

I fixed the CORS header, but still not seeing the README (which makes sense give the above, the browser isn't asking for it): In case anyone else needs it: ``` map $request_uri $allow_origin { default ""; ~^/[a-z0-9]+/[a-z0-9]+/raw "*"; } ``` location / { ... add_header Access-Control-Allow-Origin $allow_origin; }

You could have a button to clone and display files, maybe? What library would you use in the browser to do a clone? I did git clone --no-checkout --depth 1 --filter=blob:none

GitHub

GitHub - bitcoin/bitcoin: Bitcoin Core integration/staging tree

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

and got 216K, ahahah.

O yeah?! I'm at a loss to think how I didn't try that before. This is the way.

My README page is still broken.

fixed by ae232c3ee1591f95070697af5cf9f1e284978445. I really need to get onto View quoted note → as I missed the notification for your previous reply to this thread: View quoted note → I'm just trying to ship some ngit updates then I can focus on gitworkshop.dev as it needs some love.

It works now!

Yes. two approaches: 1. git's `iterdiff` could be used to generate this within ngit and submit it as part of the cover letter (if one is included). There is too much duplication here and there is no garentee that PRs will include this as they may be generated by other tools. 2. apply the patch and output the diff. this could either be done in browser or by a proxy. Ideologically I don't like the idea of being overly reliant on a proxy as I think reliance on back-end infrastructure reduces the simplicity, robustness, and censorship resistance nature of a client. It looks likely that gitworkshop.dev will do a *shallow clone in the browser to deliver files and other git information. Experimentation is needed to see if PRs can be applied without checking out (and downloading) just the reliant files to the PR rather than all files in the latest state. Otherwise this could be bandwidth intensive for the user. Another possibility I have been thinking about is having nostr specific git implementations (like song) apply PRs submitted so the commits could be downloaded via the efficient git protocol and potentially could be used to access the PR diff in a bandwidth efficient way. Ultimately it would be ideal if we could do approach 2 with everything done in a bandwidth efficient way in the browser. *for context see View quoted note →