[Feature request] Add a FediLinks protocol handler #3964
Comments
|
I don't think this is the right way to go at decentralising the 'net as it actually adds a centralised step - the fedi-to dereferencer - to opening any links. Decisions like this should be made locally, anywhere from LAN-level to the application used to access content, without referencing any intermediates which could track whatever the user is doing. Then there is the (ab)use of the protocol field to indicate content type, here I'd suggest simply using a parameter - something like what the Content-Type header is supposed to be used for but used as a parameter instead of a header. Those who have the required extension/add-on/content script installed will be referred to their proxy or application of preference while others will just use the original source. For Youtube this could look like:
Of course the name of the parameter should be chosen so that collisions are unlikely, Then there is the question of what this all has to do with federation as implied by the 'fedi-to' moniker. I understand that federation is all the rage at the moment with the Twitter-brouhaha, MetaFacebook's coming entry to this field and Reddit's antics but the use of content proxies like Invidious/Nitter/libreddit/etc is not related to federation in any way. Maybe 'link-to' would be a better name, or 'proxy-to', or 'gimme' or something like the 'sensible-browser/editor/pager/terminal' from Debian's sensible-utils package would be better, e.g. sensible-viewer. BTW, that "made by a queer trans person" reference in the fedi-to.net site is quite divisive, it may act like a rainbow flag to some but acts as a red flag to many others. May I suggest keeping sexual orientation (etc.) out of unrelated communications? |
|
If you don't like the fedi-to website being a website, make it a built-in OS/browser feature. Not like it really matters; the web is centralized, it's all controlled by the WHATWG anyway. Pick your poison. |
|
I'm sure anyone interested in using Invidious and similar services uses or at least knows about redirection extensions such as Privacy Redirect, Redirector, or similar - there's no need for "messing with editing URLs" if you want to use Invidious. I'm also having trouble discerning what feature exactly is this requesting: in the title you suggest that Invidious starts registering a protocol handler (for |
|
the idea is to familiarize users with protocol handlers and set them free from traditional platforms. the goal is to EEE the traditional platforms. |
|
Okay, but what's the Invidious feature being requested exactly? |
|
a protocol handler endpoint. we're not asking Invidious to actually call registerProtocolHandler, but to have an endpoint for a future registerProtocolHandler-equivalent. |
|
What's the benefit if this method over sharing youtube URLs and using a redirector extension (or alternatively sharing redirect.invidious.io URLs and selecting an instance)? |
|
wait what's redirect.invidious.io |
|
okay that's pretty cool. so the idea was to standardize an API for that kind of stuff, that also makes it user-overridable. so you could have e.g. (but we're still working on that "standardize" part.) |
|
One thing I don't understand, is how do you handle these
Who "registers" the protocol handler? To whom? How is sharing An other thing I don't understand, is who hosts this API you're talking about? |
|
oh no, we don't store user data. user stores user data. (it's called cookies, they're pretty great if you use them for their intended purpose, instead of tracking or profiling.) the long-term goal is to not have a centralized server, but yes the current approach is to just throw a centralized server at the problem. or to use one of the flows described in the Internet-Draft. how would an extension work? is invidious detectable by an extension? are there browser APIs for detecting whether a website does a thing (like "is an alternative youtube frontend") or does that rely on guesswork? |
|
From what I can grasp of this internet draft, each website have to implement something (a sort of popup?) in which the user will input a domain, and then get redirected if that domain supports that protocol handler, right? Isn't it a bit cumbersome? How is this faster than copy/pasting the URL into your home instance's search box (in the case of mastodon or piped, e.g)?
The extension I use (libredirect) works with a list of know instances URL per service (e.g youtube). But some others (e.g redirector) works with pure URL regex. List of instances can be gathered from online sources (like our official list) or managed locally. |
|
the Internet-Draft defines no particular interaction flow with the endpoint - the examples are mostly informative. but yes, that is exactly what the examples demonstrate. a perhaps more exciting interaction flow is provided by the the extension-based workaround sounds... well, it sounds fine. it does require installing an extension which is often not possible, so that makes it not great. but it's fine, if you can use it. but is that good enough? not everyone might agree that it is. |
|
Can you describe in detail and without vagueness how this would work for Invidious and which changes need to be made? |
|
invidious would define an URI format: invidious would then implement and that's it. |
SoniEx2
changed the title
Is your feature request related to a problem? Please describe.
Would like to be able to share youtube links without pointing ppl at youtube specifically. Ppl should just be able to use Invidious without messing with editing URLs.
Describe the solution you'd like
We made Fedi-To to direct ppl to the websites they wanna use. So for example we could wrap aweb+video://youtube.com/watch?v=whateverlink in a Fedi-To link, have it open in youtube for your average user, but have it open in invidious for your invidious user. This only requires the website to provide a protocol handler endpoint, similar to one used for registerProtocolHandler.We made The Fedi Links Project to improve mastodon and promote Atom feeds and other decentralized/distributed projects, and we're now up to 3 mastodon clients that implement it.
Describe alternatives you've considered
You could just use registerProtocolHandler directly but nobody uses that for a whole host of reasons, including the fact that you can't link to a registerProtocolHandler on some services. Meanwhile Fedi-To wrapped links are plain https and just work everywhere.Not really relevant anymore.
Additional context
Nothing else really relevant.
~~Oh right: https://fedi-to.net/~~~
The text was updated successfully, but these errors were encountered: