Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Archival Capability utilizing IPLD #4917

Closed
toxCat opened this issue Sep 13, 2024 · 1 comment
Closed

[Feature request] Archival Capability utilizing IPLD #4917

toxCat opened this issue Sep 13, 2024 · 1 comment
Labels
feature-request Request of a new feature

Comments

@toxCat
Copy link

toxCat commented Sep 13, 2024

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.

Some recommended reading, (that I should also refresh on);
IPFS Docs -- What is a CID?
IPLD Docs

@toxCat toxCat added the feature-request Request of a new feature label Sep 13, 2024
@unixfox
Copy link
Member

unixfox commented Sep 13, 2024

#879

@unixfox unixfox closed this as not planned Won't fix, can't repro, duplicate, stale Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request of a new feature
Projects
None yet
Development

No branches or pull requests

2 participants