Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

Ok, let's go beyond general principles about mailing lists and be more concrete in thinking and see if a truly censorship proof dev & distribute architecture is possible.

Let's work backwards from this desired command line:

  youtube-dl -U

That command automatically downloads latest version. (Important because Youtube, Vimeo, etc changes constantly and breaks old youtube-dl versions.)

We have 2 main areas to implement:

1) the code artifacts: a source code repo (and binary releases for download) ; for Linux kernel, I think this is "www.kernel.org"[1]

2) the workflow: the issues / bug reports / pull requests ; for Linux kernel collaboration, a popular mailing list is "majordomo@vger.kernel.org"[2]

If youtube-dl switches from github to mailing lists, how would the "-U" command work? Would somebody need to setup a SMTP server (or at minimum, a SMTP email account) dedicated to youtube-dl? Would youtube-dl then use SMTP protocol to scan the mailing list for which server has the latest code artifacts?

Does making youtube-dl act as a pseudo email-client make it RIAA proof? Are SMTP servers beyond the legal reach of RIAA?

EDIT to reply: This article is about the developer workflow, not about what the end-user software should do.

I understand that but I think it's productive to go beyond that and think out loud what a realistic implementation could be to help end users. Besides, many end users are also the code contributors.

[1] https://www.kernel.org/

[2] http://vger.kernel.org/vger-lists.html#linux-kernel

youtube-dl -U would be challenging without a download server, but, the issue here is collaboration. Many people have copies of the youtube-dl repo, and many people can build the youtube-dl binary if provided the up-to-date changes. But to develop youtube-dl, they need to be able to continue to collaborate, which is currently at risk due to the DMCA takedown.

If they can continue to share patches over distributed mediums like a mailing list, they can continue to collaborate, and share improvements to the youtube-dl code that many already have copies of.

Possibly not a fantastic long-term solution, but certainly worth attempting whilst fighting it out with the RIAA.

Another important point is that many projects use GitHub as their general communication about issues, support, roadmap, etc. When GitHub suspends a repo, all of it goes away. Whereas Sourcehut is selling the point that your collaboration tools would survive even if they were required to remove your code.

Just a reminder: git was developed as, and can be used as a decentralized source control system. You don't need github at all. Github came 3 years after git was invented.

Sure, but it is difficult for everyone to work on the same tree if they can't communicate over a given web endpoint.

At minimum, a mailing list allows you to coordinate shifts to a new repository location, which might be hard if all of your communication was via GitHub.

Why can’t you distribute latest commits via a mailing server? git fetch becomes a “check your inbox”, git push sends an email to the list.

Are commit sha1/256 values preserved when using git format-patch -> send-email -> am? If not, then that would be a problem for signed commits or tags I think.

If you're sending trees with history, I think you're looking for commands like `git fast-export` and not mere patches.

Email is usable for code commits. Some people update git over smtp today. For artifacts, I envision Usenet or distributed rsync on Tor.

    youtube-dl -U

    Fetching signed update from usenet over TLS...
    Validating GPG signiture...
    Installing...
    Updated to youtube-dl-20201029

People could subscribe to artifact updates over email, but the client won't know how to get it. You would need a plugin that allows mapping to a local mail dir or a plugin that has an imap library to fetch updates and validate GPG signature. Or maybe use a plugin that talks to Tor relays? This is all hypothetical of course. I am not factoring in legal consideration and risk to the developers.

I think that your concern about the SMTP server is the serious issue. In the end, (for the RIAA) it should be indifferent whether the source code can be accessed using git/http/smtp, whatever protocol.

So, in any case, it looks like the idea is not good to fight that issue (right now no one prevents anyone from sending his copy of the master of youtube-dl and letting other people reproduce it/develop it). The use of a mailing list is just an improvement over this but it should be perfectly possible (for the RIAA) to take it down as well.

The RIAA can't reach into everyone's mailbox to get the code (patches, etc) out. If everyone's commits are signed, you can rebuild the repo at anytime from anyone's mailbox contents. It's SMTP/IMAP/JMAP DHT/Bittorrent. Automating git pulls (cron or similar) accomplishes that same thing, but with more effort on everyone's part.

Yes but mailboxes are usually kept private. That is why it is more cumbersome than torrent.

This article is about the developer workflow, not about what the end-user software should do.

Developing free from censorship is useless if you can't ever reach the user due to censorship

The author isn't saying that isn't important. The author is just tackling one aspect of censorship resistance.

You can use git as an ‘end user’. You just pull or clone without ever contributing.

Off the top of my head, an auto-updater in a legally hostile environment could work through a hard-coded a network of mirrors updated in every new version, torrent protocol, etc. It’s a feature, even if complex it can be addressed with development effort, and it only really becomes impossible if development is not happening.

You could:

* use the blockchain to distribute a magnet link for the latest revision, and

* use the torrent protocol to download the latest revision

This is one of the few legitimate uses for blockchain tech (besides money) that isn’t just an ICO scam. Bitcoin solved zooko’s triangle! We should make use of that.

In retrospect: you could do the same on a mailing list with lower latency and higher energy efficiency.

git-ssb has interesting properties.

https://github.com/noffle/git-ssb-intro

git over i2p seems a good option as well to go outside RIAA proof.

Reply on news.ycombinator.com