Seed desktop can now show ordinary websites inside the app, behind an experimental setting (PR 1138). An agent can read and act on that page when the user allows it. This page asks the bigger question: should Seed become a browser, or should it stay a Hypermedia app that opens the web in the user's real browser?
The security side is covered in detail in Considerations of becoming a browser, and the work it calls for is in Plan: a very secure browser in Seed.
What "browser" could mean
There are three very different levels, and most of the argument depends on which one we mean.
A web view for links. Clicking an http link inside a Seed document opens it in a pane inside Seed instead of jumping to Chrome or Safari. No address bar, no tabs, no bookmarks. This is roughly what the experiment does today.
A research browser. The web pane is a place to read, collect and import. The user can archive an article into a Seed draft, cite it, comment on it, and let their agent read it. Seed is the place where reading turns into writing.
A general browser. Tabs, history, bookmarks, password autofill, extensions, downloads, sign-in to everything. Seed replaces Chrome for daily use.
The case for
Links stop being exits. Today every web link in a Seed document sends the user away from Seed. A web view keeps the reading, the comment box and the agent in the same window.
Import gets much better. A page open in Seed can become a Seed draft with its source, author and capture time recorded. That is the start of a real citation and archive flow, and it fits what Hypermedia is for: permanent, attributed documents.
Agents can see what the user sees. "Summarize this page", "compare this with my notes", "draft a reply" all work better when the agent reads the rendered page instead of fetching the URL on a server that has none of the user's context.
Custom domains blur the line anyway. A Seed site on its own domain is a website. Opening it in Seed and recognizing it as Hypermedia is already half of a browser.
The case against
We would be shipping someone else's security. A browser is only as safe as its Chromium version. Seed desktop ships Chromium through Electron on our release schedule, which is slower than Chrome's. Every week we lag, users browse on a Chromium with known holes.
Browsers are a huge, crowded product. Tabs, sync, password managers, extensions, content blockers, accessibility, crash recovery, Safe Browsing. Users judge any browser against Chrome and Safari. We would lose that comparison for years.
Sign-in gets messy. Some big providers refuse or warn about sign-in inside embedded web views. Users would hit this on the first day.
Agents plus signed-in pages is a new kind of risk. A page can carry hidden instructions for the agent. The review of the first version showed how easy it is to get this wrong: any agent a user chatted with could read their signed-in sites (security task). Those holes are fixed, but the class of risk stays.
It pulls focus. Every hour on browser features is an hour not spent on documents, identity, permissions and agents, which are the things only Seed does.
Recommendation
Go to level 2 and stop there.
Keep the web pane as a reading and research surface, tied to Seed actions: archive, cite, comment, ask the agent. Every one of these is something Chrome cannot do with Hypermedia.
Do not build level 3. No password autofill, no extensions, no sync, no "make Seed your default browser". When the user wants to do general browsing, one click opens the page in their real browser.
Keep it off by default until the security work in Considerations of becoming a browser has shipped for a few releases and we have a Chromium update policy we trust.
Treat agent access as the main feature and the main risk. Browser access is off until the user allows a website, only for agents they own, and never for public agents. That rule should never be relaxed for convenience.
Open questions
Should web pages open in the same history as Seed pages, or in a separate pane beside the document that linked to them?
Should archived pages keep a full offline copy (HTML and images), or only the article text we import today?
Do we want the same reading pane on the web app, where the browser is already the user's own?
What Chromium lag are we willing to accept before we disable the web pane automatically?
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime