A blockchain is overkill for this:
Its central goal of providing a clear ordering of events by the time at which they happened (t1 < t2 < t3) is not necessary to distribute software updates.
You merely want to be able to sort things by a number, the version of the software, which their author has provided on their own.
Remember, the blockchain was invented so Bitcoin could prevent double-spending of the same coins. I.e. if someone attempts to send the same money to multiple different addresses and thus fool multiple people into believing they were paid it can use the blockchain to determine which attempt was the first and ignore all others.
Such attacks would happen within milliseconds typically, hence the need for a strong mechanism against them.
This is not needed for merely distributing downloads:
You already trust the author enough that you would run their code, so you can as well trust them that the number which they say is the latest version in fact is the latest one. That's also because they have no incentive to fool you into using an older one, there's no money involved.
What you'd want instead is Freenet, the goal of which is preventing censorship and providing anonymity: https://en.wikipedia.org/wiki/Freenet
It's "updatable subspace key" (USK) address type is suitable here.
I guess that's not strictly necessary just to provide a binary update, but this feature could also be used to make the blockchain itself host the repo and its commits. Branches, pull requests, reverts, and everything could be stored as events on the blockchain. Differential commits do need that clear ordering of time to work.
Basically, imagine a decentralized version of Github.
Code is a well-chosen piece of logic to make sense as a whole. You can't just arbitrarily take to pieces of code and mash them together just because two random developers on the planet happened to write them one after the other in a sequential fashion of time.
E.g if you ask a classroom "What's 1 + 1 ?" then someone might say "3" right after you asked but before someone else says "2", but that does not make "3" right.
Proper order of commits is established by a MUCH more simple mechanism in fact: A git commit includes the hash of the previous commit in the history.
So the plain aspect of "storing some bytes" is needed, not a blockchain :) As someone else said, Git provides just that.
FWIW, censorship-resistant networks such as the aforementioned Freenet can and are used to publish Git repositories in a robust fashion. But no blockchain magic is required here either :)
I think a better strategy would be to separate the youtube-dl core "engine" from the set of rules/exceptions/offsets that it uses to iterate and download the media.
So the core youtube-dl could not download anything (or, perhaps, only a simple file at a static URL) and you would add a set of rules, or specs, that give it the ability to download from youtube or vimeo or whatever.
Then you would not worry about blocking youtube-dl or having it barred from github, etc. and all of the "rules" could be simply shared, or published, as simple text via pastebin or email or whatever.
I think hosting the development repository in a country that doesn't respect the DMCA is a simpler solution. Git is a blockchain too, after all.
Interestingly, the DMCA notice RIAA sent GitHub isn't a typical DMCA notice either. It seems to be more of a cease and desist along the lines of "we noticed this repo is a tool used to infringe on our rights -- sure would be a shame if you were to get caught up in the legal shitstorm that's about to happen, thanks!"
Let's take this objective:
>it can be switched from one host to another anytime without breaking that.
... that flexibility of any unknown host in the future then breaks the following code:
>if we could make a youtube-dl that dynamically fetched the latest working version
... and youtube-dl would download the latest version from where? What kind of "intelligence" does one put in the code to download from a future unknown http source?
One could try to be clever and embed a "intelligent algorithm" inside youtube-dl to scan the Google SERs[0] for the latest host source but that's not foolproof. Google may also later block results with the all-too-common censorship message "In response to multiple complaints we received under the US Digital Millennium Copyright Act, we have removed 6 results from this page."
Would youtubel-dl scan a well-known Twitter account or SMTP mailing list server to find the latest version? (My previous comment exploring that[0])
Storing binary blobs in popular blockchains like Bitcoin or Ethereum would be near impossible because of technical and architectural limits. (E.g. youtube-dl binary is about 1.7MB and thus miners will reject your non-standard transaction.)
I'm unaware of a foolproof way to share future versions aka future sources that can be programmed into deterministic code. Discovery will have to involve humans coordinating in some way. E.g. PirateBay moves from host to host but humans (not code) spread the new location.
[0] https://www.google.com/search?q=youtube-dl+latest+download
This is entirely possible :)
You would use an "USK" ("updatable subspace key") address of Freenet to achieve that: https://en.wikipedia.org/wiki/Freenet
Also see my other comment to the parent for an explanation of why Freenet would be preferable to blockchains here.
This is small enough that embedding it in a major blockchain is entirely feasible. There is also the much more boring option of hardcoding many different locations to find the URL.
>History youtube-dl was created in 2008 by Ricardo Garcia.[4] Initially, only YouTube was supported, but as the project grew, it began supporting other video sharing websites.[5] Ricardo Garcia stepped down as maintainer in 2011 and was replaced with phihag, who later stepped down and was replaced with dstftw.[6]
Would that be 3 different gpg signatures?
- gpg for Ricardo Garcia
- gpg for phihag
- gpg for dstftw
What would be the deterministic programming code algorithm to find the future unknown gpg signature for the latest non-malware version of youtube-dl on the blockchain?
Conceivably, one could create a project-specific gpg signature (private key shared with future authors) instead of human-author-specific gpg signer. Is that collaboration scenario common?
Doesn't work if latest maintainer loses access to their private key or dies or anything like that though.
Sounds like what you actually want is IPFS.
That way the command would "just work", "always work", and it can be switched from one host to another anytime without breaking that.