It’ll have to meet all the requirements, whatever those were 

 There weren't any really and I'd guess it was by design. But we knew what we needed to do. nostr:nprofile1qqsth3eu4eq4qtw667jpzfvxmjh5gg5pp4s25j6hccmue5d8g6c8s3qpzpmhxue69uhkummnw3ezumrpdejqzyrhwden5te0dehhxarj9emkjmn9qyxhwumn8ghj7mn0wvhxcmmv0v6v8t file storage was a crucial requirement to make this work over Nostr. 

 Man, that's a big rock to lift... 

 Thanks? Do you mean getting repositories and their contributors off github onto a nostr based solution is a hard challenge? 

 It's not a nostr based solution, it has a web address. 

 I was referring to NIP-34 

 Yes, NIP-34 requires a web hosted repository like gitworkshop.dev

 

 What do you mean by a web hosted repository? gitworkshop.dev stores no data. You can build it yourself and run it locally. You also don't have to use a web client. You can use a CLI like ngit or gitstr. 

 The data is stored somewhere on a single server. 

 The PRs, the PR commits, issues and comments and git state are sent via nostr events so they are on relays. And the data related to the state is stored on as many git servers as you specify. The ngit git plugin will push to and fetch from to all git server's specified by maintainers. The git data is also stored on all the contributors local machines... 

 The maintainerscann change git servers and when the users run `git pull` it will automatically fetch from the new servers. 

 ngit doesn't have a distributed consensus algorithm so there has to be the one server that's the one and only with the official source of truth 

 That's not the case. Anyone can express their view on what the state of a repository should look like by issuing a repo announcement event with a matching identifier. They can either issue state updates themselves, or list other pubkeys as 'maintainers'. This effectively delegates or entrusts these pubkeys to update the state, and  which git server(s) to get the data from, on their behalf.

When you clone a nostr repository you choose one pubkey you trust and follow their state. 

For most repositories, there will be a small number of maintainers who all list each other and permissions will appear much like a normal centralised solution. But its actually much more interesting and powerful.

Take a project like bitcoin-core. nostr:nprofile1qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgprdmhxue69uhhyetvv9ujucnfw33k76twwpshy6ewvdhk6qguwaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6qg5waehxw309aex2mrp0yhxgctdw4eju6t0udvd2m or nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uk3h9ux, who are knowlegable and respected in the community could create a repository announcement that lists maintainers they trust. They practically wouldn't have to do anything to maintain the state but could elect to change their list of maintainers at any time if they felt the movement was better served by a different set of maintainers. Everyone who chose to trust their pubkey for the repository state will now be served the state issued by their new selected maintainers.

This reduces the level of trust required in the actual maintainers by just a little and spreads it throughout the community. It certainly means there is no official source of truth.

Additionally, the use of the optional `maintainers.yaml` file, embedding the list of reccomended maintainers in the commit history, can act as a distributed concseus mechanism but thats a topic for another post. 

 So if forces wanted to shut down a repo they could query nostr for the current set of servers recommended by the pubkeys whom they assume to be the maintainers.

The repo could then be set up again on a different set of servers and the locations published via events. Until those get shut down again etc. etc., effectively playing cat and mouse.

In other words, yes there is the one authoritative server, or set of servers with redundant identical content via replication, but it's too short-lived to be a viable target. 

 Doesnt this same critque apply to censorship resistant nature of social media on nostr? But with git servers rather than nostr relays? I suppose its harder to query git servers for whether they are storing a user's repository.

In that scenario the maintainers could point to onion addresses which are harder to shut down? 

 > I suppose its harder to query git servers for whether they are storing a user's repository.

You should be able to query a server for "all repos signed by public key X" the same way you can query a nostr relay for "all events signed by public key X".

But on nostr relays can just store your events without your involvement. A relay can mirror another one just by pulling events off of it.

Your git server idea requires going back to the maintainer for each new server, the maintainer has to approve each new git server with a signed event that needs to be broadcast. So there's a bottleneck there.
 

 Maybe ngit can be augmented with an element of discovery. Where basically the user tells it to find a repo just identified by a certain public key, and give it a list of servers to try.

That would make it very nostr like. 

 This could work great for git server implementations designed to work with NIP-34 becausei repos could be addressable by, domain/pubkey/identifier a bit like how content is addressable in blossom. You could even have DVMs that could find git servers that serve the repo for you. 

 Beware that IPFS tried that ages ago and ... it doesn't scale well the same way nostr doesn't scale well.

They call it IPNS, basically you ask the network to find data signed by a certain public key. There are many more levels there than nostr because basically one server (relay/node/peer) can delegate to another one which delegates again sort of like DNS.

