PrivateGraph: a network system for one user has to drop automatic collection first

Core verdict: the product's biggest selling point and its hardest technical problem are the same sentence — absolutely private, for one user only. It is architecturally incompatible with cross-platform intelligent collection. The moment a server pulls data from platforms on your behalf, you have created a second personal-information processor and "only I can see it" stops being true. So the first decision in this plan is not a technology stack, it is cutting scope: redefine intelligent collection as user-initiated export plus local merging, and redefine matchmaking as suggestions only, with no messages sent on the user's behalf.

Note added 2026-11-05: in October 2026 more than 150 apps formally refused to let the Doubao phone assistant operate on their behalf, providing a ceiling case for cross-platform automatic data extraction. See the case study in chapter 3.

Codename: PrivateGraph. A working codename, not an official product name. Project opened 2026-11-05.

1. The problem is not forgetting — the data was never in one place

A person's contacts usually sit in five disconnected containers: paper business cards and conference directories, the phone address book, follower/following lists on content platforms, private messages and comment threads on social platforms, and assorted group chats. They share no common ID, no unified timestamp, and often not even a consistent spelling of a name.

A concrete example using our own public numbers: the ZouIC media matrix records followers on 5 platforms — 3287 on Toutiao, 317 on iQIYI, 131 on Weibo, 47 on Zhihu and 117 on the Tencent Omnia account, 3899 people in total. Those 3899 sit in 5 separate backends, none of which can see the other 4. How many are the same person under different accounts, how many work in the component trade, how many once asked for a quote — today that relies on memory. This is not an information-volume problem, it is a container isolation problem.

A more practical layer is matchmaking. Take electronic component sourcing: A says in one group that a batch is in stock, B asks for that part in another group, both know the owner, but the owner has not connected the memories from the two groups — and the deal is lost. Our component matching service is essentially a human doing this manually. What the product wants to reduce is exactly this loss of "I clearly know two people but cannot bring them to mind".

2. Three unavoidable contradictions

Contradiction one: absolute privacy vs cross-platform collection. Automatic cross-platform collection implies three things: holding platform account credentials, making requests to platforms on the user's behalf, and writing the returned data to disk. If that runs on a server, the data passes through a third party; even if the vendor promises not to retain it, legally it is still an entrusted processor (PIPL Article 21). Worse, simulated login or scraping generally violates platform terms and puts the account itself at risk of restriction. Conclusion: collection must happen on the user's own device, taking user-initiated export files as input.

Contradiction two: automated merging vs irreversible false merges. The same person appears as "Zhang Wei / Company X / 138xxxx" on a business card, as "Wei-ge" in a WeChat note, as "@xxx" on Zhihu and as "Engineer Zhang" in a group. With no global ID, cross-source merging can only be probabilistic. Once an algorithm mistakes two real people for one, two entirely different sets of relationships, chat logs and transaction notes are permanently glued together and are hard to detect. There is no undo button for this class of error. Conclusion: precision always outranks recall; the system only produces merge candidates and never auto-commits them.

Contradiction three: matchmaking vs separate consent. Matchmaking sounds like introducing two friends, but as a data flow it is handing A's information to B. PIPL Article 23 requires that providing personal information to another processor means disclosing the recipient's name, contact details, purpose, method and categories of information, and obtaining separate consent; Article 25 prohibits disclosing processed personal information unless separate consent is obtained. Article 24 also requires transparency in automated decision-making and gives individuals the right to an explanation and to refuse decisions made solely by automation where their rights are significantly affected. Conclusion: the system never pushes A to B on the owner's behalf. It only shows the owner themself "these two might match"; the introduction is done by the human, who obtains consent.

3. The case study: a team with system-level privileges took screen-reading collection to its limit

The three contradictions above may read like a paper exercise, but between December 2025 and October 2026 somebody already ran the control experiment with real devices, real money and real regulatory filings. For this project the conclusion is decisive: the hardest part of cross-platform automatic extraction is not the model and not OCR — it is that you do not own the entry point, and the owners have already said no in writing.

The timeline makes this clearer than any architecture debate:

