Does Buku support adding images to bookmarks?

[YousufSSyed]

I did some searching and it doesn't seem to.

[LeXofLeviafan]

At this moment, only the following fields exist:

• ID/index (non-editable, can change when a bookmark is deleted)
• URL
• Title
• Description
• Tags (sorted, lowercase)

Additionally, a metadata flag "Immutable" exists, for the purpose of excluding the bookmark from batch updates.

---

I've got some ideas on implementing extended bookmark records by adding support for custom fields (including images, at least as remote URLs); but at the moment there's no such thing and it's probably not gonna be a thing for a while.

There is, however, a good chance that I'll be adding support for rendering descriptions as Markdown to the webUI (bukuserver) fairly soon; in which case, it would be possible to include an externally-hosted image.

(Markdown image example)

![optional alt text](https://remote.site/path/to/image.jpg "optional tooltip")
![Markdown](https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Markdown-mark.svg/175px-Markdown-mark.svg.png
 "Markdown logo, from Wikipedia")

[YousufSSyed]

What do you think about having screenshots of pages with bookmarks that could be viewed in the web UI? I would help with searching.

[LeXofLeviafan]

…Alright, I didn't quite get that.

Do you mean some sort of a feature to generate such a screenshot automatically? (And storing such a screenshot in the DB as binary data, I presume?)
And what is this "searching" you are offering your help with? 🤔

[YousufSSyed]

Yeah, a feature to generate or get a photo of the page and show it in the web ui with the bookmark, and show the images when searching for bookmarks after entering something in the search bar (I haven't used the web ui, I'm just looking at the screenshots here: https://github.com/jarun/buku/tree/master/bukuserver#readme).

[LeXofLeviafan]

There's a concern of size when storing images in a DB file (though using WebP and smaller resolution reduces the image size, this screenshot converted to WebP would take up about 30Kb… multiply that by the number of bookmarks you're expecting to have, and I give no promises on performance when the file is that large 😅). Using an external site (e.g. Imgur or ImageChest) for hosting images might be a better choice for such a use 🤔

That said, there's also the question of how to take such screenshots. I can name 3 possible solutions here:

• Manually: user makes a screenshot, then copy-pastes it into the input (assuming such an action can be implemented with existing limitations on the browser), or "uploads" it from a saved file. This is the most technically feasible option, but not particularly convenient.
• With a script: using JavaScript running on the website you're making a bookmark for. I'm not sure if this would work completely correctly (JS is rather limited), and this would most likely require a companion userscript to be installed; on the upside, taking such a screenshot could be done automatically when invoking the bookmarklet dialog.
• With a service: using API of a remote service that generates such screenshots. This is basically the same exact JS solution, except instead of capturing it from your browser it would be done on a remote computer (and might not look the same way as in your browser). …Also, it appears that all such services require payment for long-term use (and of course they all have different APIs, if any at all).

I'm guessing it would be possible to implement the 1st and 2nd option (take the screenshot with JS if possible, but allow providing a user-made one as well), but the 3rd one doesn't really seem like a way to go.

…Either way, this is unlikely to be supported until/unless I implement extended records.
And I guess I'd need to redesign how the bookmark are rendered in UI first (…though that would probably be necessary regardless).

[LeXofLeviafan]

FYI, here's some proof-of-concept stuff related to this ticket:

• Rich-text formatting support in Description field, via Markdown (including images)
• Screenshots taking support in a custom Bukuserver bookmarklet

This relies on external tools (namely custom userscripts), but it works already, without a need to wait for Buku to support such functionality. …It's not exactly perfect, but as far as taking screenshots is involved it's probably as good as it can get.

(TL;DR it uses screen sharing API to take a screenshot… which happens to be much less complicated in Chrome-based browsers than in Firefox and presumably Safari as well)

[tathastu871]

Using screen sharing api has limited capabilities and support and also share privacy concern

Suggesting alternatives

1. Extensions/userscript available -> CaptureVisibleTab api
   eg -> extension like goFullPage uses this to take full page snapshots

2. With or Without extension/userscript (cors/csp affect) using limited javascript environment available on browsers

Using html2canvas or domtoimage like js libs that convert html dom to image, supprot png svg jpeg, with jpeg quality can be set to low to have small size image

3. In very limited environment (like on mobile browsers though not automated few manual step like using bookmarkelt that user need to run)
   Logic is to
   -> As browser has rendered html, use javascript to apply all document stylesheets as inline to dom elements, base64 embed images, then send page outerHTML to server, Thereby on server side we can have offline rendered html page almost like snapshot of how page looked in browser

-> That way we also archived a page, via buku, and can add new feature like offline browsing when no internet server can send this html page to be viewed

-> To main point, on server side we can then use any python go libraries, some like
wkhtml2pdf or weasyprint, that convert html to pdf

-> Then convert pdf to image using image magick

So what say on this ??

[LeXofLeviafan]

Using screen sharing api has limited capabilities and support and also share privacy concern

The "privacy concern" level is precisely the same for all methods (that actually work to begin with). Capturing the screen is the entire point of this; the way I did it at least ensures the picture is never actually shared outside of the intended usage. As for capabilities/support… it's actually better at "just working" than any other alternatives here; and a solution that only works correctly, say, on 30% of existing websites (on a good day), is not really a "solution" now is it? 🫠

And if you meant browser support, there's actually no issues with the usecase of taking a screenshot (other than the ones I had to work around):

And yes, I've researched the matter before ending up with this particular implementation.

…Also, if the user is concerned to that level with privacy over convenience, he'd just be taking screenshots manually instead (e.g. using builtin OS/browser screen capture functionality). Which to be fair would be my to-go approach as well (if I ever wanted to screenshot my webpages for some reason), but it's not the case being discussed here.

captureVisibleTab API

This requires using a full-on browser extension; which means much lower usage flexibility (no self-made functionality adjustments possible whatsoever) along with near complete usage opacity (the user cannot tell what's happening to the picture that was just taken, unless he looks up the extension repo – if available to begin with – and trusts that the code he's running is actually the one he found in the repo). As far as I'm concerned, that's much worse both on the privacy and on the utility side.

(Not to mention that it's basically the same exact thing that I did but with guaranteed less transparency for the user 😅)

html2canvas or domtoimage

These tools do not pass the criteria which is most important for the user: that it needs to actually work (regardless of the website, webpage content, and HTTP headers). Yanno, as opposed to being broken in any non-trivial usecase 🫠

Part of the reason for that is "privacy concerns" (which translates to intentional limitations enforced by the browser itself), which is why I had to discard this approach entirely.

send page outerHTML to server

This approach is even worse on that front; with it you can get botched images even in cases when html2canvas actually works! (…This doesn't include the limitations I've mentioned, but server-side rendering has a few major issues that prevent it from being useful for a number of usecases as well.)

In very limited environment (like on mobile browsers though not automated few manual step like using bookmarkelt that user need to run)

Honestly, general-purpose mobile browsers can go to the garbage bin; their UI is invariably inconvenient for anything beyond casual network search (e.g. for reading… good luck finding a mobile browser where landscape mode was not botched entirely 🫠). And yes, their extensibility is effectively nonexistent as well.

For mobile devices, a dedicated app would be necessary for most usecases – especially for extended bookmarklets (in fact, I'd be quite surprised to hear that the regular bookmarklet works there in the first place); and while we're at it, we might as well add screen capture capability to it. (…Not that any other approach can be used with mobile devices to begin with, other than going back to taking screenshots manually.)

That way we also archived a page, via buku, and can add new feature like offline browsing when no internet server can send this html page to be viewed

…If you want to download the Internet, that's on you. Me, I'd rather not have to support a half-baked feature which is guaranteed to perform worse than dedicated alternatives (like Internet Archive or the Ctrl+S hotkey, for instance); and would also bloat the database for sake of functionality that most people will never use to begin with.

(Also, that'd require implementing a separate API just for the sake of said feature. And I imagine it'd actually need to be invoked at separate times from screenshot taking, since unlike an image you can't really use it as form input data…)

almost like snapshot of how page looked in browser

If only… 🫠

---

The bottom line is: I've researched the matter, and the reason I've arrived at that specific solution is that it's the only one that actually works correctly. If you want an alternative implementation… well, no one is actually stopping you from making it, since the implementation has to be external to Buku in the first place, due to its nature 😅

(If you want to have the webpage download thing though, you'd need internal support for that; but then again, by the time Buku officially supports storing images, I would likely have plugins implemented as well – they both require extending current Buku functionality and DB schema, and I've been considering the idea of adding plugins support for a while, as they would allow for further customization of UX.)

[sjehuda]

The Atom Syndication Format has element "atom:link" with relation attribute "rel" which can be set with value "enclosure" to indicate of a file, so we can do this by adopting modeling the database in accord with The Atom Syndication Format (RFC 4287).

#795 (comment)

[sjehuda]

I have made a proposal of a database, which also includes this concern of graphical references.

#795 (comment)

Please refer to tables "txt_rel", "txt_uri" and "ele_link". URI can be "base64", "ftp", "gemini", "http", "magnet", et cetera.

Reference: 4.2.7. The "atom:link" Element

https://rfc-editor.org/rfc/rfc4287#section-4.2.7