On 1/20/22, k <gmkarl@gmail.com> wrote:

git-remote-ipfs hashes on blockchains

Those seem to be snapshots, if so, projects and users have to keep passing around current hashes. One form of blockchain based repo is... People can send patches to a project address, that maintainer can sign a tx to themselves containing accepted txid's, users could filter the chain for addresses they want to listen to. Get more features with multisig, smart contracts, etc. It works, is distributed, can be anonymous and or private as needed, is donation and funding enabled, etc. This might be new, if people develop and use it they should pay me some lump and yield, lol.

On 1/27/22, Undiscussed Horrific Abuse, One Victim & Survivor of <gmkarl@gmail.com> wrote:

what kind of chain do you imagine backing it? on-chain

Any kind of structure for which msgdata (patches) can be sent to addresses (repos), and that maintainer address can then sign and send a msgdata tx (branch update, release) out to itself that contains a list of accepted patches (selected from earlier txn's that were sent to that address). BSV, ETH... anything that could store a repo's worth of ongoing patch tx's since a repo (address) was init (generated and published as being a project)... could be used for this right now today, if the tx cost were free. Even if not free, crowdfund to that address, hand the funds out to developers to use to pay tx cost, fund devs addresses directly, etc. Code branch/fork side/subtoken chains, whatever... in the end, like onchain, they're just bitfields and part of global available cpu/disk/network.

would the data be ipfs

Content-addressible requires you to be passing hashes around with some other tool, it's an unnecessary layer when a chain can just hold all the patches themselves directly as tx's. Perhaps then use the txhash as index referencible content hash, patches would want to include them to make it easier and automatic to figure out what they were based on and apply to. Decentralized probably involves more work there figuring out and deciding/marking what the tip of HEAD looks like than does git. Maybe you're not going to be using some git to keep rereading even a fully indexed chain directly (inefficient), but are maybe just scraping patch sequences that were sent to an address out of the chain, through maintainer/committer acceptance filters, into a simple local repo, then you can use a hacked git to emit your commits as patches sending them back out to the repo address on the chain. It's not meant to be featureful, but it could turn out that way because you can define the API, bitfields, etc. However it may solve how to do a globally distributed repo, detached realtime redundant cryptographic uncorruptible consensus etc. None of today's "dvcs (Git)" or even "databases (Oracle)" seem to offer that. Closest historical simplistic analog would be stitching together split files posted to NNTP. This one has its own ticker symbol: [G]CODE People can invest in it, work remotely, earn dividends, etc.

Pre-existing economic models of, and networks for, value/currency... are unlikely to be usable, since their motivations, valuations, and participation are not centric to or aligned with "code". ie: Though it maybe / is possible, to directly build and use a repo upon existing native ETH/BTC network, it would be futile due to high per tx fees and tx/day limits. Global democratization of coding, code, access, even grand socialized determination of dividend-for-accepted-work, etc... out to third world accessibility, requires repo operation fees to be trivial, say $0.001 per op, or even "free" depending on the network model. Either clone and tune an existing network that can work, or create one optimized as a global coding repo from scratch. A "blockchain on a git" is not a "git on a blockchain". A global repo that depends on DNS/dotcom services, that isn't replicated, under consensus, etc... isn't "permanent" and won't survive censorship's assault against critical application code and its metadata. PGP, DeCSS, MP3, and PopcornTime were examples of app code whose survival was under duress and thus forced to go mobile to survive. A global distributed repo running at a level of 1000+ repos, 500GiB, 1000tx/day, or larger will be quite hard to shutdown than Bitcoin since its primary purpose is not money but codespeech. More apps that need code censorship protection will surely be coming in the future. Github, and even git on an onion/i2p, neither being distributed stores, will hardly provide enough resistance.

On Tue, 9 Aug 2022 15:21:01 -0400 grarpamp <grarpamp@gmail.com> wrote:

Distributed uncensorable p2p code repositories, networks,

"do not exist. They are a fucking lie promoting but subhuman pentagon turds like you." should have been "do not exist. They are a fucking lie promoted by subhuman pentagon turds like you." worth repeating yet again : "Distributed uncensorable p2p code repositories, networks," do not exist. They are a fucking lie promoted by subhuman pentagon turds like grancrap.