The thing to remember in these numbers is the mismatch between capability and authorisation. Over 80% task success, chains of hundreds of steps, injection permission requiring a system private key, an on-device model filing, a public protocol with operation logs and a system security baseline, and the commercial resources of a hardware major plus a model major — none of those chips was missing, and the return was still 3 standard interfaces and 155 refusal statements. SAEP even designed four notably restrained safety mechanisms: apps may declare allow or deny at page level; a policy module decides using agent identity, the system security baseline and user authorisation state; restrictions are enforced by system capability gates rather than relying on agent self-discipline; and full logs record who, when, on which page, requested which operation, hit which policy and with what result. Technical, compliance and audit all in place — ecosystem authorisation still did not arrive. A third-party personal tool holds none of these chips and has no reason to assume it could do better.

Translated into technical obstacles for project one, the event is four independent walls:

One more point is easily missed yet directly sets the architectural boundary: refusing integration does not mean the app cannot be used. Several outlets made clear that the affected apps can still be downloaded, installed and used manually on the Doubao phone; only the assistant's automated screen reading and simulated taps are restricted. In other words, the user opening an app and using its own export and share functions to take data out has always been open, and has never been refused by anybody.

So "user-initiated export plus local merging" is not a second-best compromise; it is the only route the control experiment proved remains open. The Doubao case turned "can cross-platform intelligent collection be done" from an open hypothesis into a question with an answer, so the architecture below does not need to spend another 12 weeks walking into the same wall.

Sources: official Doubao phone assistant announcements and SAEP integration documents, compiled from CNR (2026-10-16), China Economic Net (2026-10-15), The Paper, Nanfang+, 21st Century Business Herald and CCIDNET reporting; verified 2026-11-05. The refusal list updates every Wednesday; the 151 / 153 / 155 / 166 figures quoted by different outlets reflect different cut-off times and counting rules, and the current official list is authoritative.

4. Product definition, and an explicit will-not-do list

One-sentence definition: a single-user, local-first tool for managing personal relationship assets. It imports scattered contact fragments into a device the user controls, deduplicates, merges, searches and flags supply-demand matches, with all plaintext never leaving the device.

The will-not-do list matters more than the feature list, because it decides whether the product oversteps:

Data inputs: vCard / CSV address book exports, local OCR of business cards, "export personal data" files from official platform backends, chat logs manually exported as text by the user, and the owner's own notes. All are user-initiated, traceable and reversible actions.

5. Compliance boundaries: clause by clause, not "it is only for me so it should be fine"

A common misconception is that private use is unregulated. China's PIPL has no household-affairs exemption in the GDPR sense; it regulates the processing activity itself. Fortunately several provisions are friendly to this project, and several red lines must be avoided.

Legal basis: the full text of the Personal Information Protection Law of the PRC (effective 2021-11-01), clauses verified 2026-11-05. This document is product design and engineering discussion, not legal advice; before a formal launch, conduct a personal information protection impact assessment (Articles 55, 56) and have a professional review it.

6. Technical architecture: five layers, all on the user's device

Why layer 4 insists on local: sending the names, companies and chat summaries of 3899 contacts to a cloud model for semantic matching is the easiest trap for this kind of product — nominally "AI-powered organisation", in substance handing the entire relationship graph to a third party. If external compute is genuinely needed, maintain a reversible pseudonym map locally, replace entities with meaningless tokens such as ENT_0001 before sending, and restore them locally on return; note also that this lowers leakage risk, it does not change the legal status of the information as personal information.

7. Encryption and masking: three layers, and masking is not anonymisation

Storage layer: whole-database encryption protects against device loss, field-level encryption protects against the whole database being readable once opened. Phone numbers, emails and notes each get independently derived keys, so revealing one record does not expose the others.

Display layer: masked by default (for example 138****6621); every click on "show full" writes a local audit entry with time and field. Warn against leaks via screenshots and the clipboard. This layer looks trivial but is the most common real-world leak — not a hacker breaking the database, but the owner taking a screenshot and posting it to a group.

Compute layer: search and matching run only in decrypted memory, and index files are encrypted too; temporary files and crash dumps are in the cleanup list. Externally, offer only single-record exports the user explicitly chooses, with an automatic masking option at export time.

One related distinction worth clearing up: de-identification is not anonymisation. Article 4 excludes information that has been anonymised, while data restorable through a pseudonym map remains subject to the law. Writing "we masked it, therefore no personal information is involved" in product documentation is planting a landmine for yourself.

8. Matchmaking: the real product value, and the place that needs the most restraint

There are two kinds of matchmaking, with completely different risks and approaches.

Warm matchmaking: the owner knows both sides. The system externalises memory — when the owner types "find someone who can volume-produce RK3588", local search returns 3 candidates, each with an evidence chain: which platform it came from, when you last spoke, and what was discussed. One glance tells the owner whether to make the introduction. A human can do this too, but it means scrolling through chat history on 5 platforms; the product value sits inside those 20 minutes.

Cold supply-demand: one party is unknown to the owner, for example a follower leaving a purchasing request in a comment. Here the system must step back: it records only the public comment as a lead (reasonable scope under Article 27), without enrichment, cross-linking or guessing other identities of that user, and without proactive contact. "Helping the owner find a stranger" and "contacting a stranger on the owner's behalf" are two different things; the second turns a notebook into an unauthorised information broker.

One more product principle: do not score relationships. Ranking people by "value" on a 1-5 star scale lets the tool shape the owner's social behaviour in return, and if the data leaks, the damage is not only to privacy but to the relationships themselves. The system records facts (when, where, what was discussed), not evaluations.

9. Competitor comparison: the difference is not features, it is data ownership

Comparison based on the public positioning of each product, verified 2026-11-05; excludes undisclosed features and commercial data.

The table makes one point: the market is not short of software that remembers people; it is short of one that still leaves the data entirely with you afterwards and can merge across sources. The moat is not AI, it is data ownership and restraint.

10. Business model: be clear up front that this is not a VC project

Single-user, invisible data, no network effects, no data monetisation — with those 4 true at once, the project has no data flywheel and cannot burn capital to buy scale. Forcing a SaaS growth story will eventually force a move to the cloud, and then the core promise gets lost.

The honest positioning is professional tool software: a one-off purchase desktop client (suggested 168-298 yuan), with optional end-to-end encrypted sync as a low-cost annual fee (suggested 68-98 yuan/year, ciphertext only, the server has no decryption capability) and no enterprise edition. Following the payment logic of comparable local-first tools: users pay for "not losing data when switching devices" and "spending less time organising", not for "more features".

The revenue ceiling is low, but so is the cost structure: no server clusters, no content moderation, no support ticket system, no heavy compliance-audit assets. It suits 1-2 people maintaining it long term, or an open-source core plus a paid desktop client. Putting "no fundraising" into the plan is not weakness, it is a guarantee that the product does not deform.

11. A 12-week MVP and the metrics that matter

The key metrics deliberately avoid growth measures such as DAU or retention and look at only 4: import coverage (what share of contact fragments made it into the database), merge confirmation rate (what share of candidates the human confirmed as the same person), successful introductions (how many times the owner actually made a match, marked manually by the owner) and false-merge incidents (target permanently 0). The fourth is a veto item; it matters more than the other three combined.

12. Risks and three hard stop lines

Summary

The real value of this idea is not "using AI to manage contacts" — that is the easiest and least valuable part. The value is turning relationship assets accumulated over a decade or more, locked inside 5 disconnected backends, back into something its owner can search, understand and take responsibility for. On this site, 3899 cross-platform followers are today just a scattered set of numbers; with local merging and evidence chains they become a usable graph.

And precisely because this asset is sensitive enough, restraint has to be written into the architecture: it does not log in for you, does not merge for you, does not introduce for you. Those three refusals define what it is better than any encryption parameter. For a tool used by one person, the hard part is not building it — it is resisting turning it into a platform.

The controlled experiment in chapter 3 leaves one more reminder: what a system private-key signature could not buy, do not expect a cleverer algorithm to buy. This asset returns to its owner not by gaining more entry points, but by removing the entry-point layer altogether.

Next: Project two · One-click adaptation and distribution: turning "could this get the account banned" into a number you can compute.

Postscript 2026-11-08: access controls in 2026 turned even standard interfaces into a review surface — model vendors now include third-party skill supply chains in their risk controls, and host policy decides whether an MCP server may be called. Local-first architecture with user-initiated imports is therefore more robust, but also harder to grow into an outside business: project four uses 5W1H to downgrade it to a self-use tool. See the 5W1H re-sequencing behind the access walls.