Skip to content

Disclose the Pubchi outbound flow in the Terms and Privacy dialogs - #188

Draft
JeanlChristophe wants to merge 1 commit into
BitcoinErrorLog:pubchi/v1from
JeanlChristophe:legal/pubchi-terms-and-privacy
Draft

JeanlChristophe wants to merge 1 commit into
BitcoinErrorLog:pubchi/v1from
JeanlChristophe:legal/pubchi-terms-and-privacy

Conversation

@JeanlChristophe

Copy link
Copy Markdown

@BitcoinErrorLog for review. Opened as a draft on purpose: the text is ready but two things below are yours to decide, and it is your project to ship.

Why

bots.pubky.app serves the inherited Pubky App Terms and Privacy Policy, effective 29 January 2026. I checked the live bundle: artificial intelligence and model provider appear zero times in it, while Pubchi and kimi appear in the application code. So a user at this origin reads a social-only contract that says nothing about the feature that defines the site.

When someone asks their Pubchi something, their question, the conversation so far, the context assembled for it and their public key leave the device, and part of that is passed to a third-party model provider. Nothing in the current documents covers an outbound flow of user content to a model vendor, because nothing in Pubky App does that.

What this adds

One section at the end of each dialog, following the conventions already in those files: an all-caps heading, an italic intro in the Terms using baseCSSItalic, bold-led paragraphs, and the existing privacy@synonym.to link.

  • DialogTerms.tsx, Section 26, PUBCHI, YOUR PERSONAL BOT: what a Pubchi is, what leaves the device, that private material can be included in what is sent, that output is not published until the user publishes it, that answers are not advice, responsibility for tags applied to other people, what the bot key cannot do, availability, and that prohibited uses still apply.
  • DialogPrivacy.tsx, Section 17, PUBCHI: what is processed, why, who receives it, where it goes, what never leaves the device, how long, the user's choices, and other people's information.

One drafting decision worth knowing about

The provider is named as a category, "a third-party provider of AI language models", not as a company. GDPR Article 13(1)(e) requires the recipients or the categories of recipients, so this is sufficient, and it means the text stays accurate when the provider changes. The identity is given on request. The transfer paragraph is written the same way, so it holds whether the provider sits inside or outside the UK and EEA.

The practical consequence: this can ship without waiting on a vendor decision.

Oracle

  • tsc --noEmit clean.
  • Each dialog test gains an assertion on the disclosure itself, not just a snapshot, so these sections cannot vanish silently in a merge that overwrites these files. DialogTerms asserts the heading, the sentence naming the third-party provider, the sentence about the identity secret, and the no-advice sentence. DialogPrivacy asserts the heading, the recipient sentence, the transfer sentence, and the no-training commitment.
  • Both snapshots regenerated. 8 tests pass across the two files.
  • prettier --check and eslint clean on all four files. The pre-commit hook passed.

Two things for you to decide

  1. The Privacy text promises that the provider is engaged on terms that forbid training on inputs and limit it to returning the answer. That is a promise about a contract, so the contract has to match it. If the current setup calls a public API under its standard consumer terms, that sentence is not yet true and the fix is the provider arrangement, not the wording.

  2. This edits the two 64 KB legal files directly, which is the simplest thing to review but will conflict on the next merge from upstream dev. The added tests are there precisely so a lost merge fails loudly rather than silently. If you would rather carry the text in a small separate module that upstream leaves empty, say so and I will restructure it.

Not in this PR

A consent screen before the first request leaves the device. A disclosure in a modal is not consent, and the shape to copy already exists in this codebase: the Pulse consent gate from pubky#2527 asks before anything initializes, records the acceptance time under a versioned key, and deletes what it held on withdrawal. Happy to do that separately if you want it.

The footer on this deployment also still reads "By creating a Pubky account... built with love and dedication by Synonym Software, S.A. DE C.V.", while both documents behind it say Synonym Software Ltd. Left alone here since it is a separate question.

Made with Cursor

…cy dialogs

This deployment offers Pubchi, which sends a user's question, the conversation
so far and the context assembled to answer it to a third-party provider of AI
language models. The inherited Pubky App Terms and Privacy Policy describe a
social client and say nothing about that flow, so a user at this origin is
shown a document that does not cover the feature that defines the site.

Adds one section to each dialog, following the existing conventions in these
files: an all-caps heading, an italic intro in the Terms, bold-led paragraphs,
and the existing privacy@synonym.to link for the two requests a user can make.

The provider is named as a category rather than a company. GDPR Article
13(1)(e) requires the recipients or the categories of recipients, so the text
stays accurate if the provider changes, and the identity is given on request.
The transfer paragraph is written the same way so it holds whether the provider
sits inside or outside the UK and EEA.

Each dialog test gains an assertion on the disclosure itself, so the sections
cannot disappear silently in a merge that overwrites these files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant