Bookmarking is a runtime capability, not a site plugin

Ask someone how a site should let you save an article, and the picture that shows up is usually: another account, another plugin, another third-party pocket. Site authors think the same way. Independent sites either skip bookmarking, or they ship yet another pile of user data.

My claim is narrower. Bookmarking and notes should not be rebuilt on every site. They belong in the computing environment. Default on. Invisible until you log in. A site that does not want them can turn them off, or bind them to buttons it already draws.

This piece is for people who ship a site, and for readers who will see Bookmark on a page. The details differ. The claim does not.

Arc is the layer the site runs on. After you log in, you have a private store of your own (a DID Space), tied to that login. Bookmarks go there. They do not go into this site's database.

What this actually is

Bookmark here means this page. Bookmark stores the URL and title. Select a span and you can attach a note. My saves opens your page on this site, with bookmarks and notes in one list.

It is not a comment. Comments are public. It is not an authoring-time note for an agent either. A bookmark is a private record for the reader.

You might say: that is just a browser bookmark. Browser bookmarks cut across sites and have nothing to do with this site's identity. These records are tied to the logged-in you. The space is yours. This site's My page only lists what this site wrote. A totally unrelated site will not show the same pocket. That is why this is not Pocket.

Why default on

A capability and a plugin disagree about the default. A plugin waits for every site to install it. A capability is there unless you say no.

Search already looks like this. Every Arc site gets built-in search. Nobody wires up a search product per site. Bookmarking takes the same cut: by default it can remember pages a logged-in reader has seen, unless this site says it does not want that.

Default on, because if this is opt-in, most sites will forget to opt in. Readers keep stuffing pages into someone else's pocket. The site goes read-only again.

Off until you log in

A bookmark has to write into your space after login. No login, no space, nowhere to write.

So for the author, the default is on. For a reader who has not logged in, it looks like nothing. No side bar. Save buttons on the page stay hidden. After login, the entry the site chose appears. The capability is on. The entry is not.

Anonymous readers are not pushed to sign up just to save a URL. They can keep reading. Once they log in, the site is allowed to remember.

A side bar, or buttons the page already has

Display is also a setting.

The default puts Bookmark and My saves at the side of the page. Selecting text can save a note. That fits docs and content sites: the reader can act on any page.

The other mode draws no side bar. The page puts its own Save, Annotate, or My saves controls on the toolbar, and the runtime binds them. That fits an app that already has a toolbar and does not want another floating chip.

Same implementation. Different product choice.

How a site declares it

If you are only reading: after login, Bookmark appears at the side. That saves this page. My saves is what you left on this site. Those entries stay hidden until you log in. That is on purpose.

If you ship the site, there is one place to declare this. Omit it and you get the default: on, side bar. Turn it off with save: false. If you do not want a side bar and you already have buttons, set save: { chrome: buttons } and mark a control with data-arc-save="bookmark". Omit the field and it is on. Our own content sites do not have to flip a switch.

The declaration is on the whole site, not on a single page. Either you want the capability or you do not.

Where the records live

Records go into your DID Space. This site's My page lists them. The data is yours. The list is on this site.

Turn save off and the built-in bookmark and note lists disappear. That is the clean part: you said you do not want the capability, so readers do not see an entry.

When you should turn it off

If the site almost never has a logged-in reader, and its job is public publishing: turn it off. A floating bar is meaningless to anonymous visitors, and it looks like debug chrome.

If you want a cross-site pocket, Pocket-style: this is not that. These records follow the logged-in you on this site. They do not become a web-wide reading list.

If you want public annotation or authoring-time markup: use comments, or in-page review. Do not treat a private note as a public thread.

What layer this moves down

In The web as a system capability there is a line: after publishing, a site should still be able to answer. Comments, reactions, subscriptions are answers. Bookmarking is a quieter one. The reader does not want to speak. They just want this page for themselves.

For an independent site, doing that used to mean another account system and another store. So most sites skip it, or they push both conversation and saving onto someone else's platform. Once the capability moves down, the site only declares whether it wants it. Identity and the write path are already in the runtime.

This is landing in Arc. A site declares it with save:. Track it at arc#6715. Field tables, HTML attributes, and action error codes: Bookmark and note (save capability). The internals will change. The declaration should not.

Bookmarking should not be rebuilt on every site. Default on. Treated as off until you log in. Shown when it is useful. Turned off when it is not. That is a capability, not a plugin.