Sharing, comments and history

This page is about a page you do not have to yourself: who can open it, what people write on it, and what it remembers afterwards. The trash is here too, because deleting a page is the last thing sharing it can lead to.

There are four levels of access, and a level can reach you from five places. Almost everything below is those two sentences unfolded. The share dialog is built to answer the second question rather than the first — a list of names says nothing you can act on, while "this comes from the collection" tells you where to go and change it.

The four levels

The levels are a ladder: each one contains the ones below it.

The dialog says your own level back to you in a sentence rather than a word: You can edit this page and decide who else may.

The lowest level has two names. The share dialog calls it Can read; a collection's access list calls it Can view. It is one level; nothing behaves differently. The members screen names no levels at all — it hands out roles, which are a different thing.

One act is not on this ladder alone. Deleting something permanently needs full access to it and the workspace's own delete-for-good right, which only an owner or an admin holds — see The trash.

Where access comes from

Every row of the share dialog says where its access came from, and so does the line about your own:

When two grants disagree, the nearer one wins outright — even when it is weaker. A grant on this page beats one two pages up, whatever the two say. Only at the same distance does anything else decide: a grant to a person beats one to a group, and among what is left the strongest level wins. So a group grant of Can read written on this page really does override your personal Full access from further up, and the dialog says which is which so you can see it happen.

A page you may not read answers exactly as a page that never existed: This page is not available. That is deliberate — a different answer for the two would turn a link into a way of finding out what exists.

Collections

A collection is the top level of the tree, and its visibility is the widest lever in the product: it decides who reaches everything inside without being named.

Private means private, including from an owner. No workspace role grants an implicit read there. An owner who needs to get into a private collection gives themselves a grant, which everybody with access to that collection can then see — which is the point of doing it that way.

A closed collection you cannot open is still listed, by name. Its row in the sidebar says No access, with You can see this collection’s name, not what is inside it. underneath. That is a boundary being honest, not a sidebar that failed to load. A private collection is not listed at all.

Named grants are the second half. The ⋯ on a collection's row has two entries: Collection settings… (name, icon, description, visibility — and deleting) and People with access…, the same dialog opened at the question you actually had. A grant here looks exactly like a grant on a page and uses the same four levels. Reading the list needs full access to the collection, or the workspace right to manage members; changing anything in the settings needs full access to that collection and nothing else substitutes for it. Each entry is only shown where it would work, so a menu with one entry in it is a boundary rather than a fault.

Deleting a collection

A collection is deleted with everything in it, and nothing goes to the trash. It used to have to be emptied first, which at a few hundred pages was not a procedure but a dead end.

So the press is protected by knowing rather than by refusing. Collection settings… ends in a count of what is inside — It holds 412 pages and databases and 2 documents. — and deleting asks you to type the collection's name. The count is the whole point: a collection holds things this app does not list, and they are destroyed too.

The same block appears on Settings › Collections, because it is the same block: one irreversible action cannot be described two ways if there is only one of it.

Two things it will refuse, and both are worth knowing before you reach them:

• Content you cannot reach stops it. If the collection holds a restricted page you have no full access to, the delete says so and offers no button. No role crosses that boundary — not an admin's, not an owner's — so the way through is to be given access, or to have whoever holds it move that content out. An owner can always grant themselves access, and everybody with access to the thing sees that they did.
• It is not undoable in any sense. The trash is not involved, there is no restore, and a page that was already in the trash goes with the rest.

Two things the list will tell you rather than let you discover:

• On an open collection: An open collection is reachable for the whole workspace — an explicit list only adds to that, so it is usually empty.
• On the last full-access holder: A collection always keeps at least one person or group with full access. Grant somebody else full access first.

Roles

A workspace role is about administering the workspace, not about reading its content.

No role gives you content. An admin who was never named in a private collection holds nothing in it, and no amount of access to a page lets you manage groups. The two systems meet in exactly two places: the visibility table above, and permanent deletion.

A guest opening the app sees a sidebar that says Nothing has been shared with you yet. — not "No collections yet" with a create button beside it, which would be two false statements at once.

Sharing one page

Share… sits in the page's ⋯ menu and is offered only to somebody with full access. It has four parts, in this order: your own access, whether the page inherits, the people and groups it names, and publishing.

Only grants written on this page can be changed here. An inherited row is listed — you need to see it to understand your own access — with Change this where it was granted. beside it, and its controls disabled. Rows written here sort above the inherited ones for the same reason.

