Use XBEL to store bookmarks

[makew0rld]

(Original title was: Use JSON to store bookmarks. It was changed after discussion below.)

---

TOML is not appropriate for this purpose. Viper still might be. There will have to be migration code to detect the existence of the old .toml file and convert it.

[lachrimae]

Hey, are you open to PRs? I'm curious to contribute to the Ctrl+F search functionality, and maybe also this issue.

[makew0rld]

@lachrimae Definitely, happy to hear someone ask! I've been neglecting the search feature, so if you don't mind trying something difficult that's more pressing then this, then we can discuss it in #36. Otherwise feel free to contribute to any other issue I'm not working on already.

[Jackymancs4]

If I may, I recently came across the XML Bookmark Exchange Language (XBEL) specification. It appears to be a fairly standardized way to manages bookmarks in a file (XML instead JSON).
As noted in the project homepage, among the most notable supporting clients there are eLinks and Konqueror browsers. This seems a pretty good indicator of reliability.

Also as a bonus point (not sure though) go should have a fairly good native package to handle xml, no extra dependency required.

For documentation:

• http://xbel.sourceforge.net/
• https://en.wikipedia.org/wiki/XBEL

[makew0rld]

I can't say that I'm that interested in supporting this format. I mainly just wanted a way to store the bookmarks that is not inefficient/hacky like the current solution.

[Jackymancs4]

That's understandable but let me try prove its benefits. Also, I'm not a go programmer, so please forgive any misunderstanding.
A minimal example file .local/share/amfora/bookmarks.xbel:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xbel>
<xbel version="1.0">
    <folder folded="yes">
        <title>Main</title>
        <bookmark href="gemini://gemini.circumlunar.space/">
            <title>Home Page</title>
        </bookmark>
    </folder>
</xbel>

It's very straight (xbel->folder->bookmark). By default, it supports folders (should close #56 ). It supports an icon attribute which you can populate with the emoji favicon (so that it is shown in the bookmarks view.

This page https://gobyexample.com/xml shows that it is possible and fairly simple to map 1:1 a Struct to an XML file using the encoding/xml package, so (after some refactoring of https://github.com/makeworld-the-better-one/amfora/blob/master/bookmarks/bookmarks.go) it can be future proofed in case you add for example the ability to add a description the the bookmark (feat also supported by xbel).

And obviously, there is the advantage that since it is a third party standard, other apps like bombadillo could support it in the future, allowing for an easy exchange of bookmarks among people and clients.

The whole point was that since you decided to move from toml to json, which is a structured but loosely typed language, moving to xml (structured and typed) should be almost the same amount of work, with way more advantages.

A more complete example of file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xbel>
<xbel version="1.0">
    <folder folded="yes">
        <title>Main</title>
        <bookmark href="gemini://gemini.circumlunar.space/">
            <title>Home Page</title>
        </bookmark>
        <bookmark href="gemini://gemini.circumlunar.space/">
            <title>Home Page Again</title>
        </bookmark>
    </folder>
    <folder folded="yes">
        <title>Second</title>
        <bookmark href="gemini://gemini.circumlunar.space/docs/">
            <title>Docs</title>
        </bookmark>
    </folder>
</xbel>

[makew0rld]

Thank you, this is helpful. I may end up implementing this then, seems useful. I will indicate when I have started work on this, so if anyone wants to create a PR that does this before that point, feel free.

[sotpapathe]

Why not exploit the filesystem and Gemtext for this? This way no new rendering capability is needed and it is easy for users to edit/generate their bookmarks outside amfora. Keeping bookmarks as simple, plain-text files is a good thing IMO. If we restrict bookmark folder depth to 1, we could have something like:

$XDG_CONFIG_HOME/amfora/bookmarks/
├── folder1.gmi
└── folder2.gmi

where the contents of folder1.gmi are

=> gemini://example1.com Description 1
=> gemini://example2.com Description 2

[makew0rld]

@sotpapathe It's an interesting idea. I like the bookmarks being more structured, because they tend to be structured data, but I guess there's no reason why it can't just be a text file. It just feels a bit too loose to me, but I can't say I have a very good reason not to do it.

[sotpapathe]

@makeworld-the-better-one Maybe we can come up with an idea to have both structured and user-editable bookmarks. Another idea is:

$XDG_CONFIG_HOME/amfora/bookmarks/
├── folder1
│   ├── bookmark1
│   └── bookmark1
└── folder2
    ├── bookmark3
    └── bookmark4

where each bookmark* file contains just the URL. This has the advantage that it allows for arbitrary levels of nesting and creating/deleting/moving bookmarks is simple. But it requires special code to show the bookmarks (probably not too hard) and more importantly has the potential to create too many files.

[Jackymancs4]

This is only my opinion, but I'm fairly against this concept. Let me try build my case.

Why not exploit the filesystem and Gemtext for this?

As a general rule of thumb it is a bad idea to leverage the filesystem to structure data. It should act instead as a final destination for already processed data for long term storage. I can think of performances (number of IO), consistency, atomicity of operations and the like as generally hard things to tame even at small scale.

