Terms & Privacy

• Campaigns and responses are stored on Sui Testnet, which is periodically reset by the Sui Foundation: they may be deleted without notice. Data persistence is not guaranteed until mainnet launch.
• The contract is upgradeable during the beta, and Logbook holds the key that upgrades it. A fresh deployment of the contract starts with an empty history in the interface: earlier campaigns stay on-chain but are no longer shown.
• Features may be incomplete, change significantly, or be removed.
• Nothing here costs real money. If you sign in with Google, Logbook pays the gas fees for you, within daily limits per account and per IP address. With a wallet you pay gas yourself with test SUI, which is free: use “Get test SUI” on the Account page.

• A campaign and every response are transactions on the blockchain. A response cannot be changed or deleted, and each account responds once.
• A campaign can be edited or deleted until its first response; after that it cannot be changed. Deleting a campaign does not erase the transactions that created and edited it.
• Do not publish anything you might want to take back.

• That an address responded, and when, is always public: it is visible in the campaign's Responses tab and to anyone who views the blockchain.
• Who can read the answers depends on the campaign's “Answers visible to” setting, which is shown before you respond. With Everyone, answers are stored in plaintext on-chain. With Everyone with access, Voters only, Only creator or After the end date, answers are encrypted in your browser before they are sent, and only the readers allowed by that setting can decrypt them. You can always read your own answer.
• One kind of campaign for the members of groups, created as a secret ballot, records a ballot that Logbook's relayer sends without the member's address: the record of such a ballot does not say which member cast it. A ballot you send yourself is recorded beside the address that sent it. It is a beta on a test network: a vote can be lost or never open, nobody outside Logbook has audited it, and it is not for a decision that binds anybody. It does not protect against being pressed to show your vote or being watched while voting; in a small group the result itself can show how people voted; that you voted can show from when ballots arrive (at a fixed time a ballot reaches the blockchain among at least five of its question group, of which four may be one party's, and in the last three minutes before the end it may travel alone and may not be recorded at all); the key servers a vote names, and you yourself, can open a ballot before the end; whoever can use your passkey can vote as you and find your past ballots, and the file of a ballot that the page offers when the relayer does not take it in time is a receipt as well; a device with malware, or a changed copy of the page, which Logbook and Cloudflare serve anew on every visit, reads what your passkey derives, and so can a browser extension that reads the page; the operators of the Sui node and of the indexer the page asks see which vote your network address reads, and when. And Logbook, or Cloudflare, which hosts it, could work out how a named member voted after the end, once the ballots are opened by whoever the vote lets open them: one service receives the ballot from your network address, pays for your other actions in the community, serves your encrypted list of communities and sees you sign in. We keep no table that says so, but for two days our sponsor's counters hold keyed hashes of your address in the community and of your network; the second relay run by somebody else, which would prevent it, does not exist yet. Read what it hides, and what it does not before you rely on it. Everything below in this section is about every other campaign.
• No setting is anonymous, and none is a secret ballot. A response is recorded under your address, and in every setting the readers see your answers next to that address. After the end date hides the answers only while the campaign runs: from its end on, everyone who can open the campaign (if it is open to anyone: anyone) can read them, for good.
• The keys are released by key servers that Logbook does not run (Seal) under the rule written in the contract. Who runs the three key servers this site uses: two are run by Mysten Labs, the company behind Sui, which also runs the full node this site reads and the service behind Google sign-in; the third is a committee of operators reached through an address of Mysten Labs. They are independent of Logbook, not of each other: any two of the three release a key, so Mysten Labs alone could read what they protect. That holds for member cards, applications and private campaigns as for secret ballots. Logbook's servers do not hold them, with one exception: for an app you connect through the remote MCP connector they hold the signing key of that session, encrypted, for at most 7 days, and decrypt what the app reads. Logbook does hold the one key that can upgrade the contract, and an upgrade could change that rule for everything already encrypted. It would be a public transaction; it is not yet prevented.
• A campaign that is not open to anyone keeps its title, description and questions encrypted as well: they can be read with its password, by the addresses on its list, and by its creator.
• Encrypted or not, what is on the blockchain is public data: anyone can copy it, and it stays there.

• Membership is public. For every group, a private one included, the blockchain shows the addresses of its members, when and how each joined and left, the addresses of its owner and admins, and the addresses of everyone who applied, also those not accepted. If the fact of belonging to a group is itself sensitive, do not use a group for it.
• A private group encrypts its name, description and card form: its owner, its own admins and its current members can read them. A public group shows them to everyone.
• A member card has two parts, both encrypted. The part for members can be read by you, the owner and admins of the group, and its current members; the part for admins by you and the owner and admins only. The text of an application, and the card sent with it, can be read by the applicant and the owner and admins of the group while it waits.
• A group that lets people in by a list keeps the admins' copy of that list (the names of the seats, the expected holders, their emails if an admin entered them, and the personal links not yet used) encrypted in Logbook's cache. Only the owner and the admins of the group can open it; Logbook's servers store the ciphertext and are not given the key (the remote MCP connector aside, as said under “Who can read what”).
• All of this is encrypted in the browser before it is sent. The keys are released by key servers that Logbook does not run (Seal; two of the three are run by Mysten Labs, as said under “Who can read what”) to an address the group's contract accepts at that moment. Someone who is removed is no longer served the keys; what they read before, they may have kept.
• Records of a group cannot be deleted. Leaving a group, or being removed, ends your membership and closes your card, so that nobody is served its keys any more; the record that you were a member, and the encrypted card, stay in the history of the blockchain. An application that was withdrawn or not accepted stays there too.
• Nobody's identity is checked. A card says what its owner wrote, and a seat on a list belongs to whoever opened its link first. The World ID check is not available. The email check, where it is switched on, confirms a mailbox and not a person.
• The email check is made by Logbook's check server, which the contract cannot verify: it trusts the server's signature. For a check you sign in with Google, and the server reads the email address of that sign-in (and whether your organisation manages the account); Google knows that the account signed in for the check. The server does not store the email address and writes it into no log line; for two days it keeps daily counters named by keyed fingerprints of the mailbox and of the Google account, and by the address the check is for. It computes a keyed fingerprint of it, different for every community, which is written on the blockchain next to your address, with the day the check ends (90 days later, rounded to the day). Nobody can turn the fingerprint back into the address, and nobody without the server's secret can test a guess; Logbook itself could. A private group that lets people in by its mail domain stores a similar fingerprint of the domain instead of its name.
• “A mailbox of the organisation” means only this: Google says the account is managed under an organisation (Google Workspace or Cloud Identity) and its address is at the domain the group names. Logbook does not check how that organisation showed Google that the domain is its own, cannot tell two mailboxes of one person from two people, and whoever runs an organisation's Google accounts can make more of them. Where a group lets people in by its mail domain and its community counts nothing, one mailbox can bring in more than one account.

Privacy in Groups lists everything the blockchain shows about a group. Members and admins read each other's names on member cards, so for them the address under a response has a name.

• With Google (zkLogin), your blockchain address is computed from your Google account. Logbook never sees your Google password, and your email is not stored on the blockchain (an email check stores a keyed fingerprint of it, see Groups).
• That address is the one you act under in every campaign outside communities (a campaign that is not for a group). In each community (a group and the groups inside it) you act under an address made for that community alone, which this site derives for your account; our servers could connect those addresses with each other. What remains true of these addresses: a Google account on a device that never opened its addresses before cannot always check that the record of them which Logbook’s store serves was made by the account, and then takes it as served. The page says so in a notice, on each page load until it is answered: “This device could not check that the stored record of your addresses was made by you. It has never opened them before, and with a Google account the signature made when they were created can no longer be checked. That means: whoever runs Logbook’s store could have given your account addresses they also hold the keys of, and could then act as you in your communities. Before you rely on them, compare your address in a community (the account menu on its page) with the one shown on a device you have used before. Until then, do not register a ballot key and do not sign a roll from this device: Logbook will not let you.” Until the person has compared and said so, this site refuses, from that device, to register a ballot key, to sign a roll as returning officer and to create a secret-ballot campaign, whoever its returning officer is; it does not refuse joining, a member card or a response under those addresses. A wallet user who signs one key-server session message for another site gives that site every one of their community addresses, for good; a key left in a browser by somebody who closed the page without signing out stays there until anybody signs in on that browser, or 30 days pass, and the keys derived from it can be read by scripts of the page, which is why this site loads none from anywhere else; and Logbook’s server sees when an account’s list is read or written, and its database keeps history for days. It is computed by the sign-in service of Mysten Labs (Enoki), which receives your Google sign-in token each time: Mysten can tell which Google account has which address, and Google knows that the account signed in to Logbook.
• With a wallet, your keys stay in the wallet: it asks you to approve every transaction and every message it signs.
• Signing out ends your web session in this browser. An AI agent you signed in separately keeps its own session until it expires or you end it; see Authentication.

On Sui Testnet: campaigns (their content, encrypted unless the campaign is open to anyone; who may take part and who may read the answers; the creator's address; the address list of address-list campaigns; the hashes of the documents a campaign is about), responses (the respondent's address, the answers in plaintext or encrypted, the time), and groups (see Groups above: who belongs to them and who runs them in the open, names of private groups, cards and applications encrypted).

On Walrus, with a copy in Logbook's cache: the documents a campaign is about, AI reports and results certificates. Their SHA-256 is recorded on-chain, and files of private campaigns are encrypted before they leave the creator's browser. Walrus storage is rented: during the beta, files are kept for at least 50 days after publishing, while the on-chain record stays. A file uploaded but never recorded on-chain is deleted from the cache after two days.

On Logbook's servers: no database of campaigns, responses or members. Two things are kept in Cloudflare D1 databases: for each account, its vault (the seed of its addresses in communities, sealed for the key servers under that account, and its encrypted list of those communities), without a time limit, until the account moves it to its own device on the Account page, which deletes the record from the store and leaves a mark that it was moved, with a fingerprint of the sealed seed (what Cloudflare can restore of the database stays for up to 30 days); and the queue of the relayer of secret ballots (each ballot handed to it, until it is recorded, with no network address in the row; the row holds the fixed time of the ballot’s batch, the start of a half hour, and whether the ballot came in the last half hour before the end of its vote, so the half hour of its arrival is in the row and the moment is not; and what the relayer paid per campaign and per day). Cloudflare can restore such a database to any minute of the last 30 days (7 on its free plan), so a deleted row, and the minute it first appeared, can be brought back until then. For two days the relayer also keeps a counter per network and day of what that network wasted (ballots whose proof does not verify, requests that are not a well-formed ballot), under a name made from the network address with a secret that changes daily; a network that wasted nothing has no counter. Besides these and that cache, the servers keep daily quota counters (they expire after two days: the gas sponsor's are named by a keyed hash, different every day, of the sender's address and of the network, which whoever holds the key could test a guess against; those for uploads, AI and sign-in are named by the address, the IP address or the id of the Google account itself, and by a hash of an API key; email checks are counted by address and IP address, and by a keyed fingerprint of the Google account and one of the mailbox, made for these counters alone, never by the email address itself), integrator API keys (hashed), and the sessions of apps connected through the remote MCP connector, with their signing keys encrypted. The cache also holds the two files of a group's list: the admins' encrypted copy, and a published form with one fingerprint per seat that anyone can download. Error reports from the app go to the hosting logs (Cloudflare), with web addresses cut to their path and with wallet addresses, emails and the ids of campaigns and groups taken out; the log line of a sponsored transaction holds a short code that stands for its sender for one day, not the address. Other lines of the server's log are different: one about a report upload that failed names the campaign, and several hold an error as the blockchain, the storage or a library worded it, unedited, which can hold an address or an id. For a transaction whose gas Logbook pays, the server sees the sender, the IP address and the transaction before it reaches the blockchain.

With others: Cloudflare hosts the site and sees every request with its IP address. The Seal key servers see which address asks for which key. The public Sui node and indexer of Mysten Labs, which your browser asks directly, see which IP address asks about which addresses and campaigns. What they keep is their policy.

With the AI provider: the AI features send data in plain text through Logbook's server to a third-party provider, DeepSeek (api.deepseek.com, a company in China), handled under that provider's terms: what you type to the campaign assistant, with the current form, and, when a creator runs AI Analytics, the campaign's texts and the answers the creator confirms, written answers included, without addresses. A creator can do this at any time for the answers they can read, also on a campaign with encrypted answers; the page says so before you respond.

In your browser: your Google sign-in (address, email, the session key and its proof), your preferences, the passwords of password campaigns you created or opened, and the campaign assistant's conversation; for the open tab only, campaign content keys, answers you are filling in while you sign in, and where to return after signing in. For groups: the draft that prefills your member card, which groups you acted in and which seats you took, and, for an admin, the invitation links made in this browser and an encrypted copy of a list. Signing out removes the sign-in, the stored passwords and keys, the assistant's conversation and what was kept for you about groups; an invitation link you did not copy elsewhere cannot be copied again after that.

Privacy: what is public, what is encrypted, what cannot be deleted is the one page to read before using Logbook for anything sensitive. The Data Storage and Beta Testing pages of the documentation go into more detail. Write to hello@logbook.zone, or find us on X and Telegram.