Comments
Select a sentence in a note and say something about it. The remark lives beside the note rather than in it — the text you wrote stays exactly the text you wrote, and travels that way through the export, the API and anything else that reads it.
Saying something
Select some text and a small Comment control appears at the selection. What you picked is quoted above the box, so there is no doubt what the remark is about, and the box takes full Markdown like every other Markdown area here — the same formatting keys, the same paste, the same tables.
The comment is anchored to the words, not to a line number. Write a paragraph above it and the highlight moves with the sentence it was about.
When the sentence goes
If somebody edits the text away, the thread does not follow it somewhere else and it does not disappear. It is marked as orphaned, keeping what was said and naming the version of the note it was said about — which you can still read in the note's history.
That is deliberate. A comment that quietly moves to the wrong sentence is worse than one that admits its text has gone: the first is hard to notice, and the second is obvious.
Answering and closing
Anybody who can comment can reply to a thread, and anybody who can comment can resolve one — not only whoever started it. A count that only goes down when one particular person gets round to it is a count nobody reads. Resolving is not deleting: a resolved thread is dimmed and still there, and reopening it is the same button.
You can edit and delete your own comments. An administrator can delete anybody's, and cannot edit them — deleting takes something away and everybody can see that it is gone, while editing somebody else's comment would put words in their mouth under their name. A thread is yours to delete while it holds only your own words; once somebody else has replied, removing it is an administrator's to do.
Two numbers
The badge on a note carries two. The plain number is how many threads are still open — the same for everybody, and the measure of what this document owes an answer to. The coloured one is how many of those are new to you.
A thread becomes read when it has actually been in front of you for a moment, not when you opened the note and not when you opened the panel. That is the only version worth having: a mark that clears when you did not read is worse than no mark at all.
Mark unread keeps a thread in front of you regardless — you are looking at it when you press the button, so nothing automatic takes it back, a new reply included. Only Mark read undoes it.
Who can see them
Commenting is its own permission, between read and write. Somebody with Read and comment can join the conversation on a note and change no word of it — which is what you give somebody asked to review a draft. Share links have the same three levels, so a link can be for reading, for reviewing, or for editing.
Read-only sees no comments at all — not that there are none, but that there are none to see. That is what makes a reading link safe to hand to a client: they get the note, and not the discussion about it.
Programs, too
The API and the MCP server carry comments, which is what makes a review loop possible: a person leaves remarks, something else reads them, makes the changes that make sense and replies saying what it did. Replying never closes a thread — resolving is a separate, deliberate act, so whether a remark is finished stays the reader's decision.
A comment quotes the text as a reader saw it, so a note can be read either way: as the Markdown you typed, or as the words that Markdown produces. Reading a conversation through the API marks nothing as read — a program must not spend a notification meant for you.
What comments are not
They are never part of the note's text. A note's export carries none, on purpose: a file has no permissions, so a copy of the document with the internal review attached would hand a client the one thing the permission was keeping from them. A whole-workspace archive does carry them — that is a backup of everything, not a copy for somebody.