privacy policy

sol pbc · solpbc.org · last updated: October 6, 2026

the short version#

how to read this page#

the short version is a summary. the sections below carry the specifics, service by service: what each one handles, what we keep, who processes it, and how to see, export or delete it. this page is the one home for what sol pbc holds; the services terms are the one home for what each service they cover does, and for paying, canceling and refunds. where one needs the other's facts it points there rather than repeating them. if the short version and a section ever seem to disagree, the detailed section governs; tell us at support@solstone.app and we'll fix the summary. the covenants are the authority over all of it: this policy describes them in plain language, and if it ever conflicts with the articles of incorporation or the bylaws, they govern.

contents

who we are#

sol pbc is a Colorado public benefit corporation. our benefit purpose, as filed with the Colorado Secretary of State, is to advance digital self-determination by providing open-source, privacy-respecting tools and services that enable individuals to directly collect and gain insight from their personal data.

sol pbc has one director: jeremie miller, the founder. if control of sol pbc ever changes, two conditions attach, and they attach to different things. if our business continues in another entity, that entity must itself be a Colorado public benefit corporation, or be bound under its own governing law and documents to a substantially equivalent public benefit and to substantially equivalent balancing duties. and if your data, or a service built on it, moves to anyone in that transaction, they must assume covenants no less protective than Article 8. these constraints are in the articles of incorporation: they can't be amended without the founder's personal written consent, and after he stops serving the language can only get stronger. see the amendment lock below.

contact: contact us. for the hosted services specifically, support@solstone.app.

what sol pbc makes#

sol pbc develops two open source projects:

sol pbc also operates four optional hosted services. each is a convenience, never a requirement, and each has a way to do the same thing with sol pbc out of the path:

what we hold, and where it goes#

from local use of solstone and vit: almost nothing#

solstone and vit are open source software that runs on your hardware. sol pbc receives no data merely from your local use of these products: no telemetry, no analytics, no crash reports, no usage data. solstone works offline from sol pbc, except that it reaches updates.solstone.app to fetch its own runtimes, models and tools, and to check for newer versions. that leaves the same edge logs as visiting solpbc.org. (older versions fetch some of their tools from GitHub or the tools' own sites, which see your network address the way any website does.) vit reaches sol pbc only when you ask it to: its explore and inbox commands ask the index of public vit records that vit and AT Protocol describes. if you apply for or receive scout status, we receive the scout records described below; if you turn on a hosted service, whether you pay for it or receive it complimentary, we receive the records described in that service's section.

the source code is public. you can verify this yourself. what the phone and watch apps ask permission to reach on your own device is a separate question from what we receive.

from the solstone apps on your phone and watch: what they reach for, and where it goes#

these apps run on your own hardware, and nothing they take in comes to sol pbc on its own. they do ask your permission to reach parts of your device, though.

on android, the solstone app asks for your microphone, your camera, and your approximate location. each belongs to a source you turn on yourself, and what each one takes in goes into your journal: the microphone takes in audio while the audio source is on, the camera takes still photos while the camera source is on, and location notes roughly where you were, so a memory has a place attached to it. android's approximate location is neighborhood-scale, and the app never asks for precise GPS. the camera is also how you scan the pairing code when you first connect a journal. opening a pairing link (go.solstone.app) leaves the same edge logs as visiting solpbc.org; the pairing secret sits in the part of the link that never reaches a server.

on iphone and ipad, the app asks for your microphone, for the audio from the meetings and voice memos you start, and for your location, so a memory has a place attached to it. both go into your journal, both can keep running while the app is in the background if you allow that, and, unlike the android app, the app asks for precise location by default on iphone, and you can choose approximate when it asks, or change it later in settings.

the app can also take in your screen: you start it yourself from a control inside the app, which opens iphone's own screen-broadcast sheet, and you stop it there or from the red bar at the top of your screen, and while it is running, everything visible on screen goes into your journal, including whatever other apps are showing. the camera is used for one thing only: scanning your journal's pairing code. the app also asks to reach devices on your local network, which is how it connects straight to your journal when both are on the same wifi. you can share things into it from other apps as well, and those go into your journal too.

on apple watch, the app asks for your microphone and your location, only while something you started on the watch is running. both can keep running while the watch app is in the background, and what they take in waits on the watch until it can reach your iphone, and from there your journal.

all three also ask whether they may send you notifications; the notifications section says what that reaches.

you are asked the first time each one is needed, and every one of them can be turned off in your device's settings at any time. each source keeps working without the permissions it doesn't need, though turning off local network access on iphone means the app reaches your journal over the relay instead of directly, or not at all.

where it goes: into your journal. what these apps take in stays on the device until you connect a journal, and then travels to that journal on your own machine. it reaches sol pbc only through a hosted service you turn on, and each of those has its own section on this page: the relay carries it encrypted and cannot read it, the operated backup holds it as encrypted blocks we have no key to, solstone.me passes what an agent you connect reads from your journal through a relay that has no key to it, and confidential processing, if you turn it on, is the one where our own model reads what your journal sends it while it answers. on iphone, notifications from your journal, if you turn them on, pass through a hop sol pbc runs that can't read them. nothing from these apps reaches sol pbc on its own. we run no analytics inside them and collect nothing from them. we never sell, license, sublicense or lease what these apps take in, and we never profile you with it or use it for advertising: those are covenants in our articles of incorporation. we also do not train anything on it, which is a commitment we make and hold ourselves to, reinforced by those covenants rather than written as one of them.

from the solstone extension in your browser: what it reads, and where it goes#

the solstone extension works with the solstone app on your computer, and only together with it: what it takes in goes into your journal through the solstone app, and nothing it reads comes to sol pbc on its own.

what it reads. it arrives able to read no website's pages. when you open it, it looks at the address of the tab you're on so it can offer to add that site, and that stays in your browser. it reads a site only after you've agreed, on its welcome page, to what it takes in, and after you've added that site and your browser has asked you to allow it. on a site you add, whenever a tab on it is open, background tabs included, it takes in the page's text and rough layout, and reads it again as the page changes: the text you can see, the text you'd see by scrolling, some labels a page provides for screen readers and tooltips, and some text the page has but doesn't show you. with that it notes each page's address, without anything after a ? or #, its title, when it read the page, and the sites its links point to. on a mail or chat site you add, that includes your messages, and it can include words you've typed into a message there but haven't sent, and anything a site shows, even something you'd consider secret. it never takes pixels or raw HTML, never reads what you type into a form field such as a password box (what you type into a site's own editor, such as a message or a document, is part of the page's text, and it takes that in), never records clicks, scrolling or keystrokes, and never reads a site you didn't add, though it does read a site you added when another page embeds it. it doesn't run in private windows.

where it goes: into your journal, through the solstone app. nothing leaves your browser except to the solstone app on the same computer, over the connection your browser provides between an extension and an app. the extension itself connects to nothing on the internet; when it's out of date, it asks your browser to check its store for an update. the solstone app puts what it receives into your journal the same way as everything else it takes in, and if that way runs through private network, the relay carries it encrypted and can't read it. unless the solstone app is running, paired and taking in browser pages, the extension takes in no new pages. it reaches sol pbc only through a hosted service you turn on, as with everything else the solstone app takes in; confidential processing is the one where our own model reads what your journal sends it, while it answers. we run no analytics in the extension and collect nothing from it.

what stays in your browser, and how to clear it. the extension keeps a little in your browser's own storage: the sites you've added, your settings and your agreement, a random identifier for this browser profile, and anything it has read that the solstone app hasn't accepted yet, which goes to whichever journal the solstone app is paired with when it can, and stays until the solstone app takes it or turns it away for good, or you remove the extension. the identifier goes into your journal with each page, so your journal can tell your browsers apart, and nowhere else. once the solstone app has accepted a page, the app keeps it on your computer until your journal has it. if you pair the solstone app with a different journal, what it's still holding goes into that journal once you confirm it's the journal you meant, or choose to go on when the app can't tell. unpairing or pairing again doesn't delete it, and you can discard it yourself. pausing stops the extension reading; what's already taken in still goes into your journal. removing a site stops anything new from it; what's already taken in still goes into your journal, and stays there until you delete it. removing the extension removes what it kept in your browser.

Chrome Web Store Limited Use. the solstone extension's use and transfer of information it takes in from the sites you add complies with the Chrome Web Store User Data Policy, including the Limited Use requirements. sol pbc holds itself to more than that policy asks. the policy permits a developer to transfer user data as part of a merger, acquisition, or sale of assets after obtaining the user's explicit prior consent; our articles of incorporation do not let us rely on that permission. selling it is barred outright — under any circumstances, consent or no consent. no merger, acquisition, or asset sale may be used to route around these protections: if any customer data, product, or service involving it ever passed to a successor, that successor would have to assume obligations no less protective than Article 8, in its own governing documents or in a written instrument enforceable directly by us and by our shareholders and former shareholders, surviving the transaction. and where sol pbc or its business would carry on inside another entity, that entity would additionally have to be a Colorado public benefit corporation — or an entity required under its own governing law and governing documents to preserve a substantially equivalent public benefit and to manage itself to substantially equivalent balancing obligations. (Articles of Incorporation, Sections 8.3(a)(1), 8.3(c), and 8.5.)

from your sign-in at services.solstone.app#

the solstone app has no sign-in of its own. services.solstone.app, the services portal, is where you sign in, and only to turn hosted services on and off, see what we hold about you, manage billing, and ask us for help. your journal and your devices work without it. you sign in with your email (we send you a code from services@solstone.app) or with a passkey, a sign-in key your own device holds, so there is no password to make up or lose. the sign-in form runs Cloudflare's bot check in your browser, the same way the support form does, and we pass Cloudflare the network address you came from along with that check, so it can tell a person from a bot.

what we keep. the email addresses you've added (one is marked primary; that's the one we write to), the passkeys you've registered (the public half of each, a name, what kind of device made it, and when it was made and last used), and your sessions: the browser's identifying string (shown to you as a device label), the network address it connected from (held encrypted, shown to you shortened), and when it started and was last used. a session lasts up to two weeks unless you sign out sooner, and you can end any session from the services portal. a session you end, or that expires, is kept for 30 days after that, then deleted. a sign-in that never verifies an email is deleted after 30 days. we also hold a one-way fingerprint of the code we emailed you, with the address it went to, for up to a day, or, for an address you add and never verify, until that address is removed after 30 days; when your sign-in was created and last used; to stop abuse, a one-way keyed count of sign-in and services portal actions, per network address, per email address and per sign-in, for 48 hours; and, from a device-registration flow no app uses today, a one-way fingerprint of each credential it issued and when, kept until your sign-in is deleted. if we ever need to see your services as you see them, an operator can open a one-hour session on your sign-in; it shows in your session list like any other session, and you can end it there. when we look up a sign-in to answer you or to keep the services secure, the AI agent that helps us, on an outside provider's models as writing to us describes, sees what we look up, and our own working records of that may name your email. each hosted service you turn on adds the access records its section names.

all of it is Customer Data under our covenants (the Article 8 term, defined in what sol pbc will never do below): we use it only to run your sign-in, and we never sell it, profile you with it, or use it for advertising. you can see your emails, passkeys and sessions at services.solstone.app/transparency, and have all of it deleted, with your services, by closing your sign-in, as your rights describes. a passkey you remove is kept, marked removed, until your sign-in is deleted.

the request trace. every request the services portal's code answers, the notification hop for iphone included, and each scheduled job it runs, leaves a trace in our own storage, which deletes it after 90 days, apart from the older traces below. a trace says when the request or job ran and how it went, and it never holds a network address. most say nothing else. some carry more, alone or together: a one-way reference to your sign-in, to one of its records or to a journal; the service and details of the event, such as a renewal date or an error code from Stripe; or, when something fails unexpectedly, the error it raised, which can name one of your records. traces written through september 23, 2026 also record which page each request asked for; one of them names a support request by its number, and all of them are gone by december 23, 2026. the trace is Customer Data under our covenants: we use it only to operate and secure the services portal, and we never sell it, profile you with it, or use it for advertising. it isn't on the transparency page or in your download, and it outlasts a deletion of your sign-in, on the schedule above.

from private network (the relay): a record of your journal, connection metadata, never content#

what it is. a relay sol pbc runs so you can reach your own journal from your phone, or any of your devices, without running your own relay. it's a convenience, never a requirement: on your own network your devices connect directly, you can bring your own transport, or you can run the open-source relay yourself, and all three are private by the same construction.

blind by construction. your devices open an encrypted tunnel to each other and the relay passes the encrypted bytes between them. the encryption is end-to-end between your own devices. the relay holds no key to it and keeps no copy of what flows through. neither the relay nor sol pbc can read anything inside the tunnel. this isn't a setting you have to trust us to honor. it's how the relay is built.

what the relay keeps is a record of your journal. it no longer keeps a record of your devices. for each journal you connect to the relay we hold its identifier, the public key we check its pairings against and a fingerprint of that key, when it enrolled, the identifier of its current credential, when that credential was last rotated, whether that journal has been revoked, and whether its subscription is live. if a subscription is granted before the journal has enrolled, we hold that grant against the journal's identifier until it does, or until you delete it.

at services.solstone.app we also keep two access records for the relay: which journal you turned it on for and when you last turned it on, and the record the turn-on page leaves so your journal can collect its go-ahead (held encrypted, good for five minutes). both are kept until your sign-in is deleted, and both are Customer Data under our covenants.

pairing a phone or any other device issues that device a credential, and the device is what holds it. the relay checks that credential each time and keeps nothing about the device that presented it, so the relay has no list of your devices to keep, hand over, or lose. this is a change: until september 2026 the relay did keep a per-device record, and it no longer does; the records that had accumulated were dropped along with the table that held them. the credential a device holds expires on its own and can be renewed; whether a session actually runs is a separate check against your subscription.

connection metadata. to move your bytes, the relay and Cloudflare (whose network the relay runs on) necessarily handle connection metadata about your devices: their network (IP) addresses, connection timing, and how much data moved. the relay keeps no connection log of its own. this is metadata Cloudflare's network handles in order to route your traffic, and what Cloudflare retains of it is described in the Cloudflare privacy policy.

the relay's record of your journal and the connection metadata are both Customer Data under our covenants: we use them only to operate and secure the relay, and we never sell them, profile you with them, or use them for advertising. they can reveal that a device connected, never what it said.

