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]: Better storage for Invidious instances #1910

Open
ccuser44 opened this issue Nov 14, 2023 · 5 comments
Open

[Feature request]: Better storage for Invidious instances #1910

ccuser44 opened this issue Nov 14, 2023 · 5 comments

Comments

@ccuser44
Copy link

ccuser44 commented Nov 14, 2023

Currently Sponsorblock stores the list of Invidious instances via two methods.

  1. If you haven't added any Invidious instances then the list if pooled from the source code.
  2. If you have added and/or removed any instances then the list gets stored with your changes. However it does not update.

The issue here is that you can either get an updating list where you can't make changes or an old list with your changes that does not update. Both have problems and are not an ideal solution.
Usually a lot of invidious instances get discontinued or are buggy and you need to add new ones even when SponsorBlock has not updated. This is horrible UX and makes using Sponsorblock very cumbersome with Invidious.
I propose an alternate way to do this.

In the new proposed way only the list of changes should be stored instead of all of the URLs. Example:

{
	"Added": [
		"https://iv.someurl.org",
		"https://videos.test.net",
		"https://asdfgwetyu.com"
	],
	"Removed" : [
		"https://www.url1.com",
		"https://invidious.example.com"
	]
}

Then when Sponsor block is loaded the list of changes is applied over the list from the source code.

This would fix the horrible UX of dealing with Invidious instances as well as be more storage efficient than storing all of the URLs.

@ajayyy
Copy link
Owner

ajayyy commented Nov 14, 2023

It cannot arbitrarily add instances because the extension would need to ask permission again when that happens

@ccuser44
Copy link
Author

It cannot arbitrarily add instances because the extension would need to ask permission again when that happens

Could there be a feature to run through the list of instances and check if the plugin has permission. If not then prompt permission from the user.

Like a button in the settings Check permission for instances?

@mchangrh
Copy link
Contributor

I don't think a changelog list would make sense at all, wouldn't

[...default list, ...custom list]

make more sense as you can add your own changes independently of bundled instances and they can be deduped at runtime/ when permissions are added

@iam-py-test
Copy link

I'm not 100% sure this will work (but it seems to in Firefox with my test extension), but what if you:

  • declare an optional permission of <all_urls> (no permissions prompt on install since it's an optional permission).
  • When the user adds a new instance, it calls browser.permissions.request({"origins": ["instance the user inputted"]})

Demo extension

Still would take some work to implement, and I'm sure there are better solutions.
Thanks

@ccuser44
Copy link
Author

I don't think a changelog list would make sense at all, wouldn't

[...default list, ...custom list]

make more sense as you can add your own changes independently of bundled instances and they can be deduped at runtime/ when permissions are added

In theory yes, but in practice no.
The list of workable Instances changes quite a lot (if you use an autotic redirector). A lot of the old instances get abandoned and lots of new ones are added.
You would have to add a lot of URLs when every list update (which is semi often) you have to add 40 new invidious instances manually

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants