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
Support fedilinks link previews #4429
Conversation
So this means you can create a post with url web+ap://example.com and Lemmy will fetch preview data from https://example.com. However browsers cant handle this url scheme by default and show an error message instead: So I dont think it makes sense to implement this without support from clients and frontends. |
it depends on the OS, not the browser. but implementing this is a good way to generate FOMO tho, which is a good way to get browsers to implement it in the remaining OSes. (also, web+ap should probably be handled by the lemmy frontend.) at the very least, it's no worse than the current magnet link support. except this also supports previews. |
Lemmy should not generate FOMO, it should just work. And I think you are using a completely wrong approach here. If you want people to open Lemmy links in their apps, the solution would be a button in the frontend for "open in app", which rewrites the url schema from https to web+ap. When users submit a link they will simply copy it from the url bar (with https scheme), and not manually change it to web+ap. |
there is no url bar in an app. |
Not sure about this approach exactly, but lemmy-ui could in Firefox and Chrome register a handler for those types of URLs with navigator.registerProtocolHandler(
"web+ap",
"https://lemmy.ml/api/v3/resolve_object?q=%s",
"Open in your own instance's Lemmy UI"
) After doing this, when any website (including other lemmy websites) have a You will get these prompts: after which the browser will open
there's a bit of discussion in this issue: #2987 (comment) |
And as a general comment about the web+ap proposal: It seems like it might be a bad idea to try and make generic "handles all AP content" handlers. AP has very different applications, and handlers can only be installed at the protocol level. So if you do this then lemmy would have to be prepared to handle all links to mastodon, peertube, etc. It would be nice if protocol handlers were more flexible, but sadly they are very limited and since browsers don't care it (especially with the security implications) seems unlikely this will change. |
on that note, since the fedilinks mechanism is fairly generic, lemmy could decide to just use web+lemmy and peertube could use web+peertube. in an ideal world you'd either manually pick the correct application, or there would be multiple layers of fallbacks. fedilinks is pretty flexible, as long as you strictly follow the Generic URI Syntax. but we did what we could with the APIs we have available to us. just having the fallback mechanism at all (and have application developers back it) would probably be enough to get browsers to care. (you should probably support the fallback mechanism in the frontend too, by handling the |
I highly doubt it. Chrome does whatever benefits Google, which certainly does not include making the stuff better that people use that hate ads. Safari does whatever benefits iOS, which specifically includes nerfing webapps because it infringes on their app market monopoly. Firefox mostly does whatever Chrome does, not because they are evil but because that's what they have to do to stay relevant. I plan to work on some proposals for handling cross instance links in lemmy, but in the end I think relying on browser technology is mostly not going to be very helpful. |
then we should probably ignore browsers and focus on apps! a native lemmy app has to process links, and it can do so in accordance with the fedilinks spec. (we've already tested on all major OSes and all of them can do it, so it is very viable. app store reviewers might reject it but we don't think this is against any of the app stores policies as of yet. they might catch up to it eventually tho.) |
(how do you contact app devs to ask if they'd be willing to back this change? it's not something apps can do alone after all, it does need the backend changes.) (also would it be bad to simply hide these from non-moderators in the web frontend?) |
Implements what #4391 was supposed to be