Too radical

I'm not sure I quite understand this point, but perhaps it's not that important.
For any software I run on my machine, I'd **absolutely** want to be in control of what it stores on my machine. I'd hate for other users I don't know/trust to be able to push commits with malicious content and have that stored on my machine - and seeded from there to the rest of the network.

> The "cost" of operating a node, and especially the cost of guaranteeing proper data durability, is nontrivial. While it is true that the p2p network provides redundancy, there are no guarantees that peers will actually exist. Right now, if I want to ensure the durability of a git repo I care about, I just push a copy of it to github and I am done. This does not work in Radicle, unless I deploy nodes using a storage that guarantees that durability.

Or unless *others* run nodes that provide this storage for you (e.g. permissive seed nodes). Which is the same situation as with GitHub, et al. You're leaving the durability of the git repo you care about to a 3rd party.

> More generally, at a global level, it is more cost-effective to implement a desired degree of durability in a properly designed data center (like the ones used by github and other git-storage providers) than hoping that durability will magically happen in a p2p network.

Does Radicle prevent that?
Service providers can still run hosted Radicle nodes in their data centers and offer that as a service to other users who don't want to run their own infra. There seems to be an assumption here that a p2p technology excludes nodes that are running by professional service providers, in data centers. I don't think that will be the case at all - in fact, I *expect* that service providers will have an important role to play in the network.

> The most important thing is that to join the community, a new user would only need to add the appropriate metadata to their existing public git repos, and announce them in the p2p network so that they can be discovered. The barrier of entry would be much lower, the actual durability guarantees would be high, and the global impact of the project (in terms of consumed resources, like machines and electricity) would be optimal because large-scale data centers are engineered for that, there's no way for an ad-hoc p2p network to me more efficient than them.

There's quite a lot of context missing here, I think, but, if I understand correctly, this assumes we can convince the existing service providers to run radicle vs. just plain git. (Otherwise I don't understand how "adding the appropriate metadata" would allow information to be announced to the Radicle network). Depending on whom you ask, this may seem like a much bigger "barrier to entry" (they are happy with their existing forge software).

But I do agree, that we should try to get existing service providers to run Radicle nodes that announce information on the network! Such service providers can even provide *custodial* radicle nodes for their users (where their users' keys are held by the service provider - basically similar to how BlueSky works (without a Personal Data Server) and this would allow users to use Radicle through the web - without having to run a node on their machine.

Disclaimer: I am actively working on bringing one such service up online soon, so I am obviously a little biased! ;)