MarkWeave

Weave every browser’s bookmarks into one intelligent library.

Comment

MarkWeave

Inspiration

As an independent developer, I use Chrome, Microsoft Edge, and Firefox for different kinds of work. Over time, my bookmarks became fragmented across browsers, profiles, folders, and synchronization systems.

The same website might appear several times under different titles. Some bookmarks had moved permanently, some required authentication, and others no longer existed. Traditional bookmark managers could store links, but they did not answer the questions I actually had:

  • Which bookmarks are duplicates?
  • Which URLs are still usable?
  • How should thousands of links be reorganized?
  • How can the same collection remain portable without depending on a single browser vendor?
  • How can destructive cleanup remain reviewable and reversible?

MarkWeave was inspired by the idea that bookmarks should not be treated as isolated browser records. They should form a portable, searchable, and user-controlled knowledge library.

What I Learned

The first important lesson was that cross-browser bookmark management is not simply an import-and-export problem.

Each browser exposes its own bookmark tree to extensions, but an extension running in one browser does not automatically control the bookmark databases of the other browsers. A reliable solution therefore needs a small extension in every supported browser and a shared local component that maintains a canonical representation of the data.

I also learned that URL validation is more complicated than checking whether an HTTP request returns 200 OK.

A URL returning 401, 403, or 429 may still be valid. Some servers reject HEAD requests while accepting GET. Redirects may point to the current canonical address, and temporary server failures must not be treated as permanent deletion signals.

Duplicate detection has similar ambiguity. Two bookmarks can be exact duplicates, canonical URL duplicates, redirect-equivalent links, or semantically similar pages. These cases require different levels of confidence and should not all trigger automatic deletion.

For an initial duplicate candidate score, MarkWeave can use a heuristic such as:

[

D(a,b)

0.55 I(u_a=u_b) + 0.25\cos(e_a,e_b) + 0.20J(t_a,t_b) ]

where:

  • (I(u_a=u_b)) indicates whether the canonical URLs are identical;
  • (\cos(e_a,e_b)) measures semantic similarity between embeddings;
  • (J(t_a,t_b)) measures title-token similarity.

These weights are starting assumptions rather than empirically validated constants. They must be calibrated against real bookmark collections before being used for automatic decisions.

How I Am Building It

MarkWeave is designed as a local-first system with four major layers.

Browser adapters

A browser extension is installed separately in Chrome, Edge, and Firefox. Each extension reads the bookmark tree belonging to its current browser and converts it into a common data model.

The adapters also listen for bookmark creation, update, move, and deletion events. Instead of treating browser-specific node IDs as global identifiers, MarkWeave maps them to stable internal UUIDs.

MarkWeave Core

A Windows companion process acts as the local source of truth. Browser extensions communicate with it through Native Messaging.

The core component is responsible for:

  • maintaining the canonical bookmark database;
  • validating URLs;
  • normalizing URLs;
  • identifying duplicate candidates;
  • requesting AI classification;
  • producing reversible change plans;
  • synchronizing encrypted data to WebDAV or GitHub.

The core never directly rewrites a browser database file. It sends explicit operations back to the appropriate browser extension, which then uses the browser’s supported bookmark API.

Intelligence pipeline

AI is used as an assistant rather than as the final authority.

Deterministic rules first extract the domain, URL path, existing folder, title, keywords, and previously accepted categories. The AI model then returns structured suggestions containing:

  • category path;
  • tags;
  • normalized title;
  • short description;
  • confidence score;
  • explanation.

Low-confidence suggestions remain pending for review. AI classification does not directly delete, move, or merge bookmarks.

Synchronization

The local SQLite database remains the operational source of truth.

Remote services store an encrypted, portable representation of the bookmark library. WebDAV uses resource versions such as ETags to detect conflicting updates. GitHub synchronization uses repository file revisions and commit history.

Every destructive operation is written to an operation log so that a user can preview, apply, audit, and undo changes.

Challenges

The most significant challenge is conflict resolution.

A bookmark may be renamed in Firefox, moved in Chrome, and deleted from another device before synchronization finishes. Browser node IDs cannot solve this because they are local to each browser profile.

MarkWeave therefore needs stable internal identities, tombstones for deletions, source revisions, and deterministic merge rules.

The second challenge is safe deduplication. Removing an apparently duplicated bookmark may discard a useful title, folder location, tag, or browser-specific context. MarkWeave treats deduplication as a merge operation rather than a simple delete operation.

The third challenge is privacy. Bookmark collections can reveal professional interests, private infrastructure, financial services, health research, and internal company URLs. API credentials and synchronization data must never be stored as plain text in the extension package.

The final challenge is scope. Building AI classification, URL validation, multi-browser synchronization, conflict resolution, encryption, and a polished user interface at the same time would create excessive complexity for an initial release.

For that reason, the first version of MarkWeave focuses on one Windows device, three browser adapters, a local SQLite database, exact duplicate detection, URL health checks, and encrypted backup. True multi-device synchronization and semantic organization are introduced only after the local data model and operation log are proven reliable.

Built With

Share this project:

Updates