Your data in Revisenda

Who can read your manuscripts

Only the people invited to that project. Access comes from an invitation, never from having an account and never from guessing a link — every invitation is single-use and bound to one email address. Someone who registers with an address you once mentioned gets nothing.

The workspace administrator has no special access to project content. Admin pages never show manuscript text, threads, comments or decisions. What they do show: project titles, who ran which AI feature, token counts and dates; adoption counts and compile timings; server error messages with the route that failed (never the request body); and, if you asked for an invitation through the public page, the name, address and note you submitted there.

What the operator can technically access

Being straightforward about this matters more than sounding reassuring. This workspace is operated by LunarAI LLC and runs on a server rented from Fly.io in the United States (New Jersey region). Whoever administers that server can read the database directly, which includes manuscript text. That is true of every hosted research tool, including Overleaf; application permissions cannot prevent it, and only end-to-end encryption could — which is incompatible with server-side LaTeX compiling and AI assistance.

What can be promised is conduct: project content is not read without the project owner's explicit request — for example, when you ask for help with a compile failure or a lost file. There is no routine monitoring of manuscripts, and no analysis of your research for any purpose beyond running the features you use.

If your work requires that no third party can access it at all,Revisenda can be self-hosted on your own institution's server. Ask us at lei.li@lunarai.llc.

What happens with AI

AI features send the relevant part of your manuscript — the file being compiled, a thread and its context, a reviewer comment — to the configured model provider so it can answer. Each project controls this in Settings → AI:

• Off — nothing is sent anywhere. With AI off, the paper still remembers everything and still briefs you; it just won't write anything for you. Catch Up, the reviewer tracker and compile help run from the record with built-in helpers on this server; Ask the paper and AI drafts are unavailable.
• Workspace model — requests go to the workspace's configured provider using the workspace key. At the time of writing that provider is OpenAI (US-hosted API); if it changes, this line changes with it.
• Bring your own key — requests go to your provider on your own account, so your lab's text never touches a shared key.

Providers process that text under their own API terms; if this matters for your work — embargoed results, an NDA, an IRB condition — check those terms, or use Off or your own key. What this workspace records about each AI call is only metadata: the feature, model, token counts, cost and duration. Prompts and responses are not stored.

What is stored, and where

Manuscript versions, threads, comments, decisions, tasks, uploaded figures and compiled PDFs live in a single database and file store on this server's disk. Passwords are stored only as bcrypt hashes — they cannot be read back, by anyone. Invitation, password reset and verification links are stored only as hashes too, so a stolen database copy cannot be used to claim access.

Backups are taken automatically and kept for a limited window so the workspace can recover from a failure or a mistaken deletion. Backups contain the same content as the live database.

Where the backups go. A copy of the database is replicated continuously to off-site object storage at rc-lei-backup, hosted by fly.storage.tigris.dev, so that losing this server's disk does not lose your work. That copy contains everything the live database does, manuscript text included, and it travels encrypted. Two things are not readable in it even by the operator: passwords, which are only ever bcrypt hashes, and saved AI keys, which are encrypted with a key held outside the database and therefore outside the backup.

Other services that see some of your data

Every email Revisenda sends — invitations, confirmation links, digests — goes out through Resend, which therefore sees recipients' addresses and the email text. The sign-up form uses Cloudflare Turnstile to keep bots out; it sees the browser signals needed for that check and nothing you type. When billing starts, payments will be handled by Stripe, which will hold card details — this server never does.

Cookies. A session cookie keeps you signed in for 30 days, or until you sign out. If you sign in through Google, Microsoft or ORCID, that round trip also sets a short-lived cookie so the reply coming back can be checked as genuinely yours; it is read once and deleted. Signing up with ORCID for the first time sets one more, and this one is worth describing exactly: ORCID confirms who you are but usually will not tell us your email address, so while you type it on the next page your ORCID iD and name are held in a cookie in your browser, signed so it cannot be altered. It expires after 15 minutes and is consumed when you finish. Those are all the cookies there are. None is for analytics or advertising, and no advertising or third-party tracking script runs on this site at all.

What the app keeps in your browser. Three kinds of thing, all of them yours and none of them sent anywhere for analysis. Your preferences, so the workspace opens the way you left it: pane layout and widths, dark editor theme, font size, PDF zoom, spell-check language, Vi keybindings, auto-compile, which file you had open, and which one-off tips you have dismissed. A copy of the document you are editing, so a dropped connection costs you no keystrokes. And, while a tab stays open, the last thirty messages of your conversation with the assistant in that project, so switching files does not throw the thread away. That last one lives in per-tab storage: closing the tab discards it, and it is never sent anywhere as part of this. There is no button to clear it sooner — if you want one, say so and we will add it.

Counting visits. When someone opens the public home page or the sign-up form, we store one row recording which of those two pages it was, a single word for where the visit came from (“linkedin”, “direct”, the name of the site that linked here, or a short campaign label such as “email” that we put in a link ourselves), the time, and a random row id. Those are all the fields. No other page is counted — not sign in, not pricing, and nothing inside the app where your work is.

What is deliberately not in that row: your IP address, any browser or device fingerprint, any cookie or visitor identifier that would let two visits be recognised as the same person, your account if you have one, and the address of the page you came from beyond its bare domain — the path and anything after the “?” are discarded before storing. What that buys is specific and we would rather state it than overstate it: there is nothing in a row that lets two visits be recognised as the same person, and no row is linked to an account. It is not a claim that the data is anonymous in every sense a lawyer might mean — the rows do carry a timestamp, and a campaign label is text we chose, so we keep those labels generic (a channel or an institution, never a person's name). Nothing is sent to a third-party analytics service; there isn't one. Rows are deleted at thirteen months by a job that runs hourly whether or not anyone is visiting.

You can say no, and it is honoured before anything is sent rather than discarded afterwards. If your browser sends a Do Not Track or Global Privacy Control signal we act on it without your having to ask. Otherwise use the switch below — it is the one and only thing the counter ever writes to your device, and it exists solely to remember that you said no. Either way, signing in, editing and everything else work exactly as before.

Deleting things

A project owner can delete a project outright (Settings → Danger zone): every record, figure and cached PDF goes, and the database is compacted. You can delete your own account from Your account: projects only you belong to are deleted, and your name and email become an anonymised placeholder so shared history still reads sensibly for your collaborators. Deletions apply to the live data immediately; existing backups age out on their normal schedule.

One limit worth knowing in advance: if you own a project that other people are still members of, account deletion is refused rather than silently destroying their work. Delete those projects first (Settings → Danger zone), and deletion proceeds. The sample project's fictional co-authors don't count.

Questions

Write to lei.li@lunarai.llc. If something here doesn't match what the software actually does, that's a bug worth reporting — this page is meant to describe the system as built.