GoSuki: a bookmark manager that watches your browsers without an extension

The problem: a bookmark set scattered across browsers and profiles

GoSuki describes itself as a multi-browser, realtime bookmark manager with no subscription or extension required, and the project's own framing is a list of questions that anybody with more than one browser will recognise.

Ever feel like your bookmarks are a chaotic mess. Ever find yourself swapping browsers when they stop meeting your demands. Have past bookmark managers let you down, vendor locking or abandoning you in your time of need. Would you rather avoid entrusting your bookmarks to cloud companies and browser extensions. Perhaps you keep multiple browser profiles for work, research, streaming and development. Do you use some obscure browser that doesn't support extensions.

The last two are the ones that decide the design. Multiple profiles is normal for people who separate work from personal browsing, and a browser with no extension support at all rules out every bookmark manager that works by injecting itself into the page.

The answer is a cloudless, extension-free, multi-browser and real time bookmark tracker and organizer that packs everything in a single binary and captures all your bookmarks in a portable database with multi-device sync and archiving capability.

The mechanism follows from that description. GoSuki does not ask a browser to report its bookmarks, it reads the bookmark databases the browsers write on disk, and it watches them for changes. The primary language is Go, the licence is AGPL-3.0, the homepage is gosuki.net, and the project is published for Linux, macOS, Windows, FreeBSD, NetBSD and OpenBSD, with Flatpak and Snap packages for Linux.

The browser list in the documentation is a long one, and it is the practical measure of the design. Firefox and its forks, LibreWolf, Waterfox, Pale Moon, IceCat, Zen and Basilisk, then Chrome, Chromium, Brave and qutebrowser, the keyboard-driven browser that supports no extensions at all. The documentation also has a page for adding your own browser, which is an honest admission that the list will keep growing.

Ctrl+D, hashtags, and the clipboard workflow

The interaction model is the part that differs most from other bookmark managers, and it is worth understanding before installing anything.

GoSuki uses Ctrl+D, the universal shortcut, to add bookmarks and to call custom commands. The universal qualifier is doing the work: the same key works whether you are in a browser that supports extensions or one that does not, because the program is reacting to the system clipboard rather than to the page.

The consequences are both good and slightly intrusive. You copy a URL anywhere, you press Ctrl+D, and the bookmark is captured with its title. The key is the same one browsers use for bookmarking, so the muscle memory is already there, and the habit of reaching for Ctrl+D after copying something is common. The cost is that the shortcut is global, so a bookmark can be added from a terminal or a document by accident, and the documentation's framing of the feature as a feature rather than as a toggle suggests the design leans into the always-on behaviour.

The tagging model is the second idea. You can tag with hashtags even if your browser does not support it, you can add tags in the title, and your folders become tags. That last one is the most useful, because it means the folder structure you already have is preserved as metadata rather than being flattened into a path, and the tags are available across every browser rather than being trapped inside one of them.

The features list also credits a real-time behaviour: GoSuki keeps track of your bookmarks, spotting any changes as they happen. The Go dependency list explains how, with fsnotify at version 1.6.0 for filesystem watching, which is the standard library choice for reacting to changes under a directory, and a file-locking library, gofrs/flock, which is what stops two instances of the program writing to the same database at once.

The web UI, the CLI and the multi-device sync

GoSuki ships a builtin, local web UI, and it also works without JavaScript, and there is a dmenu and rofi compatible CLI.

The without-JavaScript detail is the interesting one, because it is a design constraint rather than an accident. A local bookmark server that renders server-side is simpler to reason about, works in a text browser, and does not depend on a build step for the front end. It also means the UI is limited to what the server can render, so the interface is plainer than a client-rendered one.

The dmenu and rofi compatibility follows the same logic. Both are keyboard-driven launchers, and supporting their input protocol means GoSuki can act as a bookmark picker inside a keyboard-driven workflow, which is where a keyboard-first user already is. The dependency list has the terminal stack for it: charmbracelet/lipgloss for styling, muesli/termenv for terminal colour, termenv's sibling libraries for capability detection, and urfave/cli at version 3 for the command line itself.

Multi-device sync is one of the named capabilities, and the documentation links it as a feature page rather than describing it in the readme, which is where the details of the mechanism live. What the readme does say is that the tool is cloudless, and that the database is portable, and those two facts together describe the likely design: the database is a file, and synchronising a file between devices is a solved problem that the user controls rather than a service the vendor runs.

Archiving is delegated to ArchiveBox, which is the same tool the project's topic list names alongside buku, another bookmark manager. The reasoning is sensible: archiving a page is a separate problem from organising bookmarks, and a mature tool already solves the hard part, which is running a headless browser to save a page faithfully.

The build, and the Go dependency set as a description of the program

The Makefile is short and it tells you about the build constraints.