who processes it. Cloudflare (the network the relay runs on, and the database that holds the relay's record of your journal) and Stripe (payments). both are named below and see only what's described here, never your content.

when you stop paying. the relay stops at the end of the period you've paid for, and nothing of yours is lost. the services terms say exactly what happens.

how to see, export and delete. your sign-in data is at services.solstone.app/transparency, and your subscription is on this service's page there. closing your sign-in, as your rights describes, deletes the relay's record of your journal and any pending subscription grant at the relay with it. while that deletion runs, the relay also holds a short-lived hashed record of the request itself, so a retry cannot run twice; it carries no readable identifier and deletes itself within a week. canceling your subscription stops the relay and never touches your journal.

if we're compelled. if someone served sol pbc a subpoena over the relay, what we could produce is your sign-in and billing record, the two access records above, the relay's record of your journal described above, and the request trace described in your sign-in. connection metadata is a separate matter: the relay keeps no log of it, so what a demand could reach is only whatever Cloudflare's network still retains. never a list of the devices you paired, because we no longer keep one. never the contents, because there is no key and no plaintext to give. we resist such demands to the maximum the law allows and notify you when we legally can.

from the operated tier of encrypted backup: encrypted blocks and storage metadata, never content#

what it is. storage sol pbc runs so an encrypted copy of your journal can live somewhere other than your own machine, without you having to set up and manage your own bucket. it's a convenience, never a requirement: the bring-your-own path, pointing encrypted backup at your own object-storage bucket (Backblaze B2, Amazon S3, Cloudflare R2, any S3-compatible provider), is always available and uses the same code, the same encryption, and the same recovery model.

encrypted by construction. before anything leaves your device, solstone encrypts the contents, the file names, and the folder structure, so all of it becomes unreadable ciphertext, and those encrypted blocks then land in storage sol pbc runs for you. sol pbc stores the blocks and cannot read them: we hold no key, no password, and no way to decrypt them. a backup is restored only with your recovery key, which we never have. nothing readable from your journal reaches this storage or our storage provider.

what we keep. to operate the storage, we keep a small amount of operational information about your stored blocks: how many encrypted objects there are, how much space they take, and when they last changed. we also keep a log of each time your journal was issued a storage credential, or refused one, and when, and a record of each cleanup we ran on your stored blocks; neither says anything about your content. at services.solstone.app we also keep which journal you turned it on for, when you last turned it on, a fingerprint of its current credential and, if it lapsed, when, the record the turn-on page leaves so your journal can collect its credential (held encrypted, good for five minutes), and, for a week, a fingerprint of each credential we retired; all of it is kept until your sign-in is deleted, or sooner where a week is named. to move your encrypted blocks, the storage (running on Cloudflare, in Cloudflare R2) and Cloudflare itself necessarily handle connection metadata about your device's upload sessions: its network (IP) address, connection timing, and how much data moved. all of it is Customer Data under our covenants: we use it only to operate and secure the storage, we never sell it, profile you with it, or use it for advertising, and none of it includes the contents of your journal.

who processes it. Cloudflare (Cloudflare R2, the storage the encrypted blocks land in) and Stripe (payments). Cloudflare sees only those encrypted blocks, that operational information, and this connection metadata, never your content; its handling of the data it sees is described in the Cloudflare privacy policy.

what happens to your backup after you stop paying. when your subscription lapses, whether you cancel or a renewal fails, we keep your encrypted blocks for 30 days after the period you paid for ends, then permanently delete them. because the backup is encrypted with a key only you hold, once it's deleted we cannot recover it. this only ever affects the copy in our storage; your journal on your own devices, and any backup in your own bucket, are never touched. the services terms set out the full sequence, including re-subscribing within the 30 days.

how to see, export and delete. your backup is under your control: you restore it with your recovery key, and you can delete it from the backup screen in your journal at any time. your sign-in data is at services.solstone.app/transparency, and your subscription is on this service's page there. closing your sign-in, as your rights describes, deletes the operated copy as part of it, with no 30-day window, and deletes the credential log and cleanup records with it. deleting the operated copy never touches your journal on your own devices.

if we're compelled. if someone served sol pbc a subpoena over the operated backup, the only things we could produce are your sign-in and billing record, encrypted blocks we can't read, that operational information, the access records, credential log and cleanup records above, the connection metadata of your upload sessions, and the request trace described in your sign-in. never the contents, because there is no key and no plaintext to give. we resist such demands to the maximum the law allows and notify you when we legally can.

from confidential processing: what you send the model, retained by nobody#

confidential processing is off until you turn it on, and turning it off sends new work back to your own machine. what follows describes what happens while it is on.

what it is. an AI model sol pbc runs on confidential GPU hardware, so your journal can think with more capacity than your own machine has. it's a convenience, never a requirement: the other paths are always available, and on them sol pbc is not in the path at all. you can run a model locally on your own hardware, or bring your own provider key or your own endpoint.

what leaves your device. the text and images your journal needs a model to work through, and, if the audio switch is on, your audio for transcription. that switch is on by default while confidential processing is in use, and it is yours to change: turn it off and speech becomes text on your own device instead, once any transcription already under way finishes. your journal itself never leaves.

sol pbc runs the model. the model is ours: our own weights and our own serving stack, on confidential GPU hardware sol pbc operates. no third-party AI provider is in the path and nothing you send is handed to one. this is protected differently from our other services. the relay, the operated backup and solstone.me are each closed to us by a key we never hold, in the ways their own sections describe. this one is protected by the build that booted the confidential container: before your journal sends anything, it verifies the published build, checking the hardware's own attestation and a fingerprint of the exact image, pinned in solstone's open source code. if either fails, it sends nothing.

our own model reads what you send, in the clear, while it answers you, from inside the confidential container. the relay and the operated backup never do that, and this is not the same arrangement. what the check establishes is that the build doing the reading is the published one, and that it was accepted before your content was sent.

what we commit to is what becomes of it: the service keeps nothing. no content is kept, not even in logs. no human reviews it. nothing is used to train anything. that is a commitment we make, not something the attestation proves on its own. the image that implements it is published and auditable by anybody, and your journal checks that the published image is the one running. together, those are what make the commitment verifiable.

the hardware is Microsoft Azure's, and Azure is excluded from what runs on it. the machine is a confidential GPU instance in Microsoft Azure: an AMD SEV-SNP confidential virtual machine with an NVIDIA H100 running in confidential-compute mode. that boundary is enforced by the hardware, not by configuration or by promise, and it keeps the host out of what is being processed, memory included. Microsoft hosts the machine. it is not a party to your content.

your journal checks the hardware itself, every time, before sending anything. before a channel is used, your journal cryptographically verifies the machine: the AMD attestation chain up to AMD's own signing keys, the GPU's own evidence, the binding of that evidence to the encrypted connection, and a fingerprint of exactly which software booted on that machine. that fingerprint is pinned in solstone's open source code, so it is public, version-controlled, and cannot be quietly repointed at different software without a release anyone can see. the check also needs NVIDIA to confirm that the GPU's certificates are still good. either your journal asks NVIDIA itself, which shows NVIDIA your network address, or our machine passes your journal NVIDIA's signed answer. either way, NVIDIA sees which certificates were checked and nothing you send. (older versions also ask NVIDIA for the GPU's reference measurements.) if any of it fails to verify, nothing is sent. your journal waits, tells you plainly that it could not verify, and never silently falls back to some other service. you can turn it off entirely and process locally at any time.

what we keep. nothing from what you send. that is what keeping nothing means, and it includes logs. we keep no connection metadata for this service, beyond the request trace described in your sign-in, which for a credential check names no journal or sign-in. the network the machine sits on handles the connection itself, as the relay's does, and the processor table says what Azure sees. inside the confidential container the service does count how much confidential processing it has done for a journal, so it can manage capacity, and it notes that a channel was admitted or refused. neither is tied to who you are outside that boundary, neither holds what you sent, and that count never leaves the container.

apart from the request trace, what we do keep outside it is the minimum needed to control who can use the service: three things, all about access rather than content, and all deleted when your sign-in is.

together they tell us that you consented, and each time your journal was issued or refused a credential. they tell us nothing about what you sent, and none of them says how much you used. all three are Customer Data under our covenants: we use them only to run and control access to the service, and we never sell them, profile you with them, or use them for advertising.

the one thing the container sends the rest of our systems is your credential, shown to the services portal (which runs on Cloudflare) when a channel opens, so the services portal can answer yes or no that it is still good. outside the container we write nothing down about that check beyond the request trace described in your sign-in and the short-lived request logs our providers keep, described in your rights. metering and abuse handling both run inside the confidential container.

who processes it. sol pbc, which runs the model and the serving stack. Microsoft Azure, which hosts the confidential GPU machine and is excluded by that machine's hardware from what it is processing. Cloudflare, which runs the services portal that checks a credential and the database that holds the three access records. Stripe, where the access is paid. no third-party AI provider is in the path.

access, and turning it off. access is either complimentary through the scout program or by subscription, and where you subscribe, the billing section says what we hold. turning it off returns processing to your own machine for anything your journal starts from then on, and work already under way finishes where it started; the audio switch does the same for audio alone. when access ends, processing returns to your own machine, and nothing is lost, because nothing was stored. the services terms say when that happens.

how to see, export and delete. none of what you send is retained, so there is nothing there to export or delete. the first two access records are in your data download at services.solstone.app/account/export; the third, the short-lived turn-on record, is not, and the download says so. all three are deleted with your sign-in, as your rights describes.

if we're compelled. there is no retained content to compel, because none is kept once a request is answered. what a demand could reach is your sign-in and billing record (on the same terms as any other service), the three access records described above, the request trace described in your sign-in, and, as with the relay, whatever Azure's network still retains of the connection. never the contents of what you sent, because they are not there to give. we resist such demands to the maximum the law allows and notify you when we legally can.

from solstone.me: an address for your journal, connection metadata, never content#

what it is. an address on the internet for your journal, so an agent you already use can read from it. you turn it on, you connect an agent, and you choose what that agent may see; your journal enforces that choice on your own device. sol pbc runs a relay in between. it's a convenience, never a requirement: a tunnel that only passes the bytes through works with nothing of ours in the path.

blind by construction. your own machine holds the certificate's private key and ends the encryption, so the relay passes bytes it has no key to and cannot read. it also keeps nothing: no database, no file, no lasting record of what passes through it. that is how the relay is built, not a setting we have to be trusted to honor. what it writes down about its own health says that something happened, never who it happened to.

what this doesn't protect against. whoever controls the solstone.me name (today, sol pbc and Cloudflare, which registers it and answers its lookups for us) could in principle get a certificate of their own for your address, and with it read what your agent reads, and reuse your agent's key to reach your journal as though they were your agent. we don't. a new certificate would normally show in public certificate logs, which anyone can check, but a certificate authority can issue one without logging it, and the software agents connect with usually doesn't insist that it was logged. until november 30, 2026, Cloudflare also holds older certificates that cover every solstone.me address, and using one of those wouldn't show in the logs at all. if you'd rather not rely on any of that, use your own domain with a tunnel that only passes the bytes through, and sol pbc is out of the path entirely. one warning: some free tunnels decrypt your traffic in order to move it. whoever runs one of those can read what your agent reads, and can reuse your agent's key to reach your journal as though they were your agent. look for a tunnel that says it only passes the bytes through; if its documentation doesn't say, assume it ends the encryption.

your address. turning it on gives your journal an address: eight random characters, followed by solstone.me. it is made from nothing of yours, and by itself it says nothing about you or your journal. so that an agent can trust it, your journal gets a standard certificate for that address (today from Let's Encrypt), and like the certificates behind secure websites, each one is listed in public certificate logs that nobody can edit. so the fact that the address exists stays public for good, including after you turn the service off, cancel, or close your sign-in. the turn-on screen says the same. your address is never reassigned to anyone else.

what we keep. three records, all at services.solstone.app, and all Customer Data under our covenants:

the first two are deleted with your sign-in. the third is not, and that is deliberate. it is how we make sure your old address is never issued to someone else. once your sign-in is deleted, there is nothing in it that points back to you.

what we do not keep. your journal asks us for a short-lived pass whenever it needs one. we keep no log of those passes, beyond the short-lived request logs our providers keep, described in your rights, and the request trace described in your sign-in, which carries nothing that ties a pass to you. confidential processing keeps a record of each credential it issues or refuses; this service does not. and sol pbc holds no readable record of what any agent asked your journal for, what it was shown, or what it was refused. that record is kept by your journal, on your device, for you to read; we do not receive it in any form we can read, and the service is built never to send it to us, except that if you use the operated backup, it is inside the encrypted copy of your journal, which we have no key to.

connection metadata. to carry your traffic, the relay and Microsoft Azure (whose machine it runs on) necessarily handle connection metadata: the network (IP) addresses your journal and the agent reached it from, that they met, when, and how much moved. sol pbc sees that, and never what they said. the relay keeps no lasting record of it; what Azure's network retains of it is Azure's, on its own schedule, under the Microsoft privacy statement. separately, Cloudflare runs the control plane that mints your address and issues those passes, so it sees the network address your journal asks from; and Cloudflare answers the address lookup for solstone.me, so it sees that your address was asked for, when, and the network address that asked, which is usually your agent's internet provider rather than the agent itself. that lookup service is used for nothing but this, so every lookup there is one of these.

the agent is yours, and its maker is not our processor. the agents you connect are run by other companies, or by you. connecting one means giving it your address, so whoever runs it knows where to find your journal and can match it to the public certificate listings above; and what it reads goes to them, on their terms. sol pbc is not a party to that and does not see it. this policy does not describe what they do with it, and our covenants do not bind them.

who processes it. Microsoft Azure (the machine the relay runs on), Cloudflare (the control plane that mints your address, the database that holds the records above, and the address lookup for solstone.me), and Stripe (payments). all three are named below and see only what is described here, and are given no readable byte of your journal.

when you stop paying. the relay stops carrying your traffic at the end of the period you paid for. your address stays reserved for you: the address binding and the turn-on record stay until your sign-in is deleted, and subscribing again brings back the same address.

how to see, export and delete. your sign-in data is at services.solstone.app/transparency, and your subscription is on this service's page there. the address binding and the turn-on record are in your data download (your rights), and the download names the address reservation as a record we keep. closing your sign-in, as your rights describes, deletes the address binding and the turn-on record. it does not delete the address reservation, which we keep on purpose so your address can never go to someone else, or the public certificate listings, which nobody can edit.

if we're compelled. if someone served sol pbc a subpoena over this service, what we could produce is your sign-in and billing record, the three records above, the request trace described in your sign-in, and whatever Azure's network and Cloudflare still retain of the connection and lookup metadata. never what an agent asked for or was shown, because we have no readable copy of it. never the contents, because there is no key and no plaintext to give. we resist such demands to the maximum the law allows and notify you when we legally can.

from notifications: never what one says#

notifications are built into the solstone app: free, no sign-in needed. a notification the app raises and shows on the same device never leaves it.

notifications from your journal to your phone are off until you turn them on, phone by phone, in the solstone app. when you turn them on, the phone makes its own key and hands it to your journal over the connection they paired on, and your journal locks every notification with that key before it leaves your machine. only that phone and your journal can read what a notification says. every one is padded to the same size, so its length says nothing either. turning them off on the phone takes it off your journal's list the next time the phone reaches your journal, and unpairing the phone from your journal takes it off at once. either way, your journal stops sending to it.

reaching a phone that's away from home means going through the phone's push service. here is what each party along the way handles:

a push service keeps a locked notification only until it reaches your phone, for up to a day, or on a delivery app's own schedule. none of them ever sees what a notification says. they aren't our processors: they're the push services phones use, and they handle what they see under their own terms. on iphone, the app may get a push token from Apple before you turn notifications on, but it hands it to your journal only once you do. once a notification is on your phone, the phone shows it the way your notification settings say, lock screen included.

from applying for or receiving scout status: application and status history, never your journal#

scout is a status on an owner sign-in. approval enables complimentary access to eligible services; paid access is independent. if you apply for or receive scout status, we keep the application text you submit, the fact and time you acknowledged the disclosure, the current status and its timestamps, and a forward-only history of real status changes.

each lifecycle-history event says what administrative action occurred; the internal owner-sign-in identifier; the prior and new status; a standard reason; whether the action came from the owner, a named operator, or an authenticated automated service; and the time, order, and reference identifier. events are append-only: we do not edit or selectively delete them. the history began when this feature launched, in july 2026; we did not invent old events from prior timestamps. it contains no journal content, application text, customer email, credential or token, network address, browser details, billing identifier, or key material. an operator email may appear only to identify that authenticated operator; an automated service is never presented as identifying a human.

we use lifecycle history only to administer and secure scout status, include it in your data download or provide it on request, and resolve operational problems with your status. it is never used for analytics, aggregate reporting, advertising, profiling, behavioral measurement, or model training. history remains while the owner sign-in exists and is deleted with it. your scout application and history are in your data download (your rights); ask for a correction of the current status at support@solstone.app; closing your sign-in, as your rights describes, deletes it too. our own notes on your application, which may quote it, stay in our records; those records keep a history, so a copy can outlast the deletion in a form only we can reach. this history never contains or deletes the journal on your own devices.

from subscribing (billing): the minimum to bill you#

if you subscribe to a hosted service, we collect and keep the minimum needed to run your subscription: your email address, your subscription status and renewal dates, a reference that ties the subscription to your sign-in, when you asked us to start a service right away, if you did (a request whose checkout never finished is deleted after two days), and a copy of each confirmation, renewal reminder and other notice we email you as a subscriber, with when we sent it; those copies are in your download and deleted with your sign-in. if you withdraw from a subscription at services.solstone.app, we keep a record of it: which subscription and service, and its dates. the acknowledgement we email you isn't kept, only when we sent it. the record is in your download and deleted with your sign-in. payments are handled by Stripe, our payment processor. your card and payment details go directly to Stripe and are governed by Stripe's terms and privacy policy. sol pbc never sees or stores your card number. Stripe holds the card, the name on it and the billing address; an operator can see details such as the card's brand, its last four digits, the name and the billing address in Stripe's own dashboard, to answer a billing question. we also have read-only access to Stripe, which shows what Stripe holds about your payments, such as those details, the card's expiry and each charge, and we use it to run your subscription, which includes answering your billing questions, and to keep our books. the AI agent that helps us can use that access too, on an outside provider's models as writing to us describes, and our own working records of that look-up may keep what it showed. the services portal and the hosted services never ask Stripe for your card's details, and keep none of them. we send Stripe only what it needs to charge you and tie the charge back to you: the email on your sign-in, a reference to your sign-in, the service you chose, and the transaction itself. from what Stripe sends back, we keep what we need to run your subscription: that a payment succeeded or failed, when it renews, and Stripe's own numbers for you and your subscription, so we can match what it tells us to your sign-in. the notice copies above also repeat your plan's price and billing period, and we keep a one-way keyed fingerprint of each checkout that started a subscription, which your rights names among what outlasts a deletion. we never send Stripe anything from your journal. at checkout, Stripe may show a box offering to save your payment details to Link, its own wallet. in some countries, the US among them, the box comes already ticked and asks for your phone number, and you can untick it. Link is Stripe's, under Stripe's own terms, and we keep nothing you give it.

we use your billing details only to run your subscription and keep our books. we do not sell them, share them for anyone else's purposes, or use them for advertising, profiling, or any other purpose; Stripe's own uses of what we send it are described under who processes data for us. (see what sol pbc will never do.) we keep your billing details until your sign-in is deleted, which deletes your customer record at Stripe as part of it: the card goes and any subscription is canceled. the charges and invoices that record carries are the main exception, and they sit on two clocks: our own copy of the transaction records stays for the period tax and financial-records law requires (generally up to seven years), and Stripe keeps its own for five years or more from the end of its relationship with us or your last transaction, whichever is later, because an issued invoice, which carries your email, can never be redacted. your rights names both.

from writing to us: what you send us#

the support form. anyone can ask for help at support.solstone.app without signing in. we receive the subject, the details, which product you picked, and, if they're filled in, the your versions box and your email. if you report a problem from inside a solstone app, it fills some of the form in for you: the versions you're running and the system they run on (its name, version and chip type), the diagnostic lines it shows you under the report, and a few facts about the error it was reporting (which screen, a reference id, the status). you see all of it on the form and can change or delete any of it before you send. we give you a reference number. Cloudflare runs the bot check that loads in your browser, the network, and the database behind the form; we pass it the address your request came from along with that check, so it can tell a person from a bot, and we keep no record of that address ourselves. when a request closes, what you sent is deleted. what's left is a marker with the reference number, how it closed and its dates, plus a one-way fingerprint that stops a retry being filed twice and is deleted after at least 45 days, and, if we closed it ourselves, a note of who did it and what state the request was in. through august 7, 2026, our systems also wrote their own record of each request as it arrived. that record keeps the request's subject and who sent it, and its history can hold what you wrote, so for a request sent by then, the subject and what you wrote can outlast the deletion in a form only we can reach. if you have a sign-in, requests you make at services.solstone.app/support carry the same things, plus your verified email and any files you attach, which we keep only until we've read them, keeping a short note of what each contained until the request closes; all of it is tied to your sign-in and deleted with it. until september 2026 a journal could register with the support site on its own; that route is gone, and the registration records it left were removed in september 2026.

the contact form on solpbc.org. what you write, your name, and your email reach us so we can answer you, and an outside AI service screens the message on the way in, as part of the check we run on it. the form runs Cloudflare's bot check in your browser, the same way the support form does, and we keep no record of the address it was sent from. what you wrote lands in our mailbox, which Google runs for us, and stays there until you ask us to delete it. the record our systems write about its arrival keeps your name, your email, when you wrote, a pointer to the message in our mailbox and how our AI check on the message rated it, not the message itself; that record keeps a history, so it can outlast a deletion in a form only we can reach. through september 26, 2026 it kept what you wrote as well, so for a message sent by then, a copy can outlast the deletion the same way.

email. if you email support@solstone.app or our older address, support@solpbc.org, or reply to something we sent you, your mail lands in a mailbox Google runs for us, and stays there until we delete it; ask from that address and we will. we use it to respond to you. we don't add you to mailing lists, share your email for anyone else's purposes, or use it for marketing.

elsewhere. if you ask for help on GitHub or Bluesky, what you write is held by that service on its own terms, and is public unless you send it privately, as a direct message or a private report; we read it there.

whichever way you write to us, an AI agent reads what you send and drafts our answer, and a person here may read it too. the AI tools we work with run on an outside provider's models. our own notes on it (which may quote what you sent) stay in our records, and so, for email, do the sender, the recipients and when it arrived; where our AI check reads an email, how the check rated it stays there too, all on the same terms as the contact form above. through september 26, 2026 those records also kept each email's subject, its opening lines, and the check's summary of the email, which could quote it. so send what helps and nothing more. we never train a model on what you send us.

from solpbc.org and the sites listed here: almost nothing#

when you visit solpbc.org, v-it.org, solstone.app, trust.solstone.app, transparency.solstone.app or explore.v-it.org, or solstone reaches updates.solstone.app as local use describes, our hosting provider, Cloudflare, collects standard edge server logs (IP address, pages visited, browser type, timestamp). this is inherent in how the web works. Cloudflare's collection and handling of these logs is described in the Cloudflare privacy policy under "end users."

sol pbc reads only aggregate counts of requests and errors from these logs, grouped by site or service where needed, to keep the sites up, and never anything about a visitor. we don't use Google Analytics, tracking pixels, cookies, or any other tracking technology on any of these sites; the contact form's bot check and the video player on our talks page both run in Cloudflare's own frames, under Cloudflare's privacy policy.

from children: nothing, and we don't want it#

our services aren't directed to children under 13, and we don't knowingly collect their data. if you believe a child's data has reached us, email support@solstone.app and we'll delete it.

what sol pbc will never do#

these aren't policies. they're binding covenants in our articles of incorporation and bylaws. while the founder serves as a director, any amendment to Article 8 requires his personal written consent (a right that cannot be delegated). after he ceases to serve, amendments to Article 8 are permitted only to strengthen these protections, or to comply with mandatory law to the minimum extent strictly required. (Articles of Incorporation, Article 8, Section 8.6.) the bylaws sit under Article 8 and cannot be used to narrow it. (Bylaws, Article VI.)

throughout this policy, your data means what Article 8 defines as Customer Data: any data, information, content, record, output, or inference concerning you or derived from such data, including de-identified, anonymized, aggregated, pseudonymized, or encrypted forms. connection metadata, billing records, and every access record named above are all Customer Data, and the covenants reach every one of them.

these covenants bind the company, and any successor that takes on your data must take on covenants no less protective than Article 8. they apply in full to the hosted services. the relay's blind-by-construction design, the operated backup holding encrypted blocks we have no key to, and the solstone.me relay passing bytes it has no key to, are these covenants made concrete. confidential processing is a convenience, never a requirement: a local path is always available, and turning it on is your own specific, informed choice. it is the one where our own model reads what you send while it answers you, and what stands in place of a key we don't hold is a published build your journal verifies before it sends.

the narrow exceptions. your data leaves sol pbc only in the three narrow ways the covenant allows (Articles, Section 8.3(a)(2)): (1) to a service provider bound to protections no weaker than the covenant, and only as far as strictly necessary to provide, maintain, secure, or support the service you asked for; (2) at your own specific, informed direction for that particular thing, never by this policy alone or a default you didn't change, for example by choosing to pay Stripe by card; or (3) when we're compelled by law, in which case the covenant requires us to use reasonable efforts to keep it to the minimum required and to notify you unless the law forbids it, and our bylaws add that we resist such demands to the maximum the law allows. we never sell, license, sublicense, or lease your data (Articles, Section 8.3(a)(1)), and we never share it for anyone else's purposes.

who processes data for us#

sol pbc keeps its processor list for the hosted services and your sign-in short, and names each one; the writing to us section says what else touches what you send us, and your sign-in and billing say what touches a sign-in or billing record we look up. Cloudflare, Microsoft Azure and Stripe are each bound by contract never to use what we send them to advertise to you, to build a profile of you as a person for us or anyone else, or to sell it; Google runs our mailbox under Google Workspace's standard terms and is not in the path of any hosted service. like any payment or infrastructure company, each also runs its own fraud-prevention, security, and service operations on the limited technical data it handles; for Stripe that means scoring the payment, and Stripe's own terms let it analyze what it holds about you, the email and transaction details we send included, to improve and develop Stripe's products. that is exactly why we send each one only what it needs to do its job. none of them is given a readable byte of your journal; what each one does hold is in the table below. Apple and Google also run the push services phones use, which carry notifications from your journal once you turn them on. they aren't our processors, and the notifications section says what they see.

providerwhat they handlewhat they can see
Cloudflarehosts solpbc.org and its contact form, v-it.org, solstone.app, trust.solstone.app, transparency.solstone.app, explore.v-it.org (the index of public vit records) and its database, and updates.solstone.app, where solstone fetches its runtimes, models and tools, and checks for newer versions; hosts services.solstone.app and the bot check on its sign-in form; runs the network the private network relay runs on, and the database holding the relay's records of your journals; runs the network the notification hop for iphone runs on, and the storage that holds the services portal's request trace, including the hop's; runs the control plane that mints a solstone.me address and issues its passes, the database holding its address binding, turn-on record and address reservation, and the address lookup for solstone.me; runs the storage (Cloudflare R2) for the operated tier of encrypted backup; runs the database behind services.solstone.app (your sign-in, scout records, subscriptions, and confidential processing's access records) and the services portal's check of a confidential-processing credential; delivers the emails we send you from services@solstone.app: sign-in and verification codes, and the confirmations, reminders and other notices about your subscriptions; runs the support form, its bot check, its database and the storage its attachments land in; and carries mail sent to support@solstone.app on its way to our mailboxfor solpbc.org, the other sites named with it and updates.solstone.app: standard edge logs (it gives us only the aggregate request and error counts described above). for explore.v-it.org's database: the public vit records and handles the index holds. for the relay: connection metadata, the encrypted bytes, and the relay's record of your journal described above (no record of your devices). for the notification hop: connection metadata and what passes through it (your journal's id, your phone's push token and the locked notification), and the request traces the notifications section describes, never what a notification says. for the operated backup: the encrypted blocks, the operational information above (object count, size, last-changed), the credential log and cleanup records, and connection metadata (network address, timing). for services.solstone.app: the sign-in, scout, subscription, and hosted-service access records described above, the network address you sign in from (passed with the bot check on its sign-in form), the request trace described in your sign-in, and nothing you send the model. for solstone.me: the network address your journal asks for a pass from, and, at the address lookup, that your address was asked for, when, and the network address that asked; not the traffic itself, which does not pass through Cloudflare (solstone.me says what Cloudflare and sol pbc, which control the name, could do). for the support and contact forms: what you sent and the address it came from, on its own schedule (and, for up to a day, the contact form's copy of what you sent). for email: what we email you from services@solstone.app and the mail you send us, in transit. given no readable byte of your journal
Microsoft Azurehosts the confidential GPU machine that confidential processing runs on, and the ordinary machine the solstone.me relay runs onfor confidential processing: operational facts about the machine itself: that it exists, its size, and when it is running. because your journal connects to that machine directly, Azure's network also necessarily handles the connection: the address it came from, when, and how much data moved. the hardware boundary excludes Azure from what the machine is processing, memory included, so it sees no content, no prompts, no transcripts, and nothing from your journal. for the solstone.me relay: the same operational facts about that machine, and the connection metadata its section describes. that machine has no hardware boundary of that kind; what keeps Azure out of your journal there is that the bytes it carries are encrypted to a key only your own machine holds, and the relay keeps no record of them
Stripepayment processing for the hosted subscriptionsyour card and payment details (which you provide to Stripe directly), the minimal billing info we send to charge you, and what its own checkout page collects from your browser under its privacy policy. never anything from your journal
Googleruns the mailbox where mail to support@solstone.app or support@solpbc.org, what you send through the solpbc.org contact form, and our replies land. it is not in the path of any hosted service, and holds the mail under Google Workspace's standard termsthe mail and contact-form messages you send us, and the mail we send you. nothing else as our processor; notifications covers its push service

