I’ve used TH72 a bit. I’d describe it more as shock proof than flexible. It’ll certainly make your miniatures robust, but it’s nowhere near as soft as something like TPU.

I know a joke about UDP.

I know a joke about TCP too.

Did you get it?

The point would be that it’s a failover. It takes about two seconds for the video here to start streaming from the webseed and that’s probably just the wait for enough video to load in order to render. The standard peers don’t really become load bearing until the server is struggling.

This is a good answer.

I’m not sure if I’d agree that instance to client is infeasible though. Peertube does it OK.

I wish IPFS was a solution but it’s just broken. I’ve got goto social running on a raspberry pi on a residential connection. If I try to run IPFS, my router crashes as it seems to try and connect to every peer on the network.

I’m thinking in terms of what happens when someone on a $5 VPS hosting plan uploads a large image or small video and a thousand other instances want to grab it. The latency of a torrent isn’t as much of a problem as the server falling over. This is for propogation between servers rather than when a user requests a file.

You could just have a standard peertube instance hidden away on the backend and use the peertube embed code to insert videos into your microblog and pretend the Peertube instance doesn’t exist.

I’ve played with peertube a lot, and as long as your cross site permissions are set up correctly, you can access the player API from your host site.

A torrent file and a webseed is enough. The client uses the torrent file to validate the download from a standard http source.

The webseed can be the same source as the file your browser would normally download.

So yeah the site needs to seed the file, but not necessarily using a torrent client.

I don’t know what that post is about. It’s not possible to change the contents of a torrent. The torrent file itself is a list of checksums which validate byte ranges within the files being downloaded. If a client downloads a poisoned piece, it discards it and deprioritises the seed it got it from. Perhaps they’re transcoding a file, whilst still seeding the original.

Torrents can work as a CDN for static files, because the downloader has to validate that the file is the same one as on the server using the checksums in the torrent file.

I’ve just been reading up on that. Apparently a magnet link won’t work without at least one proper seed, as it still needs to download the torrent file from somewhere. https://github.com/webtorrent/webtorrent/issues/1393#issuecomment-389805621

I think something like peertube would be a good solution for media, but there’s obstacles to getting it deployed in terms of adoption.

The player is quite mature and does everything you could want. For servers it saves resources by being peer to peer using webRTC. For clients it handles graceful degradation and redundancy.

A way it could be implemented for other drivers servers could go like this…

I upload a video to Lemmy. My Lemmy instance forwards that video to peertube. Peertube processes the video and releases it as unlisted. Peertube sends the URL back to my Lemmy instance. Lemmy publishes my post with the peertube player iframe as a video.

The issues with this are getting app developers and instance owners to adopt the changes and getting users to understand the implications of the P2P aspect.