A novel is written alone and finished in company. A co-author drafts alternate chapters, an editor marks up the second draft, three beta readers tell you where they got lost. Each of them needs something different from your story bible: the co-author needs to change it, the editor needs to read and comment, the beta readers need the manuscript and nothing else to break.
Co-writing a novel in Lokee comes down to two roles per vault, invitations sent from the vault itself, comments that tell you when they arrive, a quiet reading view for the people who only read, and a few safety nets that make handing your world to someone else much less frightening. The demo story The Ashen Circle is the book being shared.
Which vaults can be shared?
Lokee has two kinds of vault, and only one of them can be shared.
- A local vault lives as a folder of files on your computer, opened in the desktop app (Windows or macOS). It needs no account and no internet. It is yours alone.
- A cloud vault lives on Lokee's servers and opens when you sign in: in the browser, and depending on your plan in the desktop and Android apps too. On the web, cloud vaults are listed under Your vaults. Cloud vaults are the ones you can share.
A local vault can also be synced to the cloud on a paid plan (more on that below), which gives it a cloud copy you can share. How many people you can share with, and everything else that depends on the plan, lives on the pricing page; this guide describes what each role can do, not what each plan costs.
Two roles: Co-author and Reviewer
Every person you share a vault with has one role in that vault. A person can be a co-author on the series bible and a reviewer on the standalone.
Co-author can change everything: entities, relationships, the manuscript, maps, the event plan, settings. Use it for genuine co-writers and for an assistant who maintains the bible for you.
Reviewer is the role for editors, sensitivity readers and beta readers. In the app's own words: "You are a reviewer here: you can read, comment on the manuscript and export, but not change anything." That banner is what a reviewer sees on every page, so they are never surprised.
What a reviewer does not get, specifically:
- the manuscript is read-only, with no extraction tools;
- characters cannot be placed on maps, and nothing in the bible can be edited;
- Consistency Check, Restore Points, Deleted, Import and Import history are not in their sidebar;
- in comments, they can add threads and replies, and resolve, reopen and tag only threads they started. Nobody else's words can be changed or removed.
What a reviewer does get is underrated: the whole story bible, read-only, plus a reading view of the manuscript. An editor who can open the card for Lady Iseult Varnhold, see her history and the map of Duskhollow, writes far better margin notes than one working from a PDF.
How do I invite someone from the vault?
Invitations start in the vault you want to share. Only its owner can invite. In a cloud vault, open Settings, the Sharing & sync tab, and the Collaborators section (from Your vaults on the web, the vault's Settings link takes you straight there). Then:
- Type their email in the Email address field.
- Choose Co-author or Reviewer next to it.
- Press Invite.
The person appears in the list as "invited as Reviewer, not accepted yet", with Cancel invitation next to it. An invitation opens this one vault and nothing else, so a proofreader working on one book never sees your other projects.
The invitee gets an email naming you and the vault. The link opens a Vault invitation page that says who invited them and in which role, with Accept invitation and Decline. They must sign in with the address you invited (Lokee says so if they are signed in as someone else), or create a free account from the same page. Once accepted, a co-author lands in the vault and a reviewer lands in its reading view. An invitation that sits unanswered for a week expires; cancel it and send a new one.
Below the list, a line tells you how many people you share your vaults with out of the number your plan allows, with See plans next to it. Each person counts once, however many of your vaults they are in; at the limit, an invitation is refused with a message that says why.
Changing access later happens in the same section. The owner can change anyone's role from the list, Remove one person from just this vault, or add someone who is already in another of your vaults: Add someone from your other vaults…, pick Share as, then Share. You can promote a beta reader to co-author, or demote a co-author to reviewer before you take the book back for a solo pass, without touching anything else. Comments a removed person wrote stay in the manuscript.
Give beta readers a reading view
Beta readers do not want a writing tool. They want the book, a way to say "this lost me", and nothing to click by mistake. That is what Read is for: it is in the navigation of every cloud vault, on the web, desktop and Android, and it is where a reviewer arrives from Your vaults.
The reading view shows one chapter at a time in a clean column, with Chapters for the table of contents (a button on a phone, a side list on a wider screen) and "Chapter 3 of 24" so the reader knows where they are. ← Previous chapter and Next chapter → sit at the bottom.
Two things happen there besides reading:
- Comment on selection. Select a sentence, press Comment on selection, and the thread is anchored to those words, exactly as in the Writer. Comments opens the threads of the chapter.
- Mark as finished. At the end of a chapter the reader presses Mark as finished; it turns into "✓ Finished — tap to undo", in case they pressed it too early.
On your side, the owner and co-authors see "Finished by" and the readers' names in the reading view's chapter list, and a "Finished" chapter count next to each person in the Collaborators section. That one number answers the question every author asks a beta reader and nobody likes answering: how far have you got?
The reading view works on cloud vaults only.
Collect feedback as comments on the manuscript
Comments live in the Writer and the reading view, attached to chapters. They are for the manuscript; entities and maps do not take comments.
To comment on a passage in the Writer, select the text and use Comment in the editor toolbar. The comment panel opens with "Commenting on the selected text", and the thread is saved anchored to selection, so it stays with the words it is about. A comment typed straight into the Comments panel, with nothing selected, belongs to the whole chapter.
To read comments, open Views and choose Comments. The panel shows the threads of the chapter you have open. Filters across the top choose Open, Resolved or All, filter by tag (All tags), and in cloud vaults by who was mentioned (Anyone mentioned).
Inside a thread:
- Reply keeps the discussion in one place instead of a new comment per answer.
- + tag adds a tag. Tags are free text; agreeing on a few with your readers turns the panel into a triage tool. "pacing", "continuity", "dialogue" and "cut?" cover most of what beta readers say.
- Resolve closes a thread once you have dealt with it; Reopen brings it back.
- In cloud vaults, type @ to mention a member of the vault. In local vaults there is nobody to mention, and the comment box simply says "Add a comment or note…", which makes comments a decent place for notes to yourself.
Know when someone comments
In a shared cloud vault, a new comment or reply sends a notice to the vault's owner and to everyone already in that thread, the person who wrote it excepted. Mentioning someone with @ brings them into the thread too. The notice appears under the bell (Notifications) on the web and in the Android app, as "commented in", "replied in" or "mentioned you in" followed by the vault's name. Clicking it opens the chapter in the Writer with its comments.
You also get an email, but not one per comment: Lokee gathers what is new in a vault and sends at most one email per vault an hour, and a notice you have already read in the app is not emailed. The desktop app has no bell, so there the email is how comments reach you; comments written in the desktop app notify everyone else as usual.
To stop the emails, switch off Comment emails on the Account page, or use the link at the bottom of any of them. The notices in the app stay either way. The account help section lists the same switches.
A pattern that suits a round of beta readers: invite each as a Reviewer, ask them to read in Read and tag every comment, then filter by tag rather than by reader when revising. Five people flagging "pacing" in chapter seven is a different problem from one person flagging it five times.
Restore points and backups: undo for the whole vault
Collaboration multiplies the number of hands on your story, and restore points are the reason that is safe. A backup outside the app is the reason it stays safe.
Restore points inside the vault
A restore point is a snapshot of the vault you can roll back to without leaving it. Lokee saves one automatically before the operations most likely to go wrong. Restore Points in the sidebar lists them with their reason: Before extraction commit, Before entity merge, Before bulk edit, Before notes import, Before recording event effects, Before sync repair, Before merging synced history, and Manual save for the ones you take with Save restore point now.
Roll back to this never acts blindly. It first compares the point with the vault as it is and shows what Will be removed, Will be restored and Will be reverted, grouped as entities and chapters. If another device has synced to the vault since the point was taken, it warns you that rolling back may discard those changes.
How many points a vault keeps: in a local vault you choose, under Settings, the Backups tab ("Keep the last" 20 by default). A cloud vault keeps a number set by its owner's plan, and the oldest are pruned after each new save. Either way, save one by hand before handing the vault over, and again before accepting a large batch of a co-author's work. It costs a click.
A zip you can hold in your hand
- Export a zip. Export in the vault sidebar downloads the whole vault as a zip: entities, relationships, manuscript, notes, maps, the event plan and all of its history. A local vault exports from the desktop app; a cloud vault exports in the browser, where reviewers have the link too, so an editor can keep a copy of their own.
- Import a zip as a new vault. Import from zip in the desktop app creates a new local vault from an export. On the web, the button under Your vaults is called Start from a downloaded demo, but it takes any Lokee export and creates a new cloud vault from it. Importing never overwrites an existing vault; it always creates a new one, so a backup can never silently replace your working copy.
A zip export before every handover, kept with the date in its name, is the cheapest insurance a co-written book can have. The backup help section has the short version.
Sync: know what actually arrived
A local vault in the desktop app can be synced to the cloud: open Settings, Sharing & sync, and in the Sync section use Enable Cloud Sync and choose a Sync interval (Every minute, Every 5 min, Every 30 min or On demand). Vault sync needs a paid plan.
Once syncing, a small status line under the vault name tells you the truth about it:
- Synced: everything is up.
- Syncing… and a count of pending changes while it works; the ↑↓ button pushes pending changes now.
- Sync error or Sync paused when it could not finish.
- Synced, except: followed by what stayed behind, such as "2 maps". Those items stay queued, the vault is not marked as synced, and Retry sends them again.
That last state matters more than it looks. A "Synced" that hides a map still on your laptop is how co-authors end up working on different worlds, so Lokee tells you exactly what is missing.
When the same thing changed on both sides, Lokee asks rather than guesses: a conflict shows both versions side by side with Keep Local and Keep Cloud. If relationships cannot be matched between the computer and the cloud, Check relationships before syncing lists them with Keep and Drop for each, and a restore point is saved on both sides first. Nothing changes until you choose.
Two authors and an editor on The Ashen Circle, end to end
Here is how the pieces fit on the demo book, with two authors I will call the owner and the partner, an editor, and two beta readers.
Setup. The owner creates one cloud vault for the book and, before inviting anyone, settles the schema: Character, Location and Faction types, a Place field called Location, "Member Of" as a cluster relationship. Setting up a story bible that scales is the checklist for this, and doing it alone first avoids two people inventing a "Place" and a "Location" type in parallel. Then Save restore point now, and Export a zip named with the date.
Invites. In the vault's Collaborators section: the partner's email, Co-author, Invite; the editor's email, Reviewer, Invite.
The partner's week. The partner drafts chapters four to six and, on the map page, records Rowan's move to The Undercroft at the world point of the raid. On the owner's side the Writer shows the new chapters and the map shows the move, because it is one cloud vault and not two copies. Before the partner runs Extract whole book on the new chapters, a restore point is saved automatically (Before extraction commit); the owner reviews the committed entities afterwards by their AI Extracted banners, as Turning a draft into a story bible describes.
The editor's pass. The editor opens the vault from the email and lands in Read. In chapter three they select a paragraph, press Comment on selection, and write "She cannot know Rowan's name yet; see chapter two", tagged "continuity". The owner's bell lights up; the email with that comment and the next few arrives within the hour. Twelve more threads follow, each tagged, and chapters one to five are marked as finished. The editor cannot touch the text and can Export a zip to keep.
The beta readers. Once the draft is complete, the owner invites two readers as Reviewers. A week later the Collaborators section says one has finished 19 chapters and the other 6. The reading view's chapter list shows the second reader stopped after chapter six, which is also where the editor tagged "pacing" twice. That is the chapter to fix first.
The owner's revision. Views, Comments, filter by the tag "continuity": four threads. Each one is checked against the vault, not memory; the first turns out to be an error in the book, the second an error in the bible, where someone had overwritten Ophelia's knowledge instead of recording it as a change. Fix, Resolve, next. Then the consistency check, run before the vault goes back to the partner, so nobody inherits the other's contradictions.
The mistake. In week three the partner bulk-edits the Faction type and deletes it by accident with six entities inside. Restore Points, the automatic Before bulk edit point, Roll back to this: the confirmation lists six entities under Will be restored and two chapters under Will be reverted, which the partner had edited since. The partner copies those two chapters' text out first, rolls back, pastes it in. Fifteen minutes, no email chain.
Common mistakes
Sharing before the schema is settled. Two people inventing entity types in parallel is the fastest route to a messy bible. One person sets up types and fields; then invite.
Making the editor a co-author "so they can fix typos". They will fix more than typos, and nothing records what changed. Editors are reviewers; typos travel as comments anchored to the word.
Sending beta readers into the Writer. It works, but it is built for writing and full of panels a reader doesn't need. Point them at Read and ask them to press Mark as finished; you will learn more from where they stopped than from what they say.
Trusting "Synced" without reading the rest of the line. Synced, except: is the state to watch for. Press Retry before you close the laptop.
Rolling back without reading the preview, or keeping the only backup inside the app. A chapter under Will be reverted is someone's week; copy its text out first. And if the vault is the thing that goes wrong, a dated zip on a disk is what saves the book.
What Lokee doesn't do here
There is no track-changes or suggestion mode: a co-author's edit is the text now, and the way to propose without changing is a comment anchored to the selection. Comments exist on the manuscript only, not on entities, maps or the event plan, and only comments send notices; edits and finished chapters do not. The app does not merge two people's edits to the same chapter line by line; a sync conflict shows both versions and asks you to keep one. A reviewer cannot be given a middle role such as "may edit notes but not chapters"; it is co-author or reviewer, per vault. And there are no push notifications on phones: the bell and the email are the two channels. If you need finer control over who sees what, split the work across two vaults and invite each person with the role that fits. How Lokee helps with worldbuilding describes where collaboration sits among the other modules.
In five minutes
- One cloud vault for the book, owned by one of you. Both authors are Co-author.
- Agree on the schema first, then invite from the vault's Collaborators section.
- Editors and beta readers are Reviewers, with a short list of comment tags, and they read in Read.
- Check the finished chapters before you chase a beta reader, and let the comment emails tell you when feedback lands.
- Before each handover, save a restore point and run the consistency check.
- Keep a dated zip export outside the app at every milestone.
None of these steps is complicated. Together they mean that inviting a reader into your story never risks the story itself.