I was just setting up remote runners for TankieTube when I had an epiphany:
I could ask comrades to volunteer their own computers! 
That way those who can’t or don’t care to donate monetarily could still contribute.
How would it work?
Conceptually, you can think of it like a crypto mining botnet. Except it transcodes videos for the community instead of producing heat for individual profit. And it’s voluntary ofc.
It can run on any operating system with an internet connection. I’m going to use my gaming desktop and at least one VPS.
Tech level required: comfortable copy-and-pasting things into a CLI.
OpSec considerations: negligable as far as I can tell. There is no P2P involved. Your computer talks directly to the TankieTube server using sicko-to-HTTPS communication. The server would see your IP address, but that’s always the case on every website.
Thoughts?
Yes. Video decoders are complex software and ffmpeg has a long history of security patches. If those are the bugs we caught, what’s left?
Not really except that tankietube is probably more of a target than random anime pirates. But comrades, if you have a need for decent opsec, don’t be sailing the high seas.
This seems more like the sort of thing to run on something you can periodically nuke, and maybe put behind an external firewall that only allows communication with the tankietube servers. Maybe some comrades have spare credit on a cloud provider that would be suited for this.
This is a great idea but unfortunately security is always a concern.
edit: sorry if you got hit with a bunch of notifications, the reply was silently failing and I didn’t know what was going on so I retried oops
I think it is worth further research, at least. Setting aside potential exploits in ffmpeg, containerization (if not virtualization) seems necessary. A process running as root in a Docker container effectively has root access to the host, but a properly designed container should run all the work as non-privileged users. This work can be isolated using the cgroups APIs (docker should manage this, I think) and potentially reinforced with SELinux policies. Done correctly, this would effectively limit the impact of remote code execution in ffmpeg to denial of service. The attack surface for privilege escalation would then be limited to the Linux syscall API, utilities with the setuid flag, etc (highly, highly audited stuff that would allow you to root any machine if it were broken).
Alternately, it might be worth looking at bubblewrap, which is the basis of FlatPak containerization.
What is the threat model? The TankieTube server sends a malicious MP4 to the remote runner machine? Or a malicious remote runner sends a malicious MP4 to the server?
The former is easy to avoid by me not being evil. The latter is only a security concern for the TankieTube server, not the contributors.
Hostile user uploads a malicious video file, peertube instance sends it to a volunteer for transcoding, RCE occurs on volunteer’s machine.
So the concern is that a volunteer could have a more vulnerable installation of ffmpeg compared to the local server? How does that happen?
I think most prospective volunteers just want ffmpeg to run in a secure context without root, and stronger vouching of security by multiple knowledgeable users. The specifics of ffmpeg having vulnerabilities is not that important.
Do you vet all videos uploaded? I thought anyone could upload files to tankietube.
Yes. Anyone can upload, and videos are published automatically. I review the videos every day that have been published recently. I also rely on user reports.