CGO_ENABLED=1
CGO_CFLAGS="-g -Wno-return-local-addr"
TARGETS := gosuki suki
COMPLETIONS := fish bash zsh

The first line is the one that matters. cgo is enabled because the SQLite driver, mattn/go-sqlite3, is a cgo package rather than a pure Go one, and the custom C flags exist to silence a warning that the driver produces. That has a direct consequence for the build, and the Makefile handles it: the comment about cross-compilation support via Zig notes that it is for CGO targets, specifically go-sqlite3, and there is a helper target that installs the latest stable Zig release, fetching the version list from the Zig download index, so that cross-compiled builds have a C cross-compiler available.

The two targets, gosuki and suki, are the program and its shorter-named companion, and the completion targets are generated for fish, bash and zsh, which tells you that the tool is expected to be used from a shell and that the maintainers care about completion.

The version is derived rather than written, using git describe with a dirty flag, so a locally built binary reports where it came from, and a non-dirty build reports the exact tag.

The Go dependency list is a good map of what the program does. Beyond the terminal and CLI libraries already mentioned, there is fatih/structs for mapping configuration structs, go-ini for INI style configuration, a TOML parser, a YAML parser, godbus for the Linux desktop bus, which is how a status icon and menu entries are published, energye/systray for the system tray, jmoiron/sqlx for the database access layer, swithek/dotsqlx for building SQL from Go structures, BurntSushi/toml and gopkg.in/yaml.v3 for configuration, OneOfOne/xxhash for hashing, hako/durafmt for formatting durations such as age of a bookmark, shirou/gopsutil for system information, google/go-github at version 66 for GitHub integration, and xlab/treeprint for printing trees, which is the shape of a folder hierarchy.

The Go version line in the module file is 1.26.0, which is a modern floor.

The repository tree is organised in the usual Go way, with cmd/ for the entry points, internal/ for the internals, pkg/ for the public packages, browsers/ for the per-browser database readers, hooks/ for the extension points, mods/ and packages/ for the bundled modules, contrib/ for the shell completions, docker/ for the container build, docs/ for the documentation site, generate/ for the code generation, and a test/ directory.

Where GoSuki is the wrong tool

The first limit is that the clipboard shortcut is global, and that is a deliberate trade with a real cost. A bookmark manager that watches the clipboard adds a URL to your database whenever you copy one, which means a copied link from a chat message, a command line or a document can end up in your bookmarks without you asking. The Ctrl+D requirement makes it deliberate, but a global hotkey is a program-wide side effect, and on a shared or remote machine it is the kind of thing colleagues notice.

The second is the local-only model. There is no cloud account, no web service and no vendor, which is exactly the privacy property the project advertises, and it is also the reason there is no cross-device sync that just works, no mobile client, no sharing with other people and no reading your bookmarks on a machine where you have not installed the binary. The sync is a file you move yourself, which is a fine trade for one person and a poor one for a team.

The third is the AGPL-3.0 licence. It is a strong copyleft licence with a network clause, and for a personal installation it means nothing at all. For anyone who modifies GoSuki and then offers it to others over a network, the obligations are real, and the choice of licence is a deliberate statement about the project's values that an organisation should look at rather than assume.

The fourth is the cgo build. A single binary with no dependencies is a strong claim, and it holds at runtime, because the SQLite driver is compiled into the binary. It does not hold at build time, where a C toolchain and, for cross-compilation, Zig are needed. A project that promises one static binary is usually written in a language whose SQLite story is a pure Go implementation, and GoSuki chose the cgo driver and then solved the cross-compilation problem with a Zig helper.

And the fifth is the browser coverage, which is a moving target. The list of supported browsers is long today and the documentation has a page for adding more, but every browser that changes how it stores bookmarks forces an update in the browsers/ directory, and the number of forks in the Firefox family alone suggests how many variations there are to track.

Editorial conclusion

GoSuki is worth trying if your bookmarks are scattered across several browsers and profiles, because the program watches the bookmark databases on disk and updates as changes happen, so nothing has to be re-imported, and because the database is a portable file you can copy, back up and sync yourself, and because the clipboard shortcut works the same way in a browser that supports extensions and in one that does not. It is the wrong tool if you want a hosted service with sharing and mobile apps. Before you adopt it, check three things: that you are comfortable with a clipboard-driven workflow, because adding a bookmark means selecting a URL anywhere and pressing Ctrl+D, which is fast and which some people find intrusive; that you understand the AGPL-3.0 licence, which matters if you intend to modify the program and offer it over a network; and that you check the build requirements, because the SQLite driver needs cgo, so the Makefile sets CGO_ENABLED=1 and the cross-compilation targets depend on Zig being installed.

Frequently asked questions

Official sources

1. blob42/gosuki on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases