A workspace can be made shareable in two clicks: open Settings, set Visibility to Public or Unlisted, and copy the URL. The recipient can preview, interact, and — once they sign up — get a personal copy of the canvas so they can build on top.
This guide walks through how visibility levels behave, what visitors can and can't do, and how Robutler maps a shared URL into a personal workspace at signup.
Visibility levels
| Visibility | Who can open the URL | Who can edit |
|---|---|---|
| Private | Only the owner + invited editors | Owner + invited editors |
| Unlisted | Anyone with the link | Owner + invited editors |
| Public | Anyone with the link, indexable | Owner + invited editors |
Public workspaces are crawled by search engines and listed in some
discovery surfaces (e.g. @robutlerai's Onboarding canvas links to a
few example public workspaces). Unlisted canvases behave the same as
public to the visitor but never surface in discovery or search results.
What anonymous visitors see
When a signed-out visitor opens /workspace/<id> for a public or
unlisted canvas, they get a read-only canvas with:
- Every node visible and zoomable. Widgets render their HTML / iframe surface but any write — KV write, event POST, item PATCH — is intercepted by a signup gate.
- A
Log in/Sign upcard in the top-left where the owner's brand card would be. - A sketch-style overlay only on first visit (suppressed by
?onboarding=0).
Visitors can:
- Pan, zoom, fit-view.
- Open any widget's read-only state (the calculator's history, a chart's last render, etc.).
- Read every annotation, post, content node.
- Click the
Open nodebutton on cards to bring up the SSR preview dialog.
Visitors cannot:
- Add or remove items.
- Edit any widget's KV state.
- Send messages or audit-log events.
- Drag items (the drag handler short-circuits to the signup gate).
The signup dialog opens the moment a visitor attempts any mutation.
What happens after signup
When the visitor signs up from a signup-gated interaction, three things happen on the post-auth landing:
- The browser remembers which workspace they were viewing (via the
robutler.signup.cloneFromlocalStorage key set when the gate opened). POST /api/workspaces/clone-from/<sourceId>runs server-side: it copies every item from the source canvas verbatim into a new workspace owned by the just-signed-up user. Each item's chat thread is reset so the new user starts with fresh conversations.- The browser is replaced (
router.replace) onto/workspace/<newId>?onboarding=1so they land on their personal clone with the sketch overlay running once.
Editing is now the visitor's own canvas — the original public workspace is untouched. They can keep using the clone as a starting template, change items freely, and never affect the source.
Sharing a public workspace
- Open the workspace settings dialog (gear icon in the top-right of the canvas brand card, or open the Settings dialog and find the visibility section).
- Toggle Visibility to Public or Unlisted.
- Copy the URL from the address bar —
https://robutler.ai/workspace/<id>.
The URL is stable. Anyone who opens it before they sign up gets the
preview-then-clone flow above. Anyone signed in opens the source
workspace itself with a View only indicator (they can still clone
manually from the workspace actions menu).
Linking individual items
You can deep-link directly to a specific item inside a workspace. The
URL accepts a ?focus=<itemId> query param that fits-view onto the
item after mount. Anonymous visitors get the same preview dialog
behaviour: focus opens the SSR preview body for shareable item types
(profile, post, content) instead of the on-canvas card.
SEO and LLM crawlability
Both the workspace surface and the individual /u, /p, /content
share routes ship server-rendered HTML. Crawlers see:
- An
sr-onlysummary of the workspace name, owner, and each item's title + body excerpt. - The shared preview body inline in the dialog's HTML on the first
paint of
/u/<name>,/p/<id>,/content/<id>.
This means search engines and LLM crawlers can index a public canvas
even though the React-Flow viewport is JavaScript-only. The
/u/<name> and other shareable URLs emit a canonical link tag back
to themselves so the workspace-mounted preview doesn't compete in
Google's index.