Quote from: n0nce on Today at 03:30:15 PM

Quote from: aliashraf on Today at 10:23:56 AM

Quote from: BlackHatCoiner on Today at 07:07:59 AM

Quote from: aliashraf on August 17, 2022, 10:10:33 PM

Once a repository is initialized, it comes with a built-in authentication metadata that includes a root public key which is committed by the fingerprint of the whole repository, hence immune to forgery.

This root public key. How can you make sure it isn't altered effectively, since repository is distributed among nodes. For example, what forbids a node change it, and send the entire repository to other nodes?

In the scheme, authenticity of a repository is hard-coded to its genesis and is not forgeable ever, though the genesis itself is a different story:
[...]

What I like about your idea is that a Git commit history is one of the few data structures that slightly resemble - and because of that might actually make sense to implement as - a blockchain.

Kudos, you nailedit. Cool

Quote

I see 2 issues:
[1] Embedding developer keys in the 'genesis commit' means they can't revoke them, add new ones or add new developers to the project down the road.

I've already addressed it above thread:
The authorization scheme is hierarchical resembling a pki infrastructure. As long as the root is not compromised, it is possible to grant/revoke authority to new/old keys, it would be possible for root to delegate its authority, share it, and so fort, all happening on-chain and without being considered as a fork. It is done by conventional commits (metadata is part of the repository after all), though downloading and processing of commits to metadata is mandatory for nodes, to check for potential tempering attempts by devs with lower/incompatible authority.

Quote

[2] You need a consensus mechanism, and as so often discussed on the forum, nothing works as well as PoW (if at all). So either it's built on top of a PoW cryptocurrency like Bitcoin, or you need to incentivize people to 'mine commits' using real-world energy resources.

Yes, it is the biggest issue, the only serious issue to be clear, other aspects of the scheme have been explored and addressed as much as it is possible for a lone ranger Tongue

but the incentive mechanism? It is complicated.

Firs and foremost, it is important to understand how deeply different is the case with a blockchain that supports the scheme I'm proposing for a truly decentralized Git, with bitcoin that is designed basically for solving double-spending of digital cash. Noticeably what bitcoin solves is a threat posed by the potential owners of the asset, whereas for repository owners it is the contrary, they have full incentive to keep their asset intact.

It would be a good analogy that repositories in my scheme are better understood as evolving NFTs, their ownership can be delegated though it is neither common practice nor subject to ordinary double-spending by re-org attempts.

Finally, and most critically, blocks in this scheme are rather batches of commits, they are signed and don't compete with forks or other repositories.

That all said, there is still the incentive problem remained in gray zone. I've been mulling this for a long time, not a conclusive result, just a few ideas:

1- I think, in this context, participating in an ultimately decentralized repository network, the altruistic factor should not be underestimated.

2- As I've said before, the actual download takes place on demand and is not part of the protocol which is only concerned about versioning and forks, it implies that the costs of participation are considerably low if not negligible.

3- Theoretically once a node supports one repository, as long as it tracks forks, it is open to multiple repositories, still in practice it is possible, though not encouraged, for nodes to “choose” a subset of the whole universal repository space to track, or even sticking with just the main branch. The drawback would be the potential obsoleting of less famous repositories/forks.

4-We have bitcoin p2p and full nodes as potential participant.

Spamming is another issue that I found as being important, interestingly it looks to be resolved by a game theoretic equilibrium, where spammers are suspected to lose support from nodes because of point (3) where nodes are free to restrict each repository they wish from their list.