Privacy

If you are an author, the operator of Inkwharf decides how your account data is used, and is the controller of it. Everything in sections 2 and 3 applies to you.

If you are a reader who bought a book, your details were collected for the author you bought from. They decide what happens with them; we process that data on their instructions and for no purpose of our own. In data protection terms the author is the controller and we are their processor.

The practical consequence, and it is a promise rather than a technicality: we do not market to an author’s buyers. Not a product announcement, not a survey, not a “we noticed you bought”. The only email we send a buyer is the one that delivers what they paid for, or one they asked for themselves.

Your name and email address, a password stored only as a scrypt hash, your chosen language, and the pen name, biography and shop settings you enter. We keep this to run your account, and because a contract with you requires it.

Payment credentials you connect — a Stripe restricted key, a Blockonomics API key, webhook signing secrets — are encrypted at rest with a key held outside the database. We never store an unrestricted Stripe key; the studio refuses one.

Your books, covers and the metadata you enter about them, so they can be sold and delivered.

Records of your sales — amounts, dates, buyer country — which are also what you need to account for your own tax.

An email address, and a name if one was given, because a delivery link has to be sent somewhere. Buying does not create an account.

What was bought, when, for how much, and on which rail. The buyer’s country where a card payment reported one, because where a digital sale is taxed depends entirely on where the buyer was.

A delivery token, which is what a download link is. If a buyer sends a book to an e-reader, the address they sent it to, so the form can remember it.

Where an author has watermarking enabled, each delivered copy carries a licence code derived from the purchase, so a leaked file can be traced to the sale it came from. The author chooses this per book.

We keep this for as long as the author’s account is open, because a download link that dies turns a bought book into a support request. A buyer who wants their record deleted should ask the author they bought from; we will act on that request when the author passes it to us, and directly if the author is unreachable.

One cookie: a signed session cookie, set when you sign in. It is strictly necessary, so it needs no consent banner. Buying a book sets no cookie at all.

We record events about how authors use the studio — signing up, connecting a payment account — so we can see where the product is confusing. These are tied to an author account, never to a reader.

Page views on our own pages — the landing page, pricing, the studio, this one — are counted by Vercel Analytics, which is cookieless and does not build a profile of a visitor.

It does not run on an author’s storefront. A reader browsing a shop, reading a sample or downloading a book is not measured by us at all. That is the promise in section 1 applied to the one place it is easiest to quietly break, and the cost of keeping it is that we have no idea how much traffic any shop gets.

We do not use tracking pixels in email, and we do not measure whether a message was opened.

Running the service means other companies process data on our behalf. Each is used for one job:

• Vercel — hosting and request logs, which include IP addresses.
• Supabase — the database, and the private bucket holding book files.
• Stripe — card payments. On a book sale the charge is made on the author’s Stripe account, so Stripe is the author’s processor there, not ours. Our own Stripe account sees only author subscriptions.
• Blockonomics — bitcoin addresses and payment notifications, against the author’s own merchant account where they have connected one.
• Our email provider — delivering the messages described above. Whichever SMTP service is configured for this deployment.
• PostHog — the author-side product events and error reports in section 4.

Some of these operate outside the UK and EEA. Transfers rely on the safeguards in each provider’s own terms, usually standard contractual clauses.

We do not sell personal data. There is no arrangement under which we could.

Passwords are hashed, never stored or recoverable in plain text. Payment credentials are encrypted at rest. Book files sit in a private bucket and are reachable only through a link that checks entitlement first and then issues a short-lived signed URL.

A download link is a bearer token: anyone holding it can reach the files on that order. It is not a login and grants nothing on any account. Buyers can rotate theirs at any time from the recovery page.

If you are in the UK or EEA you can ask for a copy of your data, ask for it to be corrected or deleted, object to how it is used, or ask for it in a portable form. Authors can export their own data from the studio without asking us.

You can also complain to your local supervisory authority. We would rather you told us first.

A contact address has not yet been published — see the draft notice above.