Add a Bearer-authenticated Latchshot bookmark preview provider

[BaiqingL]

Add a Bearer-authenticated Latchshot bookmark preview provider

Disclosure: I directly maintain Latchshot, the service proposed below. This is a provider-fit question, not a claim of Nextcloud affiliation.

Is your feature request related to a problem? Please describe.

Bookmarks currently supports provider-specific Screeenly and ScreenshotMachine previewers plus a generic direct-image URL. The generic path is not a safe fit for APIs that require an Authorization: Bearer header: using it for Latchshot would require putting the API key in the configured URL, which I do not want to recommend.

Describe the solution you'd like

Would you accept a separate LatchshotBookmarkPreviewer, modeled after the existing provider-specific previewers while leaving them unchanged?

The proposed path would:

• store one Latchshot key in a dedicated server-side app setting such as previews.latchshot.key and render it as a password field in admin settings;
• call only fixed-origin POST https://latchshot.fly.dev/v1/render with Authorization: Bearer … and a JSON body;
• request a public-page 800 × 800 JPEG with the existing two-second delay;
• accept only HTTP 200 plus image/jpeg, reject bodies above 15 MB, and then return the existing Image('image/jpeg', $body) type;
• reuse Bookmarks' existing one-month FileCache ownership and the admin test-preview route; and
• expose no custom endpoint, checkout, plan-changing action, or credential in a URL.

The renderer intentionally accepts only public HTTP/HTTPS pages on ports 80/443. It does not support cookies or login state, arbitrary scripts/actions, private-network targets, proxy rotation, CAPTCHA solving, or anti-bot bypass. Those boundaries would be stated in the admin copy rather than presenting this as a general browser or a drop-in replacement for every previewer.

Latchshot provides 100 successful renders per UTC calendar month without a card; only successful renders consume quota. Payment and plan activation remain outside Bookmarks and are handled separately by the service owner.

I have not created a fork or implementation PR because this repository's checks require a Developer Certificate of Origin sign-off. I am asking for provider/design fit first; no DCO-signed commit or PR should be created until the Latchshot owner separately reviews and authorizes that legal attestation.

Describe alternatives you've considered

• Keep using the existing ScreenshotMachine, Screeenly, Pageres, Webshot, or generic provider paths.
• Put a Latchshot key in the generic URL. Rejected because URLs are routinely logged, cached, copied, and exposed in diagnostics; the key belongs in a header.
• Add arbitrary headers to the generic provider. That is broader configuration and secret-handling surface than one fixed-origin provider, so I would not propose it unless maintainers prefer that abstraction.

Additional context

• Public OpenAPI 3.1 contract: https://latchshot.fly.dev/openapi.json
• Data handling and retention: https://latchshot.fly.dev/data-handling.html
• Existing preview-provider expansion precedent: Add more preview options besides screenly #741

The fixed request would be equivalent to:

{
  "url": "https://example.com",
  "format": "jpeg",
  "quality": 85,
  "width": 800,
  "height": 800,
  "delay": 2000
}

If maintainers prefer the generic-provider abstraction or do not want another hosted preview service, that answer would avoid an unnecessary implementation and DCO-bound pull request.

[github-actions]

Hello 👋

Thank you for taking the time to open this issue with the bookmarks app. I know it's frustrating when software
causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at
and if possible solved.
I'm Marcel and have been maintaining this software the last few years. I currently work for Nextcloud but maintain this app
in my free time, because it is not an official Nextcloud product. My day job at Nextcloud is pretty awesome but sadly leaves me with
less time for side projects like this one than I used to have.
I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it.
Until then, please be patient.
Note also that GitHub is a place where people meet to make software better together. Nobody here is under any obligation
to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can
collaborate to make this software better. For everyone.
Thus, if you can, you could also look at other issues to see whether you can help other people with your knowledge
and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and
try to fix the odd bug yourself. Everyone will be thankful for extra helping hands!
One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the forum,
to twitter or somewhere else. But this is a technical issue tracker, so please make sure to
focus on the tech and keep your opinions to yourself. (Also see our Code of Conduct. Really.)

I look forward to working with you on this issue
Cheers 💙