Guerilla Open Tube: A Distributed, Censorship-Resistant Backup of YouTube | Hacker News Reader

Guerilla Open Tube: A Distributed, Censorship-Resistant Backup of YouTube

github.com

18 pointsobvio17121 comments

"Censorship-Resistant". Until your GitHub account or repository ends up here: https://github.com/github/dmca

You can use git without Github.

Yep, that's the idea. Github is just a nicety to help get things moving.

Another important point about censorship-resistance is that git works even by email, so worst-case people can still set up mailing lists and exchange patches.

https://www.youtube.com/yt/press/statistics.html

> 100 hours of video are uploaded to YouTube every minute.

"Backup" may be a strong term here. Perhaps you mean "mirror of specific videos"? I suppose in this regard, YouTube is acting as a reference index.

(I feel like such a pessimist today.)

"cache" would be a much better term to use, as there are specific DMCA exemptions that protect caches:

http://digital-law-online.info/lpdi1.0/treatise36.html

The linked page says:

"Subsection (b), service provider caching, exempts service providers’ making local copies of Web pages so that the pages don’t have to be fetched repeatedly over the Internet."

It doesn't sound like random people making copies of specific YouTube videos would qualify as "service providers". In the case of YouTube videos, wouldn't YouTube be the service provider who is allowed to create cached copies, like on a CDN?

From a legal point of view, making copies of YouTube videos available to the public would seem to be a straightforward violation of the video creators' copyrights, except in cases where they license the videos in a way that specifically allows such copying. I'd expect that copyright owners would get upset about this.

Thanks for the heads up. I've changed the wording in the descriptions.

Awesome. You can ignore my email :)

Why is a censorship-resistant tool linking to a Facebook post? I'm not going on FB.

Text only mirror of the announcement: https://gist.github.com/timelf123/e7bb350a8f93af3f824b

First place I published it after thinking about it. Didn't know if it would get any attention at all, so just went ahead and did the simplest thing by posting the FB link.

I'll fill out the README a bit more now, thanks for the feedback :)

Isn't this fundamentally just using GitHub as a torrent tracker?

I can't imagine that GitHub would be entirely happy about this, and it still leaves a third party (GitHub), functioning as registrar of torrents, vulnerable to attack, just as any public torrent tracker is.

While I agree GH may have a problem with this, in this case they aren't technically a "tracker" as they don't facilitate connections between seeds and peers. They just provide the metadata (magnet links)

TPB hasn't facilitated connections in a long time. They still got shut down.

TPB's problem is that it was a SPOF. Git is distributed, so even it Github shuts down repositories, people can just still pull from each other or move to a different host.

Assume you stored torrent metadata in the bitcoin blockchain. How would you shut that down?

Both git and the blockchain would be horribly inefficient.

TPB's magnet list in the end was about 40MB. If git were scaled to that sort of level, it would be far larger. Also there would need to be a lot of code written on top of git to automatically synchronize files between users. Git does not really solve many of the problems faced with a decentralized public database of magnet links.

A blockchain would be far worse. First of all, there would need to be some sort of currency backing it, and that currency would have to hold significant value to secure the network. A blockchain solves the problem of distributed consensus. A public distributed list of magnet links does not need such strong consistency guarantees as is needed for a financial transaction log.

Both git and the blockchain are useful tools but should not be used as a solution to every distributed computing problem.

The blockchain can solve a lot of distributed computing problems. It covers a very wide range of use cases, however, a large subset of those problems can also be solved with other algorithms which are far simpler, more efficient, and do not come with problems inherent to the block chain, the ever growing size, the wasted cpu-cycles, 51% attacks etc.

Then you still need to distribute the location of the metadata in the blockchain, wouldn't you? It's as silly as people who think they can store information as digits in pi.

The metadata itself would be in the blockchain. If you've got the blockchain, you have the data. You'd still need to find peers, but you've got the data for the content.

But where in the blockchain. It's multiple gigabytes, isn't it?

Reply on news.ycombinator.com