if we ever add or change a processor, we'll update this list and the changelog below.

your rights, and how to see, export and delete#

you have rights over your data, and we extend them to everyone, regardless of where you live:

see it. services.solstone.app/transparency shows each kind of record the download carries except support requests, with your most recent records of each; your support requests are at services.solstone.app/support.

download it. at services.solstone.app/account/export you can download what we hold for your sign-in as one file. the page asks you to prove it's you, and the file covers your sign-in, your subscriptions, your scout application and history, the lasting access records each service's section names, and what the relay and the support system hold for you. it names, by kind, most of what it leaves out: your journal's contents, which stay in your journal and are not held with your sign-in, and the backup's encrypted contents, which we can't read; your receipts and past charges, which Stripe holds and you can download from Stripe's billing portal; support requests sent without an email address, which can't be tied to your sign-in; the working records behind signing in, turning a service on and closing your sign-in (sign-in codes and challenges, the abuse counts, the short-lived records a turn-on page leaves for your journal to collect, credential fingerprints and reservations, and the records of your request to close it); and anything a service could not answer for at that moment. things it leaves out without naming them include the services portal's request trace (your sign-in) and the security-event records named below. for those, and for anything else, email support@solstone.app.

delete it yourself. at services.solstone.app/account/delete you can close your sign-in, which ends every service tied to it; you can't do this one service at a time. the page asks you to prove it's you, and you then have 72 hours to change your mind and keep your sign-in. if you keep it, the request itself, with its dates and the one-way fingerprints of the proof you gave, stays on your sign-in until your sign-in is deleted. if you don't, once the 72 hours are up we delete your sign-in, your emails, passkeys, and sessions, your subscriptions and the service records tied to them, the relay's record of your journal, your solstone.me address binding and turn-on record, your support requests, the encrypted copy in the operated backup, and your customer record at Stripe. those sign-in and service records are gone from sol pbc's active systems within seven days after the 72 hours are up. we commit to that: deletion keeps retrying each part until it succeeds, and you can check where it stands at services.solstone.app/account/delete/status. the longer-lived exceptions are named below. it never touches your journal on your own devices, your devices themselves, or a bucket you control.

a few things outlast a deletion, and this list applies wherever another section says something is deleted with your sign-in or kept until your sign-in is deleted. the transaction records: our copy, for the period tax and financial-records law requires, and Stripe's charges and invoices, which Stripe keeps for five years or more on its own clock, as the billing section describes; and the fraud signals Stripe's own systems derive from your payments, which Stripe keeps for as long as it finds them useful and which we cannot delete. the services portal's request trace, until it goes, as your sign-in describes; the request logs our providers keep for a short time on their own schedule, and the delivery records of the emails we sent you or that Cloudflare routed to support@solstone.app, which it holds for a period we have not been able to verify. security-event records, which carry a one-way reference to your sign-in (and, for a backup refusal, to the journal it was for) and nothing from your journal, kept in our own records with no scheduled deletion date. the rolling recovery image our database provider keeps so we can undo our own mistakes, which covers the last 30 days and expires on its own, so anything deleted is gone from it 30 days later. the hashed, unreadable record of the deletion itself, for up to a week, and after that an unlinkable note that a deletion ran and finished, with its dates and how each part went, which names nothing about you. a one-way keyed fingerprint of each checkout that started a subscription, with when we recorded it and nothing else attached, kept with no scheduled deletion date so that our own internal alert of a new subscription, which says only which service and when, is never raised twice. the closed-request marker and one-way fingerprint the support section describes, on that section's schedule. and, if you ever turned on solstone.me, two things that never expire: the reservation of your address, which is the address and when it was reserved with no name, sign-in or journal attached, kept so it can never be issued to anyone else; and the public certificate listings for that address, in logs sol pbc does not run and cannot edit. any mail you sent to, or got from, support@solstone.app or support@solpbc.org, and any message you sent through the contact form, which stay in our mailbox unless you ask us to delete them too. our own records of any support request sent by august 7, 2026, and of any contact-form message or email. our own notes on any support request, contact-form message, email, GitHub or Bluesky message, or scout application, which name who wrote and may quote what you sent, as the writing to us and scout sections describe. and our own working records of any time we looked up your sign-in or your billing at Stripe, which may name your email or keep what the look-up showed, as your sign-in and billing describe.

everything else. for correction, or any other right, email support@solstone.app (for the services portal and hosted services) or contact us. we'll respond as fast as we can, and within the time the law requires: 45 days under the Colorado Privacy Act, one month under GDPR, with the extensions each allows.

if we deny a request, you can appeal by replying to support@solstone.app; within 45 days we'll tell you in writing what we did or did not do about it, and why. if we deny the appeal, you can raise it with the Colorado Attorney General or the privacy regulator where you live, and nothing here stops you going to court.

if you're a Colorado resident, you have the specific rights granted by the Colorado Privacy Act; residents of California (CCPA/CPRA) and the EU/UK (GDPR) have the rights those laws give them, where they apply, including, where a law grants it, the right to restrict or object to processing. where GDPR applies, our legal bases are these. we process your sign-in and billing data, and the records each service's section names, to perform the contract you asked for. we process what you write to us, our notes on it, the abuse and security records this page names, the checkout fingerprint named above, our working records of looking up a sign-in or a billing record, the edge logs and bot checks this page names, and the services portal's request trace, based on our legitimate interests in answering you and running and securing the service. we run the index of public vit records based on our legitimate interest in making those records browsable and searchable. you can object to either. we keep the transaction records the law obliges us to keep, as the billing section says. we process anything else only with your consent or where the law requires it. where we rely on your consent, you can withdraw it at any time without affecting what was done before. for anything that would leave sol pbc, the narrower rule in what sol pbc will never do applies on top of this. sol pbc does not make automated decisions that produce legal or similarly significant effects about you, and does not profile you. our covenants go further than any of these laws require. exercise any of them through the channels above.

vit and AT Protocol#

vit is built on AT Protocol, a decentralized protocol where most data is public by design. when you publish a capability, vouch for a skill, or follow someone on vit, that data flows across the AT Protocol network to relays and indexers operated by many different parties.

sol pbc's privacy commitments apply to data on sol pbc's infrastructure. once data is published to the AT Protocol network, sol pbc cannot delete copies from other servers. this is how decentralized protocols work.

sol pbc runs one index of public vit records, at explore.v-it.org, on Cloudflare. it copies the capabilities, vouches and skills people publish, with the identifier of the account that published each and the handle it resolves to, so they can be browsed and searched. when its author deletes a record, the index deletes it too, unless it missed the deletion. a record whose deletion it missed, the records of an account that was deleted or taken down, and every handle it has looked up stay in the index until we remove them, and we will if you ask. vit's explore and inbox commands ask this index, so using them leaves the same edge logs as visiting solpbc.org, including which project you asked about.

if sol pbc operates a relay or PDS for vit, we collect only what the protocol requires to function. no additional tracking, analytics, or data collection.

solstone and recording laws#

when what you share with the solstone app includes audio of a conversation, wiretapping and consent statutes call that recording, the term used in this section, because it is the term used in the laws.

the solstone app takes in what you share with it, including your screen and, when you turn audio recording on, the audio you record. all of it goes into your journal. if you use solstone, you are responsible for complying with recording-consent laws in your jurisdiction. some states and countries require all parties to a conversation to consent to recording.

sol pbc doesn't record anything. you do, on your own hardware, and it reaches sol pbc only through a hosted service you turn on. we recommend informing others in advance when audio recording is active during conversations.

changes to this policy#

if we change this policy, we will:

1. update this page with a clear summary of what changed

2. update the changelog below

before we launch any new hosted service, we publish the updated policy here. the covenants above apply to all services, and they cannot be weakened through a policy update. see the amendment lock described above.

changelog#

