BookmarkHub keeps bookmarks in a Gist, and automatic sync is still on the roadmap

The database is a gist and the credential is a personal token

There is no server. The storage layer is GitHub's Gist, and the whole trust model follows from that. The setup steps are four: sign in to GitHub, create a token that manages gists, create a gist, then paste the token and the gist ID into the extension's settings popup.

So the credential the extension holds is a token with write access to your gists, and the data it holds is a file in an account you already own. The page makes no claim about token scope beyond the word gist, and it makes no claim about how the token is stored once entered, which is worth knowing before you paste one in.

There is a privacy note attached to the third step, and it is the only warning on the page: a public gist can be searched by others. A secret gist is unlisted rather than private, so the distinction being drawn is discoverable versus not, and a bookmark file carries titles and, depending on the browser, folder names.

The feature list claims sync, the roadmap says automatic sync is not done

Two sections of the same page disagree about the product's headline capability. The feature list includes support for cross-machine and cross-browser synchronisation of bookmarks, plus easy upload and download with one click. The roadmap, whose first entry is an unchecked box, reads automatically sync bookmarks.

The reconciliation is the word automatically, and it is a real distinction rather than sloppy wording. One click upload and download is a transfer the user initiates and observes. A sync is replication that happens without the user asking, which needs scheduling, conflict handling and a decision about what happens when two machines edit the same bookmark between pulls. None of that appears anywhere on the page.

The other four roadmap items, support for the webdav protocol, a mobile app, import and export, and sharing bookmarks, tell you what the author considers missing next. WebDAV is the interesting one, because it is the protocol this design would otherwise have needed, and it would replace the gist with storage the user hosts.

The source is 0.0.6 and the newest published release is 0.0.5

The manifest carries version 0.0.6. The newest tag is v0.0.5, published on 2024-12-20 under the single-word note update to MV3, and the one before it is v0.0.4 from 2021-07-25. So the tree is one release ahead of anything a user can install, and the two most recent tags are three and a half years apart.

The default branch was last pushed on 2026-04-06, which puts roughly sixteen months of unreleased work between the current source and the newest build in the stores. For a project whose newest release exists to move the extension to a newer extension manifest format, that gap is the thing to weigh: whatever changed after the MV3 move is not in anyone's browser yet.

The manifest is also marked private, so nothing is published to a package registry. Build artifacts are produced by the zip scripts and uploaded to the browser stores by hand.

Four install links, two of them the same Chrome Web Store entry

The installation section links four destinations. Chrome points at a Chrome Web Store listing, Firefox at an add-ons listing, Microsoft Edge at its own add-ons listing, and the entry for other Chromium based browsers points at the Chrome Web Store URL again, the identical address as the Chrome line.

That reuse is not a mistake so much as a statement about the extension's shape. A packaged Chromium extension is installable from the Chrome Web Store in other Chromium browsers, so there is no separate listing to link to. It does mean the page presents four bullets where a reader will find three distinct destinations, and that the Edge and Firefox entries are the only ones that indicate a build produced by a different target.

The Firefox target is visible elsewhere too, in the manifest, which defines a separate script per browser for both development and packaging rather than one build that covers every store.

Bootstrap 4, react-bootstrap 1, and Chrome type definitions three versions behind

The dependency list explains what kind of extension this is. It is a React application: react, react-dom and react-hook-form, with react-bootstrap and bootstrap 4.6 for components and react-icons for the icon set. On top of that sits webext-options-sync for storing extension options, ky as the HTTP client, and lz-string, an LZ based string compressor, which is a plausible companion to writing payloads into a gist, although the page never says what is compressed or how the bookmark file is encoded.

The build side is WXT, with module-react and auto-icons as the two WXT add-ons, and TypeScript 5.6. Two details will matter to anyone tracking versions. The package scripts are split per browser rather than shared:

"scripts": {
    "dev": "wxt",
    "dev:firefox": "wxt -b firefox",
    "build": "wxt build",
    "build:firefox": "wxt build -b firefox",
    "zip": "wxt zip",
    "zip:firefox": "wxt zip -b firefox",
    "compile": "tsc --noEmit",
    "postinstall": "wxt prepare"
  }

And the Chrome type definitions are pinned at 0.0.280, which is that package's own numbering rather than a Chrome version, so it tells you nothing about the browser the extension targets. The only statement about manifest versions anywhere on the page is the MV3 note attached to the 0.0.5 release.

A template README with scaffolding comments and a half translated usage list

The page is generated from a template and the template is still in the file. HTML comments reading PROJECT LOGO, TABLE OF CONTENTS, ABOUT THE PROJECT, USAGE EXAMPLES, ROADMAP, LICENSE and CONTACT are all still present, with an empty logo anchor where an image was meant to go.

The usage section shows the other kind of leftover. Step one reads as Login GitHub with a full width Chinese comma, then continues in English to the end of the sentence with a full width period. The page offers a language switch to a Chinese readme and back to the English one, so both files exist, and this line is the seam where one of them was updated and the other was not.

The contact section is two lines, an author name and a link to the repository itself. There is no issue tracker guidance beyond a Feedback link next to the title, no support statement, and no privacy policy, which for an extension that stores your bookmark history in a git repository is the documentation gap that would be worth closing first.

Apache-2.0 in the metadata, an empty string in the manifest

Licensing is reported three ways and the three do not agree. The repository metadata says Apache-2.0, the readme points at the LICENSE file for details, and the manifest's license field is an empty string.

The empty field is the one that travels. A manifest is what tooling reads when it packages and publishes an extension, and an empty license there is indistinguishable from an unset one. The consequence is small for a store listing and larger for anyone mirroring the source or building a derivative, because the identifier they would look for is not in the file.

The rest of the tree is small and tidy: a gitignore, the licence, the two readmes, a TypeScript config, the WXT config, a pnpm lock file, a src directory, and two image directories named assets and images with nothing on the page saying which one is current.

Editorial conclusion

BookmarkHub does one thing with a refreshingly small surface: your bookmarks live in a gist you control, and moving them is a button press rather than a sync engine. It suits anyone who wants bookmarks to travel without signing up for another account, and it suits nobody who wants automatic background replication, because that is an unchecked roadmap item. Before you paste a gist token into it, decide whether a gist is storage you are willing to keep, remember that a secret gist is still a git repository, and pin the package version yourself, since the source is a release ahead of anything published.

Frequently asked questions

Official sources

1. dudor/BookmarkHub on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases