When you have many bookmarks, you'd better have a good book full of marks.

What: an informal specification

Goals:

• keep track of bookmarks
• have the concept of folder well integrated
• make sharing with friends easy with already available technologies
• supports tags and descriptions, too
• one file per bookmark
• CLI-first
  • but support
• python3

Storage

One file per bookmark

If you want to store a tree, let's just rely on filesystem!

Let's learn pass lesson: when you keep things simple, people can do crazy shit.

One quick example: if you want to share some folder with a friend of yours, having a REAL folder is the best way to make that simple. Easy share, few conflicts, easy review.

You can have some folder under git control, or rsync-ed, or shared through nextcloud.

Filename

What about the filename? Some approaches:

• GUID
• shasum of URL ⇒ you can't modify it!

File content

First line is the URL.

now we need to store description and tags. We want to be grep-friendly, so let's use a format borrowed from email (or from debian/control, if you want!):

URI: https://riseup.net/
Description: They are nice folks
Tag: privacy
Tag: change the world
Tag: email

Just avoid newlines in fields and you can do good queries just using grep

Performance

Won't this be very slow? maybe! If that happens, we'll work it around adding an index, not changing the storage format.

Interface

Searching/opening

Though non optimal, fzf, peco or similar tools can be a very good start: nice interface and support for opening multiple URLs at a single time.

Dreaming a bit more, it would be nice to:

• be able to both navigate the tree and filter results
• include frecency!

Moving stuff

If we have filtering, it's nice to be able to use it to move things around, or delete, or whatever.

Mass tagging

Having tools that can be used to automatically apply/remove tags to returned bookmarks is very nice

Examples

mxb list
mxb list coding/python
firefox "$(mxb list | peco | awk '{ print $ NF }')"
mxb list | peco | cut -f 1 | mxb tag +urgent
mxb list | peco | cut -f 1 | mxb mv work/todo
mxb mv coding/python/exercises/dfkljedua work/todo/
xsel -b | mxb add

Why

Are bookmarks abandoned?

Low development

Web browsers get tons of features in the recent years. In my opinion, they still suck at bookmarks. They barely do what they used to do in the early 2000's. Sure, most browsers added tags to bookmarks: but you can't search them in the bookmarks menu. At least in firefox, you can in the location bar, sure, but that looks messy to me: when something doesn't show up, it doesn't mean there isn't. Sometimes FF "logic" just hides that link to my view.

Low modularity

No browser is making any effort to make its bookmark system useful even when the browser is closed. There are so many reasons why that would be useful:

• having scripts to import/export
• sync with other browsers
• scripts that check for links that are nowadays non functional, dead, page not found, etc and clean the bookmark store

So we're stuck following every change to FF internal method of using that database, and adapt our scripts.

Practical use cases that suck

• moving bookmarks from one profile to the other?
• moving a single folder to another profile or browser
• export
• concurrent access (firefox keeps places.sqlite open, so it's locked)
• synchronization using already available tools (Firefox Sync started as something really cool and became something horrible)
• using multiple browsers, but a single bookmark store

My take on it

Bookmarks are abandoned to the point of being killed. Apparently, the new paradigm is the search: you can bookmark stuff, but you aren't really intended to browse bookmarks later. You can try to retrieve them using the location bar obscure mechanism of giving you what you might need.

I think this approach is flawed: it doesn't give the user much control over its notes, so he/her needs to delegate to some form of "artificial intelligence".

Why not any of the existing solutions?

I'm not the only one to complain about it, so there are very nice tools: buku and bm, to name just two of them.

I think their approach is on the right track! However, I don't like having single-file SQL databases. They will share some of the issues that most browsers implementations have:

• concurrent access
• synchronization using already available tools

So I'm trying to do a similar job, but using a storage that is simpler and more versatile.

TODO

• Core:
  • move()
  • tag()
• helper:
  • write a marxbook-search helper based on peco