4 ms·

Unless I'm misunderstanding you, there seems to be a logic gap in your proposal. Let's take this objective: >it can be switched from one host to another anyti

by jasode 6y ago

Unless I'm misunderstanding you, there seems to be a logic gap in your proposal. 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 https://www.google.com/search?q=youtube-dl+latest+download [1] https://news.ycombinator.com/item?id=24930317 https://news.ycombinator.com/item?id=24930317

0x0 6y ago
You could probably post a gpg-signed url to the blockchain, and scan the blockchain for new urls signed by a known gpg key. Or something like that.
- jasode 6y ago
  The gpg approach doesn't seem that reliable. Let's look at the paragraph about history of youtube-dl from wikipedia[1]: >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? [1] https://en.wikipedia.org/wiki/Youtube-dl#History https://en.wikipedia.org/wiki/Youtube-dl#History
  - 0x0 6y ago
    That's how android apks work. An app is signed with a public/private key combo, updates must match the same key. Surely something similar could be conceived. Keys could have an expiration date and someone would just need to post a signed update before it expires that implements an additional new key, then you could even upgrade extremely old versions through a couple of steps.
  - philsnow 6y ago
    Have each outgoing maintainer sign a string "I approve <new maintainer> whose public gpg is <public gpg key>"? Doesn't work if latest maintainer loses access to their private key or dies or anything like that though.
eMGm4D0zgUAVXc7 6y ago
> I'm unaware of a foolproof way to share future versions aka future sources that can be programmed into deterministic code. This is entirely possible :) You would use an "USK" ("updatable subspace key") address of Freenet to achieve that: https://en.wikipedia.org/wiki/Freenet 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.
gizmo686 6y ago
You do not need a resiliant method of distributing youtube-dl; just a resilient method of distributing the location where you are distributing youtube-dl, which is probably just a URL. 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.

by jasode 6y ago

0x0 6y ago

You could probably post a gpg-signed url to the blockchain, and scan the blockchain for new urls signed by a known gpg key. Or something like that.

jasode 6y ago
The gpg approach doesn't seem that reliable. Let's look at the paragraph about history of youtube-dl from wikipedia[1]: >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? [1] https://en.wikipedia.org/wiki/Youtube-dl#History https://en.wikipedia.org/wiki/Youtube-dl#History
- 0x0 6y ago
  That's how android apks work. An app is signed with a public/private key combo, updates must match the same key. Surely something similar could be conceived. Keys could have an expiration date and someone would just need to post a signed update before it expires that implements an additional new key, then you could even upgrade extremely old versions through a couple of steps.
- philsnow 6y ago
  Have each outgoing maintainer sign a string "I approve <new maintainer> whose public gpg is <public gpg key>"? Doesn't work if latest maintainer loses access to their private key or dies or anything like that though.

eMGm4D0zgUAVXc7 6y ago

> I'm unaware of a foolproof way to share future versions aka future sources that can be programmed into deterministic code. This is entirely possible :) You would use an "USK" ("updatable subspace key") address of Freenet to achieve that: https://en.wikipedia.org/wiki/Freenet 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.

gizmo686 6y ago

You do not need a resiliant method of distributing youtube-dl; just a resilient method of distributing the location where you are distributing youtube-dl, which is probably just a URL. 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.