datechange
2026-10-06you now close your sign-in, rather than delete it. where the page described what you do at services.solstone.app/account/delete, it now says you close your sign-in and have 72 hours to change your mind and keep it; delete stays for what sol pbc then deletes, and for your right to deletion. what is deleted, when, and what outlasts it are unchanged. what closing does to your services and subscriptions is in the services terms.
2026-10-06added the solstone extension, which works with the solstone app: that it reads only sites you add, after you agree on its welcome page and your browser asks you to allow each one; what it takes in on those sites, including messages on a mail or chat site and text a page doesn't show; that it sends everything only to the solstone app on the same computer and connects to nothing on the internet itself; that the solstone app puts it into your journal the way it does everything else it takes in; what stays in the browser and how to clear it; and sol pbc's affirmative Chrome Web Store Limited Use statement. no processor added or removed. the binding covenants are unchanged. writing to us names the versions box and what a report fills in. both support forms have an optional your versions box, and when you report a problem from inside a solstone app it fills in the versions you're running and the system they run on; the page now says so, and that you see and can change all of it before you send. wording: the relay keeps a record of your journal, and the page no longer calls your journal or its computer your home.
2026-10-06what you send through the contact form now lives in our mailbox, not in the records our systems write about it. since the afternoon of september 26, 2026, a contact-form message lands in the mailbox Google runs for us, and the record of its arrival keeps who wrote, when and how our AI check rated it, not the message itself; the record of an email no longer keeps its subject, its opening lines or the check's summary of it. the page now names Google for the contact form too, and says that these records keep how the AI check rated a message. also named, where the page had left them out: our older support address, support@solpbc.org, which still reaches the same mailbox; that a support request sent by august 7, 2026 left a record of its own in our systems, which keeps its subject and who sent it, and a history that can keep what you wrote; the apps' checks for a newer version; that older versions of solstone fetch some of their tools from GitHub or the tools' own sites; that confidential processing's check asks NVIDIA whether the GPU's certificates are still good; the bot check on the services portal's sign-in; the edge logs of v-it.org, solstone.app, trust.solstone.app, transparency.solstone.app and explore.v-it.org; the index of public vit records sol pbc runs, and that vit's explore and inbox commands ask it; help asked on GitHub or Bluesky; our read-only access to Stripe, which shows what Stripe holds about your payments, and that the AI agent that helps us can use it too, and that our working records of a look-up may keep what it showed; and that when we look up a sign-in, the AI agent that helps us sees what we look up, and our working records of it may name your email. named a limit on what solstone.me protects, and what takes sol pbc out of it: whoever controls the solstone.me name, today sol pbc and Cloudflare, could in principle get a certificate of their own for your address; a new one would normally show in public certificate logs, but not always, and until november 30, 2026 Cloudflare also holds older certificates covering every address, and using one of those wouldn't show in the logs; so where the page said sol pbc can't see an agent's traffic, it now says sol pbc doesn't, and the Cloudflare row now says it is given no readable byte of your journal; your own domain, with a tunnel that only passes the bytes through, takes sol pbc out of the path, and the section warns that some free tunnels decrypt your traffic to move it, and that whoever runs one can read what your agent reads and reuse your agent's key to reach your journal. the summary line in confidential processing now points at each service's own section for how its key keeps us out. corrected: where the page said sol pbc holds no record of what your agents asked and is built so it cannot receive it, it now says no readable record, and that if you use the operated backup, that record is inside the encrypted copy of your journal, which we have no key to. turning confidential processing or its audio switch off applies to anything your journal starts from then on, and work already under way finishes where it started; the page had said it took effect immediately. the page had said sol pbc's systems never fetch or store your card's details; the services portal and the hosted services never ask Stripe for them or keep them, but our read-only access to Stripe can show them. the page had said we use your billing details only to run your subscription; we also use them to keep our books. the page no longer says a closed support request keeps the product you picked; it doesn't. a sentence about your solstone.me address now says that it is never reassigned; it had said the address is never given to anyone else.
2026-09-26disclosed the services portal's request trace, which we have kept since september 12, 2026 and this page had described only for the iphone hop: a record of each request the services portal's code answers and each scheduled job it runs, deleted after 90 days, with no network address in it. the page says what some traces carry, and that older ones also record which page was asked for, until they are all gone by december 23, 2026. this corrects the sentences that said we keep no connection metadata for confidential processing, that we write nothing down about its credential check, and that we keep no log of solstone.me's passes, and it corrects how long the iphone hop's traces last; it corrects the page, not what we do. the trace is now named beside those sentences, in what outlasts a deletion, in what a demand could reach, in our GDPR legal bases, and in Cloudflare's row of the processor table. disclosed a one-way fingerprint of each checkout that started a subscription, kept with no scheduled deletion date so our own internal alert of a new subscription is never raised twice, and that the sign-in abuse counts are also kept per sign-in. the list of what outlasts a deletion now governs wherever another section says something is deleted with your sign-in or kept until your sign-in is deleted. disclosed that Stripe holds the name on your card and an operator can see it; that Stripe may offer its Link wallet at checkout, and that we keep nothing you give it; the copies we keep of the confirmations, renewal reminders and other notices we email you as a subscriber; and that Cloudflare delivers all the email we send you from services@solstone.app. clarified what the transparency page shows, what the download leaves out, and that services.solstone.app is the services portal. the iphone hop's list of what it forgets no longer includes when a notification was sent, because its trace keeps a time. added what withdrawing from a subscription, and asking us to start a service right away, would leave in our records.
2026-09-24notifications from your journal can now reach your phone, and they are off until you turn them on, phone by phone. disclosed what each party along the way handles: your journal locks each notification to a key only that phone and your journal hold, so no push service and nothing sol pbc runs can read one; on iphone, a hop sol pbc runs on Cloudflare's network passes it to Apple's push service and keeps no record of your phone or your journal; on android, your journal sends straight to Google's push service or your delivery app's server, which also sees the network address of the machine your journal runs on. Cloudflare's row in the processor table now names the hop, and Apple and Google are named as the push services phones use, not as our processors.
2026-09-20added sol pbc's fourth hosted service, solstone.me: an address on the internet for your journal, so an agent you already use can read from it, through a relay sol pbc runs on a Microsoft Azure machine that holds no key to what passes and keeps no record of it. disclosed in full: the three records we keep (the address binding, the turn-on record, and the address reservation); that the reservation outlives a deleted sign-in with nothing in it that points back to you, so the address can never be issued to anyone else; and that the address's certificates are listed in public certificate logs, as the certificates behind secure websites are, so the fact that the address exists stays public for good. we keep no log of the passes your journal asks for and no record of what any agent asked your journal for, what it was shown, or what it was refused. the connection metadata Azure handles and the pass and address-lookup metadata Cloudflare handles are disclosed, and the agents you connect are named as not our processors. Cloudflare's and Microsoft Azure's rows now say what each runs for it; no processor added or removed. also narrowed the stated use of connection metadata and storage information for private network and encrypted backup from "operate, secure, and bill" to "operate and secure", matching the services terms, and corrected the summary's claim that each hosted service has a free alternative: two of the four alternatives can cost money with another provider, so the page now says each has a way to do the same thing with sol pbc out of the path, and no longer calls the bring-your-own paths free. corrected the two sentences on a successor entity to carry Article 8's full condition: a successor must be bound to a substantially equivalent public benefit and to substantially equivalent balancing duties. corrected the sentence on new services: this page had said we would notify owners before launching one; we give no notice beyond this page and its changelog, so it now says that we publish the updated policy here before launch. added a table of contents and a link target for every section. the binding covenants are unchanged.
2026-09-20one comprehensive accuracy pass, and a reshaping so the page is easier to read. the short version is now a plain list with a link into each section, and each hosted service is described once, in one place, instead of in two. corrected: we stopped saying we keep a record of which of your devices may reach which of your homes, because since september 2026 we no longer keep one; the relay keeps a record of your home, and this page now describes that record rather than leaving it to be inferred. the page now says that the relay keeps no connection log of its own. added what the solstone apps on your phone and watch ask permission to reach on your own device: microphone, camera, location, local network and notifications, plus the screen on iphone and ipad, which the page had never described. added your sign-in: the emails, passkeys and sessions services.solstone.app holds, the 30-day tail on ended sessions, and where to see them; and, for each hosted service, the access records the portal keeps for it, which the page had named only for confidential processing. added notifications, which reach sol pbc not at all today, and the rule under which a cross-device hop would ever turn on. added writing to us: the support form, the contact form, where mail to support@solstone.app lands, which is a mailbox Google runs, and that an AI agent on an outside provider's models reads what you send us; Google is added to the processor table on that basis, and Cloudflare's row now names what it runs for us, including the support form, the sign-in codes we email you, and the portal that checks a confidential-processing credential. corrected the deletion story: you can delete your sign-in and every service yourself at services.solstone.app/account/delete, with a 72-hour safety period; the confidential-processing access records and the backup's credential log are deleted with your sign-in, where this page had said that was queued work; and the things that outlast a deletion are now named one by one, including the 30-day recovery image our database provider keeps. corrected the confidential-processing access records: they tell us that you consented and each time a credential was issued or refused, not how much you used, which stays inside the container; a third record, the one the turn-on page leaves so your journal can collect its credential, is now disclosed; and the container notes that a channel was admitted or refused. corrected the covenant on safeguards to match the bylaws' own words: sol pbc maintains them, access logging included. corrected the processor sentence so it no longer overstates Stripe's contract: Stripe's own terms let it analyze what it holds to improve its products, and this page now says so. corrected billing retention: this page promised to delete billing details once your subscription and the tax period had both ended; nothing ran that deletion, and billing details now stay until you delete your sign-in, which deletes your customer record at Stripe. added the self-service data download at services.solstone.app/account/export, which covers your sign-in, subscriptions, scout records and the lasting access records for each service; what the file leaves out, it names, and email stays the route for that. corrected the amendment-lock sentence so it reaches Article 8, which is what the founder-consent and strengthen-only rules lock, and says the bylaws sit under it. said that solstone fetches its runtimes, models and backup tool from updates.solstone.app, which leaves the same edge logs as visiting this site, and that we read only aggregate request and error counts from those logs. the contact form, and the support portal's former self-registration route and the removal of the records it left, are disclosed in the writing-to-us section. following the naming canon, this page now says "our own model" where earlier versions said "our own engine"; nothing about what reads your content changed. no processor was removed. the practices that changed are these: the relay no longer keeps device records, the support portal no longer registers journals on its own and the records that route left are gone, the contact form on solpbc.org no longer passes us the address it was sent from, and the deletions this page describes now run, including deleting your sign-in yourself; where this page had promised a scheduled deletion that never ran, it now says what we keep. the binding covenants are unchanged.
2026-08-28corrected the sentences that claimed, in sol pbc's name rather than a named service's, that nothing readable from your journal reaches us. those sentences were written when sol pbc ran two hosted services and both were sealed by key custody. confidential processing, added 2026-08-01, is sealed a different way: by a published build your journal verifies before it sends, and the sentences that summarised our services had never been updated to account for a third shape. each one now names the service it is about. the note above the processor table had been inaccurate since 2026-06-16, when Cloudflare was named as the relay's network processor: it said we send our processors "never a byte from your journal," while the table directly below disclosed the encrypted bytes and encrypted blocks Cloudflare holds. a correction, not an addition: this page previously said that to run confidential processing we count "fleet-wide totals" that are "not associated with you, your journal, or your account." that was not the instrument. what we actually keep, to run and moderate the service, is a record tying your access to your sign-in and to a journal, and a log of each time that journal was issued or refused a credential. both are associated with you, which is the opposite of what the old sentence said. both are Customer Data under our covenants and are now disclosed as such, with how to get them. we also say plainly, rather than round it off, that the second of those two outlives a deleted sign-in today, and that bringing it under the same deletion rule is queued work. we keep no connection metadata for that service, which is a real difference from the other two. the description of confidential processing also changed: it previously said only that we would not tell you we never see it, and it now says plainly that our own engine reads what you send while it answers you, and describes the published build and the check your journal runs before it sends. the recording-laws section now says that what you record on your own hardware goes elsewhere only through a hosted service you turn on. the covenant citation for "we never sell, license, sublicense, or lease your data" is corrected to Section 8.3(a)(1), which is the absolute; the previous line cited the conditional and dropped two of the four verbs. no data practice, processor, or retention period changed, and the binding covenants are unchanged, what changed is that the page now describes them accurately.
2026-08-21standardized the confidential-processing and recording-laws sections on solstone: the recording-laws section names the app as the solstone app. it now describes what the app takes in as what you share with it, no longer a closed list; attributes the act of recording to you where it describes that intake, not only where it allocates responsibility; and says that what the app takes in goes into your journal. the statutory term recording is unchanged, and so is the you-not-us responsibility allocation. no processor added or removed. the binding covenants are unchanged.
2026-08-01added sol pbc's third hosted service, confidential processing, an AI model sol pbc runs on confidential GPU hardware for journals that want more capacity to think with than their own machine has. disclosed in full: that it is off until you turn it on and reversible at any time; that what leaves your device is the text and images the model works through, plus your audio for transcription when that switch is on (it is on by default while the service is in use, and turning it off keeps speech-to-text on your own device); that your journal itself never leaves; that sol pbc runs the model itself, on its own weights and serving stack, with no third-party AI provider in the path; and, stated plainly rather than softened, that what you send is encrypted over the network but visible in running memory only while it is being processed by that engine, which is not the sealed arrangement the relay and the operated backup have, and we do not claim it is. what we do commit to is what becomes of it: the service runs zero data retention (ZDR). no content is kept, not even in logs. no human reviews it. nothing is used to train anything. named Microsoft Azure as a new processor: it hosts the confidential GPU machine (an AMD SEV-SNP confidential virtual machine with an NVIDIA H100 in confidential-compute mode) and the hardware boundary excludes Azure from what that machine is processing, memory included, so it sees no content, no prompts, and no transcripts. disclosed the verification: your journal cryptographically checks the hardware before every use — the AMD attestation chain, the GPU's evidence, the binding to the encrypted connection, and a fingerprint of exactly which software booted, pinned in solstone's open source code so it cannot be quietly repointed — and sends nothing if the check fails, deferring honestly rather than falling back to any other service. usage accounting is fleet-wide totals not associated with any owner. the binding covenants are unchanged.
2026-08-01removed the browser-extension disclosure added on 2026-07-26, because there is no longer a browser extension to disclose. sol pbc deleted the delivery route it used; that deletion shipped in solstone 1.0.21, and the extension is not a working part of solstone. it was never announced and never listed, and nothing it took in was ever readable to sol pbc, because it was sealed inside the browser and we held no key. when browser support returns it will be part of a full sol client and covered by that client's disclosures, and this policy will describe it then. the row below records what the 2026-07-26 disclosure said, and stays as written. also updated the recording-laws section to describe what solstone does as experiencing your day along with you, matching the language used elsewhere; the statutory term recording and the you-not-us responsibility allocation are unchanged. no processor added or removed. the binding covenants are unchanged.
2026-07-26disclosed solstone's browser extension in full: that it arrives holding no standing access to any website and reads only the sites you add behind a per-site browser permission grant (and what your browser hands its toolbar popup); that it takes in a page's rendered text and rough layout — including text the page renders out of sight, like screen-reader labels — but never pixels, raw HTML, form-field contents, clicks, scrolling, or keystrokes; that it reads an added site whenever a tab on it is open, background tabs included, and re-reads as the page changes; that the page address is reduced to origin and path inside the page before anything leaves it, with query strings, fragments, and embedded credentials dropped; that message text is included where you add a messaging site, and that outside Gmail and Slack a message you are still typing is taken in with the page; that what it took in waits in your browser's own storage until your journal accepts it, and how to clear it. named both destinations honestly: a journal on your own computer, which sol pbc never touches, or sealed inside the browser to your own home over the existing blind relay — with that relay's connection metadata and device-enrollment records disclosed as Customer Data, added to the relay section, the processor table, and both subpoena paragraphs. no new processor. added sol pbc's affirmative Chrome Web Store Limited Use statement, including that our articles bar selling outright and foreclose reliance on the store policy's merger/acquisition transfer permission. the binding covenants are unchanged.
2026-07-13disclosed Scout application/status history, including the forward-only lifecycle audit, its exact minimized contents, operational-only purpose, owner-sign-in-lifetime retention/deletion boundary, and support export channel; named Cloudflare D1 processing; clarified that local use of solstone and vit still sends sol pbc nothing. the lifecycle audit adds no journal content and the binding covenants are unchanged.
2026-06-23added sol pbc's second hosted service, the operated tier of encrypted backup (storage sol pbc runs so an encrypted copy of your journal can live off your own machine). disclosed what it collects — encrypted blocks sol pbc has no key to and cannot read, plus minimal storage operational metadata (object count, ciphertext size, last-changed time, used only to operate and bill) — named Cloudflare R2 as the storage processor, and disclosed the retention rule: after the paid period ends, the encrypted backup is kept 30 days, then permanently deleted. Stripe (payments) is unchanged. the binding covenants are unchanged.
2026-06-20renamed the hosted service from "solstone hosted — private link" to private network to match sol pbc's v2.1 brand model (the brand lives at the layer; services are named by mechanism). naming-only — no data practice, processor, or covenant changed.
2026-06-16updated for sol pbc's first hosted service, solstone hosted — private link (a paid, blind-by-construction relay). added the hosted-relay and billing data-collection disclosures; named Stripe (payments) and Cloudflare (relay network) as processors, with a processor table; described the hosted service in detail (data, processors, encryption, export/delete, graceful cancellation, rights); updated "your rights" with the services.solstone.app self-service + support@solstone.app channels, the CPA appeal mechanism, and the CPA/CCPA/GDPR rights. the binding covenants are unchanged.
2026-05-01hosting attribution corrected: solpbc.org is served by Cloudflare Workers only — the prior reference to GitHub Pages reflected an earlier deployment and was no longer accurate. linked to the Cloudflare privacy policy for the edge server logs Cloudflare collects from visitors.
2026-05-01updated to reflect the amendment and restatement of Article 8 (CO SOS Doc. 20261537456) and the adoption of restated bylaws. acquisition language updated to reflect that change of control is conditional (mission-aligned successors only, with covenants no less protective). amendment-lock language updated to reflect the new strengthening-only rule outside the founder's stewardship. operational-agent succession references removed; succession now flows through the Successor Designator mechanism in Article 8 §8.4.
2026-03-29initial publication

this privacy policy reflects the binding covenants in sol pbc's articles of incorporation and bylaws. the covenants are the authority: this policy describes them in plain language. if there is ever a conflict between this policy and the articles or bylaws, the articles and bylaws govern.

questions? get in touch.