The more hops the higher the likelihood to find something, and something recent too, but the network bandwidth explodes. 

 No, that's the info site. Git is obviously already decentralized - but what's missing is the community part of GitHub like sites. This must be nostr-yfied ❤️ 

 nostr:nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7hycrvd is working at it 

 So is nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp with gitstr, song and patch32. He is willing because he created 3 nostr git clients vs my 2. 

 *winning 

 But the original git folder along with the source must be committed to a centralized server if I'm not mistaken right? What was interesting about nestr was that it used blossom for that part? I maybe wrong this is just what my brain came up with trying to understand these solutions.  

 The content of each commit in a PR is sent via nostr relays. The commits from maintainers pushed to the `main` branch are just sent to the git servers listed in the announcement event. However, is really easy for maintainers to change the git servers that everyone pulls from. NIP-34 turns git servers into dumb data relays similar to nostr relays. 

 Thanks! I'll checkout nip-34 again 

 You can self host GitLab. But that is a minor point.

I'm only speculating on why people may not just start using it right away. I certainly do see the benefit of it existing. But it seems that it isn't even released yet, so anything I said is moot until it can actually be widely used and feedback comes in. It is cool that you can push to both, but is that the same thing as fully using both in tandum without choosing one or the other as the primary? That sounds like a backup, but not really an ability to actually utilize both simultaneously. I just don't think it's going to catch on broadly for years and don't really see that as a problem with it as a concept. I suspect it will be used by a lot of smaller niche projects early on though. I will certainly be trying it out. But for really big projects? I just wouldn't take their silence as a negative sign necessarily. It can take years for bigger machines to seriously consider a new tech (See Bitcoin and even Nostr in general). 

 One huge benefit is that you don't actually need any external git server for Nestr so it's much easier than self-hosting any other git service. 

 You seem to think I'm arguing against the merit of the thing and in favor of another when I'm not. I'm simply pointing out that people don't tend to just immediately hop onto a brand new thing (before it's even available in this case) and that such a reality isn't a negative sign against the new thing. My comment applies to any brand new tech, regardless of the merit over alternatives or promises it makes. 

 No no, I actually think we're agreeing completely 😄 

 You make some good points there. I personally think the same way but I don't see Nestr as a backup since tracking issues over Nostr is more resilient than tracking them on a centralized platform. And I'm not expecting bitcoin core to jump on straight after launch 😄 that would be ridiculous given how slow core MUST go. And that goes for many other big projects as well like you said. 

 You are misunderstanding so many of my points that I'm going to go ahead and end the conversation. Thanks for your work and good luck. 

 I'm not worried. this is how new things begin. perhaps projects will start off using nostr alongside github and as usage grows on the nostr side, fully transition to only accepting issues and PRs over nostr.

@hzrd149 's noStrudel is just one example of a repository on the journey. its got 99 open issues and 4 open PRs on github and 5 open issues and 0 open PRs on nostr.

https://gitworkshop.dev/r/naddr1qqykum6nw3e82er9dsqs6amnwvaz7tmwdaejumr0dspzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qvzqqqrhny5zxf4f/issues

Issues and PRs raised on nostr get interest and engagement from across nostr and not just users using git specific clients. So the value proposition is quite different than self-hosted gitlab / forgejo. 

 Exactly. That's all I was really trying to say here. It takes time for things to catch on. Not seeing hype everywhere isn't necessarily a bad thing. 

 That and some people don't want to be alpha or beta testers for everything. I don't. Kudos to those who do. I do on occasion, but bandwidth is limited. 

 When I say bigger projects, I also mean developers even in the Nostr space working on some of the more popular applications. It may take time for everyone to learn and move over. All I'm saying is that crickets in the beginning aren't always a bad thing. It just takes time. 

 Oh yeah and then there's this project that you can use right now but it's only patches on Nostr. A bit different approach than what most devs are probably used to. We're aiming for a more complete solution with UX as close to GitHub as possible which has taken a lot more time. Especially the underlying scionic merkle tree storage system. 

 Do you know why clients haven’t moved over? I’ve seen some new repos but they still seem to be on GitHub 

 I think it is still early days.  Its as much down to where contributors choose to interact as much.
As the profile of #GitViaNostr grows I'm sure more contributors, and users with issues, will use it more. most nostr users don't even know about it yet. What's promising is that Issues and PRs are getting engagement from other nostr users, which don't really happen so much on walled garden self-hosted solutions.

nostr:nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy88wumn8ghj7mn0wvhxcmmv9uqzp7k9w4xm5e55tx2z2v05huehza49mvv7a8ncrr7f7xgf0nz6d6h9km8ynq 

 people love that microsoft in their veins 

 haha. Clearly the chronological algorithm that most clients use aren't surfacing the conversation you are most interested in.  

 Seems to surface everything BUT these conversations 

 For example, me collaborating with nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp on git.njump.me
We are using https://git.fiatjaf.com/song, that is compatible with nostr:nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7hycrvd work.
 

 https://gitworkshop.dev/repos shows repositories that have indicated they are receiving PRs and Issues via nostr