Give access searches people and groups in one list and grants Can edit to start with; change the level on the row afterwards. Somebody who already holds a row on this page is left out of the search: their level is changed above, not granted a second time.

Two refusals arrive as the rule they ran into rather than as an error:

• Only someone with full access can change sharing.
• A restricted page needs at least one person with full access. Give someone else full access first, or stop restricting the page.

Restricting a page

Do not inherit access from above cuts the page out of everything upstream. With it on: This page inherits nothing. Only the people and groups listed here can open it.

Two things about it are worth knowing before you tick it.

Turning it on takes access away from nobody who can already administer the page. Everybody holding full access at that moment is carried across into the new list — you are drawing a boundary, not starting from an empty room.

Turning it off again keeps every grant you wrote. Access from above will apply again. The grants listed here stay as they are.

A restriction boundary is respected everywhere access is worked out, not only in this dialog: a public link above the boundary stops at it, and duplicating a page copies only the part of the subtree you could actually read — a restricted subpage does not come along, because a copy in your own hands would be a copy nobody had to grant you.

Moving a page can change who reaches it

A page carries its access with it only as far as its own grants; everything it inherited it inherits from wherever it lands. So a move can hand the page to people who could not open it before, or take it from people who could.

The app does not leave you to work that out. Moving into a different collection shows what you are about to do — The page leaves “{name}”., then one sentence for what the destination's visibility means, which is a different sentence per visibility (Everyone in the workspace will be able to find and edit it in “{name}”. / Only the people with access to “{name}” will be able to open it. / Only the people named in “{name}” will even see that it exists.), and Every subpage below it moves along. Afterwards the dialog stays open with The move changed who has access, listing Now has access and No longer has access, or Nobody’s access changed.

Dragging a page in the sidebar never does this: a drag only reorders inside one collection. Changing the collection is a separate act, through Move…, because a gesture that quietly re-audiences a page is exactly the accident worth designing out. Taking a page out of a collection needs edit access to the collection itself, not only to the page — and the refusal says so.

Publishing to the web

Publish to the web, at the foot of the share dialog, hands the page to anyone holding a URL: Anyone with the link can read this page — no account needed. They cannot edit it, and they see no comments, no history and no member names.

• Full access publishes; a guest never does. Even a guest holding full access on a subtree that was handed to them is refused — Guests cannot publish pages to the web. — because turning a narrow, revocable grant into an unbounded one is not a thing the workspace agreed to.
• Child pages are opt-in. Include pages inside this one is off to begin with. Turned on, pages you create under this one later become public too — except any page with restricted access of its own, which stays private.
• Withdrawing is immediate. Unpublish deletes the link; the next request finds nothing. Create a new link does the same to the old one: The old link stops working immediately.
• The scope is worked out live, on every request. Move a page out of the published subtree and it stops being public at the moment it moves; move one in and it is public at the moment it lands; raise a restriction boundary in between and the next fetch already respects it. Nothing is precomputed, so there is no stale copy of the decision to catch up.
• A trashed page is not public. Anything in the trash resolves to no access at all, and that includes the anonymous reader.
• Published does not mean indexed. The pages are served with an instruction to search engines not to index or follow them, and with the browser told not to pass the link on in a referrer — the link is the credential, and one click on an outbound link would otherwise hand it to a stranger's server.
• Only somebody with full access can even see whether a page is published, and at what URL. The answer contains the credential, so reading it is priced the same as writing it.

Four different situations — an unknown link, a withdrawn one, one whose page has been trashed, and a page outside the shared set — all produce the same screen: This link is not available. Telling them apart would be free information for anyone probing.

What a public reader sees

A published page is not the page with the chrome taken off. It is a deliberately smaller thing, and everything left out says so where it was rather than leaving a hole — so a reader can tell that a page is complete as published rather than broken.

There is no breadcrumb (it would name pages nobody shared), no sidebar (it would name siblings), no workspace name and no author. What there is: the title, the prose, a Shared page · read-only badge, and — where child pages were included — Pages in here at the foot, with a way back to where the link started.

Comments

A comment lives in the panel beside the document; the switch is in the header bar and carries a dot — not a number — for as long as any discussion is still open. A bar button is too small to read a figure off, so the dot says “there is something here” and the panel is where you see what; a screen reader is given the count itself rather than a decoration. Comments and the activity feed share that one panel, so opening one closes the other.

