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.