This is a thought I've been having for the time that a certain entity has been expending a lot more effort to suppress the capability of Invidious to access content. Please bear with me because it is late and I'm on maybe 4 hours of sleep, but this is when my best ideas just pop up.
I propose a distributed method to collect viewed content from Youtube then store it within the IPFS infrastructure. Of course each instance of invidious would be limited on what storage could be afforded to retaining a folder of collected videos - however the collective network of all IPFS instances could benefit by immediately being able to reference a CID (content identifier) if a certain video can no longer be streamed from the Tube.
I am thinking this would work one or two ways. I hope these case scenarios help clarify:
I. Automated Archival -- An Admin of an Invidious instance sets a specific number of views a frequently searched or linked video being accessed from his instance is to be archived. Once this number is reached - it is determined that the instance will automatically buffer the entire video using an utility like yt-dlp and also generating an CID and IPFS entity for other Invidious instances to reference if the video should be removed or otherwise made unavailable.
II. Manual Archival -- Whenever a user opts to share the invidious link by clicking a share button, the instance will archive the video and handle IPFS integration.
The net benefits;
Instances actively connected to the relevant IPFS network can handle interruptions in availability by asking other instances if they have a stored copy of the video a user wants to view.
Automatic archival of Youtube videos offers a censorship resistant solution to more controversial content and topics that may incur arbitrary enforcement.
Users can rest assured if they store a link to an instance that has archived the video, that it will continue to be available even if the instance is suffering from an access issue.
I would suggest employing methods to reduce the risk of automated abuse of clogging up an Instance's storage resources with Baby Shark. Not allowing redundant copies of a video to be stored and possibly introducing captcha challenges to any attempt to manually store or generate a share link for content addressed to the Instance.
unixfox
commented
2 months ago
This is a thought I've been having for the time that a certain entity has been expending a lot more effort to suppress the capability of Invidious to access content. Please bear with me because it is late and I'm on maybe 4 hours of sleep, but this is when my best ideas just pop up.
I propose a distributed method to collect viewed content from Youtube then store it within the IPFS infrastructure. Of course each instance of invidious would be limited on what storage could be afforded to retaining a folder of collected videos - however the collective network of all IPFS instances could benefit by immediately being able to reference a CID (content identifier) if a certain video can no longer be streamed from the Tube.
I am thinking this would work one or two ways. I hope these case scenarios help clarify:
I. Automated Archival -- An Admin of an Invidious instance sets a specific number of views a frequently searched or linked video being accessed from his instance is to be archived. Once this number is reached - it is determined that the instance will automatically buffer the entire video using an utility like yt-dlp and also generating an CID and IPFS entity for other Invidious instances to reference if the video should be removed or otherwise made unavailable.
II. Manual Archival -- Whenever a user opts to share the invidious link by clicking a share button, the instance will archive the video and handle IPFS integration.
The net benefits;
I would suggest employing methods to reduce the risk of automated abuse of clogging up an Instance's storage resources with Baby Shark. Not allowing redundant copies of a video to be stored and possibly introducing captcha challenges to any attempt to manually store or generate a share link for content addressed to the Instance.
Some recommended reading, (that I should also refresh on); IPFS Docs -- What is a CID? IPLD Docs