A comment is anchored in one of three ways, and the card says which. On a passage: On “…”. On a whole block: On this block. On nothing in particular: On this document — and that last one is the ordinary case, not a fallback. Select nothing, write, and you have made a general remark.

A comment has to sit inside a single block of text. Select across two paragraphs, or select an embed, and the app says exactly that rather than anchoring something it cannot find again.

• A commented passage is highlighted whether or not the panel is open, and clicking the highlight opens the panel on that discussion. The highlight is the only thing that tells a reader a discussion exists at all.
• Resolving settles it. Resolve takes the thread out of the Open list and its highlight out of the text; Reopen brings both back. The panel's Open / Resolved switch is how you see the settled ones, and the switch does not change what is highlighted — a document repainted with finished conversations is worse than one painted with live ones.
• When the text underneath moves, the card says The text has changed since this comment was written. rather than quietly pointing somewhere else.
• When the text goes entirely, the discussion does not. It moves into No longer in the text: “The text these comments were written on has been deleted. They are kept here with what they quoted.”
• You edit your own comments; deleting anybody's needs edit access to the page. A comment that has been changed says edited beside its time.
• Deleting the last comment takes the discussion with it, and the confirmation says so: Delete the whole discussion, and its highlight in the text?
• A comment written offline is not lost. Not sent — this device is offline. Your text is still here; try again once you are back. — and when the connection returns the line changes to Connected again — send your comment now., because a refusal that outlives its own truth is worse than none.

Somebody who can read but not comment sees every discussion and gets You can read this page, but not comment on it. where the box would be. A page in the trash has no comments at all.

Mentions and the inbox

Type @ in a page and pick a colleague: the picker offers pages and people together, and picking a person inserts a mention. The mention lands in that person's inbox for this workspace, reachable from the sidebar; the badge appears only when something is waiting.

Four things about mentions are not what people assume, and all four are worth knowing:

• Only a mention in the page's text notifies. A comment is a plain box of text with no picker behind any key: an @ typed there is the character @, and nobody's inbox hears about it.
• The notification names no sender. It reads You were mentioned in {title}, never “Ana mentioned you”. The only thing that observes a mention appearing in a page is the projection behind the document, which carries no session — and attributing a notification to the wrong colleague is worse than attributing it to nobody.
• A person is mentioned once per place. Delete the mention and type it again in the same block, or edit the paragraph around it, and no second row appears.
• A mention of somebody who is not a member of this workspace delivers nothing.

The inbox has Unread / All, Mark as read, Mark all as read and Clear. Clearing is permanent for that row: it is how a notification leaves for good, and it is also what stops the same mention being delivered again later.

Both the list and the badge count only what you can still open. Lose access to a page and its rows leave your inbox — not by a cleanup that has to be remembered, but because the check runs when the list is read.

Activity

The second panel in the header bar is what happened to this page: Created, Edited, Renamed, Moved, Moved to trash, Restored from trash. Repeated edits collapse into a single line with the count beside it: Edited, then 12 times.

Some entries name a person and some do not, and that is a distinction rather than a gap. A rename or a move happens inside a request, which knows who made it: {name} renamed this. A body edit is noticed by the projection behind the document, which does not: Edited. "Someone edited this" would read as a defect where Edited reads as a fact.

Activity is per page. There is no workspace-wide feed, and the inbox's second tab shows the activity of whatever page you have open — Open a page to see what changed on it. when there is none.

Version history

Version history is in the page's ⋯ menu, and the muted Updated … · by … line under the title is a button that opens the same dialog. Reading it needs nothing beyond read access; restoring needs edit access, and says so where the button would be.

Versions are written per editing session, not per keystroke. A page is captured when it has been quiet for two minutes, and at least once every half hour of unbroken editing — otherwise a long afternoon would leave exactly one recoverable point, its end. Two captures with identical text are stored once, so “five versions” always means five distinct states.

A version is labelled with why it exists: Autosave, Saved version, Before restore, Restored. Save version takes an optional name (e.g. Before the rewrite), and a named version is never written off as a duplicate — it records that you decided something, not merely what the text was.

Selecting one previews it, under an honest label: Shown as canonical Markdown — the same text the page exports. It is the text, not a rendering of the page.

Download as Markdown saves the version you are looking at as a file. It is the bytes on screen, so the file cannot disagree with the preview, and it needs only read access — taking a copy away is reading. The file is named for the page, the version and the moment it was captured, so several versions of one page never land on one name.

