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

Support fedilinks link previews #4429

Closed
wants to merge 1 commit into from
Closed

Conversation

SoniEx2
Copy link

@SoniEx2 SoniEx2 commented Feb 6, 2024

Implements what #4391 was supposed to be

@Nutomic
Copy link
Member

Nutomic commented Feb 7, 2024

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:

Screenshot_20240207_114606

So I dont think it makes sense to implement this without support from clients and frontends.

@SoniEx2
Copy link
Author

SoniEx2 commented Feb 7, 2024

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.

@Nutomic
Copy link
Member

Nutomic commented Feb 7, 2024

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.

@SoniEx2
Copy link
Author

SoniEx2 commented Feb 7, 2024

there is no url bar in an app.

@phiresky
Copy link
Collaborator

phiresky commented Feb 7, 2024

However browsers cant handle this url scheme by default and show an error message instead:

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
<a href="web+ap:foobar">

You will get these prompts:

image

image

after which the browser will open

https://lemmy.ml/api/v3/resolve_object?q=web+ap:foobar

there's a bit of discussion in this issue: #2987 (comment)

@phiresky
Copy link
Collaborator

phiresky commented Feb 7, 2024

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.

@SoniEx2
Copy link
Author

SoniEx2 commented Feb 7, 2024

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 /.well-known/protocol-handler route.)

@phiresky
Copy link
Collaborator

phiresky commented Feb 7, 2024

would probably be enough to get browsers to care.

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.

@SoniEx2
Copy link
Author

SoniEx2 commented Feb 7, 2024

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.)

@SoniEx2
Copy link
Author

SoniEx2 commented Feb 9, 2024

(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?)

@Nutomic Nutomic closed this May 17, 2024
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

Successfully merging this pull request may close these issues.

None yet

3 participants