Personally, even though they are distinct, I consider the amfora bookmarks as
full fledged config files, and I sync it with my dotfiles management solution (so that I can have them on all my devices).
Having a lot of small files feels more cumbersome and noisy to manage than a single file. Also the shareability of the bookmark folder drops quite a bit, having to be zipped or something for distribution.

And I also can think of the hardships of debugging an eventual malformed bookmark in the middle of hierarchy of files and folders.

Keeping bookmarks as simple, plain-text files is a good thing IMO.

I disagree. Even an xml file is simple, plain-text (as in non-binary). Taking your example of text:

=> gemini://example1.com Description 1

It has a structure. Now add a favicon, a title, and the date of creation (separated by tab or ,) and you get a super compressed structured data format.

Maybe we can come up with an idea to have both structured and user-editable bookmarks.

IMO there is little point in reinventing the wheel, given how many products rely on bookmarking functionality. XBEL (or the original JSON file option) seems preferable.

PS.
@sotpapathe Great job closing #67 . I like it!

[makew0rld]

@sotpapathe I agree with everything @Jackymancs4 said, they explained it better than I could. I don't have a strong preference for XBEL over JSON, but I definitely prefer either over just storing files without a format.

[sotpapathe]

I can think of performances (number of IO), consistency, atomicity of
operations and the like as generally hard things to tame even at small scale.

Having a lot of small files feels more cumbersome and noisy to manage than a
single file. Also the shareability of the bookmark folder drops quite a bit,
having to be zipped or something for distribution.

Agreed, these are all valid reasons to avoid multiple bookmark files. I am not
opposed to having a single, structured file containing all bookmarks.

Personally, even though they are distinct, I consider the amfora bookmarks as
full fledged config files, and I sync it with my dotfiles management
solution.

I do the same, but I generate the bookmark files for my various browsers from
some text files I keep (lines of Description URL). My main issue with using
XML is that I find it too verbose and it's not easy to handle using standard
unix tools.

I don't have such a strong opinion on this, I can live with XML if it's
considered a better fit. My main issue with the current TOML file is that it's
not clear how the (base64?) URL encoding works, so it's hard to edit by hand.
XML solves this problem, so it's definitely an improvement for me.

@sotpapathe Great job closing #67 . I like it!

Thanks @Jackymancs4!

[makew0rld]

My main issue with the current TOML file is that it's not clear how the (base64?) URL encoding works, so it's hard to edit by hand.

This was my issue as well with how I did it originally, and why I want something new. XML isn't my favourite either, but I like that the XBEL format already exists and is clearly extensible and designed for bookmarks, as opposed to any bespoke JSON format I could come up with.

The current format is a base32 encoding of the URL, btw.

I feel pretty decided on this subject. Unless someone finds a format much better and more widely used than XBEL I'd like to stick with it.

[ghost]

I think it is a philosophical issue whether or not to invite an XML based language to a Gemeni software.

[makew0rld]

While some may have qualms about XML's relative complexity, I don't think it's that big a deal. And this part of Amfora has nothing to do with Gemini, and all the simplicity guarantees it has.

As I said above:

I feel pretty decided on this subject. Unless someone finds a format much better [for bookmarks] and more widely used [for bookmarks] than XBEL I'd like to stick with it.

[robertknutzen]

I think we could easily accomplish what @sotpapathe was talking about using gem markup, without falling into pitfalls of using multiple folders by simply using headers.

#category 1
=> gemini://example1.com Description 1
=> gemini://example2.com Description 2
#category 2
=> gemini://example3.com Description 3
=> gemini://example4.com Description 4

Right now it's very difficult to get bookmarks out of amfora, which is frustrating because it makes it very hard to share them between other clients. somehow my bookmarks are invalid base32 according to my command line?

At the very least storing them as .gmi would be a cool way to be able to have a single file you could at least access in other clients.

[makew0rld]

Using gemtext is a completely unstructured and flexible format, and so I'm not really interested in storing structured data like bookmarks inside it.

Converting the XBEL file to a nice-looking gemtext file would be an easy task though, and I'd be happy to include that kind of capability in Amfora, or maybe as an external script. So you could just run xbel2gmi ~/.local/share/amfora/bookmarks.xml > /path/to/other/browser/bookmarks.gmi. Once I add this feature I can try and write Python script that will do this and share it.

[makew0rld]

Spec reference: http://xbel.sourceforge.net/language/versions/1.0/xbel-1.0.xhtml

[makew0rld]

At long last this is implemented! Thanks for everyone's suggestions. The master branch version of Amfora will now move your existing bookmarks into an XML file and delete the old one. This makes for easy editing and managing.

[makew0rld]

Re-opened until the master branch properly supports multiple bookmarks with the same name. Also check support for bookmarks with different names but the same URL.

[makew0rld]

Fixed in 9fd5deb. Bookmarks with the same URL are not supported as that doesn't make sense.