What Is a Bookmark?
I’ve been spending some time building a bookmarking service on ATProto and, as part of that, trying to understand how people think about lexicons and interoperability.
In talking it though at last weeks Side Project Saturday, Jared was kind enough to suggest that perhaps others in the community were already thinking about this. Oh right.
I’m still relatively new to the ecosystem, so this post is partly a request for feedback before I wander too far down a path that only makes sense in my own head.
My starting point was the community bookmark lexicon:
community.lexicon.bookmarks.bookmark
What struck me was how minimal it is. A bookmark is essentially:
- a URL
- a timestamp
- tags
That’s it. It is simple, easy to implement, and easy to reason about. However I think its too simplified to be practical – I think.
As I started building an actual bookmarking application, I found myself wanting additional fields.
Some examples:
- visibility (public vs unlisted)
- notes
- title
- description
- author
- publication date
- site name
- thumbnail image
- canonical URL
- provenance (where a bookmark was re-saved from)
The deeper question, though, is not whether any particular field is useful. The question is: what exactly is a bookmark?
I’m focused on bookmarking articles, stories, papers, blog posts, and so on. For others that won’t be enough.
Looking around the ecosystem, there seem to be a few different interpretations. I’m still catching on early conversations around it.
One interesting example is KipClip. Rather than storing everything directly on the bookmark record, it introduces a separate annotation record for additional metadata and user interaction.
https://github.com/tijs/kipclip-appview/blob/main/lexicons/com/kipclip/annotation.json
I can see the appeal but my instinct has been to push more information into a single bookmark record. Creating multiple records to represent what feels like a single bookmark object doesn’t quite sit right with me. Maybe that’s because I’m approaching this from a traditional bookmarking-product perspective rather than an ATProto one.
Bluesky’s bookmark implementation appears to be focused on saving references to existing records. In that model, a bookmark is primarily a saved pointer.
The community bookmark lexicon takes a similarly minimalist approach – for URLs rather than social records.
The direction I’ve been exploring is slightly different. When I save something, I often want more than just the URL. I want enough metadata to preserve context if the page changes, redirects, or disappears in the future.
The bookmark is no longer a simple reference toward something closer to a lightweight snapshot.
And that is where I’m no longer sure where the line should be.
For example, fields like reading status (unread, read) initially felt important to me. The more I’ve thought about it, the more I suspect that belongs at the application or service layer rather than in a shared lexicon. Different applications will inevitably have different workflows and states – but if I moved to another service might I want a record of which ones I’d already read? Should it be public like that? I am conflicted.
Metadata feels less clear-cut.
If multiple bookmarking applications are independently storing title, description, author, publication date, and thumbnail information, does it make sense to standardize those fields?
Or should a shared bookmark record remain intentionally minimal and leave enrichment entirely up to individual services?
I suspect there is a spectrum here:
- Bookmark as Reference
- A URL and a small amount of organizational metadata.
- Bookmark as Reading Object
- A URL plus workflow concepts such as status, notes, and organization.
- Bookmark as Snapshot
- A URL plus enough metadata to preserve context and portability over time.
My current lexicon draft probably sits somewhere between the first and third models.
Before I invest much more time in it, I’m curious how others think about these tradeoffs.
If you’re building a bookmarking service on ATProto:
- What fields do you consider essential?
- What should live in the record versus an application database?
- How much compatibility with existing community lexicons matters in practice?
- Should bookmark metadata be standardized?
I’m less interested in whether a particular field should be named one thing or another and more interested in how people think bookmark records should evolve within the broader ecosystem.
For reference, my current draft lexicon is here.
Depending on upcoming weekends I hope to have a beta site for people to try in a couple of weeks.
Have thoughts? Is there already an active discussion on this somewhere that I could participate in? You can reach me on Bluesky or by email.