Restoring is itself undoable, and it deletes nothing. The confirmation states the whole mechanism: “The page body is replaced with this version's content. The current body is saved as a version first, so you can undo this by restoring ‘Before restore’. Newer versions are kept. Anyone editing the page right now sees the change immediately.” Blocks keep their identity across the restore, so comments and references anchored to blocks that still exist stay attached.

A restore puts back the body and only the body. The title, the icon and the page's property values are not part of a version and are not touched by restoring one.

Delete version removes one entry for good and changes the page not at all.

How long a version is kept

Three statements, and there is no fourth:

1. Automatic versions thin as they age: the last 20 are kept, then one per day. This happens on every plan and has no end date.
2. Versions you save yourself are never thinned. They stay until you delete them.
3. Deletion by age happens on the free plan only — everything older than 30 days, saved versions included. Every paid plan keeps version history with no time limit.

The sentence in the app said something narrower for a while: a flat 30-day cut, applied on every plan, while the pricing said otherwise. All three statements above are now what the server actually does.

The trash

Trash sits at the foot of the sidebar. Move to trash in the page menu puts a page there with everything below it; the page stays readable, marked This page is in the trash. / It is read-only until you restore it., with a Restore button on it. Its comments, its activity and its version history are not reachable while it is there — anything in the trash resolves to no access at all, which is also why a public link to it stops working.

A row in the trash carries four things: an icon and a name, a badge saying what it is, the collection it came from, and when it went — deleted …, counted from now. Without that last one, two pages called “Notes” are the same row twice.

The badge is there because the trash is not only yours. Page and Database are what you make here. You may also meet a Document or a Board: a workspace holds those when it is switched on in another of our apps, a colleague working there trashes them into this same bin, and the badge means an entry you did not create still says what it is. Restoring and deleting work on them from here too, so nothing is ever stuck.

Restoring needs edit access to where the page would go back to, not to the page — the container decides, which is also why a page cannot be restored into a subtree that is itself in the trash.

Deleting permanently is the one act with no way back, and it needs full access to the entry and the workspace's delete-for-good right, which only an owner or an admin holds. The page menu does not offer it to anybody else at all; the trash row does offer it and the refusal comes from the server. What it takes with it is more than the entry, and the confirmation lists all of it: the page and every subpage, any database living on those pages — with all of its rows, its columns, and every view of it anywhere in this workspace — and anything that also sits elsewhere in your account, which is deleted there as well.

Empty trash empties the whole trash, not the rows on screen. The confirmation counts the entries so you can see the difference — and where that number is not known yet it says every entry, not only the ones listed here rather than naming a figure it cannot stand behind. It removes only what you are allowed to remove, and afterwards says what it actually removed, counting pages, databases and views separately: Permanently deleted: …

One consequence catches people out: a collection cannot be deleted while anything is still in it, and the trash counts. The refusal says so — “This collection still holds content — including items in the trash, and content created in another app.”

What sharing and history cannot do yet

• No password on a public link, and no expiry any screen offers. In the app a link lasts until you unpublish it or replace it with a new one, so a time-boxed link is one you have to remember to withdraw. The API is the exception: publishing through it takes an expiry date, and the server refuses the link the moment that date passes. There is no password anywhere.
• No “anyone at this company can read this”. Access is a person, a group, a collection's visibility, or the whole internet — there is nothing in between the workspace and the public.
• No per-block permissions. The smallest thing you can share, restrict or publish is a page.
• A discussion is one flat list. You reply into a thread; you cannot reply to a reply.
• A comment is plain text. No bold, no links, no @-mentions — the box is a box, and what it says is what you typed.
• You cannot comment on an image, on a table cell, or across two blocks. A comment has to sit inside a single block of text — the app says so instead of anchoring something it would lose.
• Nothing about a page is emailed. A mention appears in the inbox and nowhere else — no notification mail, no daily digest. The product's email is for invitations, account matters and invoices.
• Activity is per page. There is no workspace-wide feed of what changed, and no record of who read something.
• The trash never empties itself. There is no retention period and no reminder; a page stays there until somebody restores it or deletes it.
• A version restores the body, not the page. Renaming a page, changing its icon or clearing a property value is not something version history can put back.
• A public page cannot be styled, branded or given a custom address. It is served from the same origin as the app, at a link nobody can pick.

For reaching any of this from a script — grants, public links, comments, versions — see the API.