“Cloud of thoughts”: how to build a memory of the user that brings people together and does not lose privacy
Briefly about the main thing (BLUF)
Remembering the user is a double-bottom task: connecting people with their thoughts is useful, but one leak kills trust in the product forever. We show how the layers of the “Cloud of Thoughts” are arranged, why fail-closed is more important than it seems, and which disclosure channels are stricter than others.
About the product itself - "Cloud of Thoughts" in NeuralSpace — we have already told you: the system collects what it knows about you and, by mutual consent, brings together those who have the same interests (“I’m looking for a 3D modeler” ↔ “I’m making 3D”). Here - about engineering side: How to prevent useful user memory from becoming a leak. This turned out to be more interesting than the feature itself.
Double bottom problem
I want two things at the same time, and they contradict each other:
- Rich profile. To bring people together, you need to know the facts: what he does, what he looks for, what he offers.
- Privacy by default. No one agreed that his correspondence would become public. Leak = loss of trust and violation of 152-FZ.
A naive implementation (“let’s collect everything and start a match”) breaks point 2 instantly. Good architecture is built around fail-closed: Closed by default, disclosed only by explicit consent, and verified at the code level, not a “we promise.”
Layers
1. Gathering facts. Two sources: structural facts (types of generation, activity - impersonal) and extraction from chat correspondence. The second is the most sensitive, so it is gated separate chat memory toggle switch at the user. Turned it off - extraction from correspondence does not occur at all. Important: this gate Not tied to a subscription to paid features - privacy should not be sold.
2. Categories are prohibited. System collection request excludes sensitive categories under 152-FZ (health, political and religious views, etc.) - they do not fall into the cloud, even if they come up in a conversation. This is not a post filter, but a rule during the extraction stage.
3. Double consent match. Two people have the same interests - system Not shows contacts automatically. She offers an introduction to both parties; the contact opens only when both agreed. This protects against the “my chat request popped up on a stranger along with my phone number” scenario.
4. Exception for explicit declarations. Subtle point. If a person himself, publicly, in a chat says “I’m selling a service, whoever needs it, write @nick” - asking consent a second time is absurd, he has already given it. Such publicly permitted contact is recognized separately and immediately disclosed to the interested party. The contact is recognized widely (telegram with and without @, phone in any format, links), but disclosure condition - precisely explicit public permission, and not just the presence of contact in the text.
Why fail-closed is more important than it seems
The temptation is to make protection with a “show/don’t show” flag at the interface level. This is false: any bug in UI logic = leak. We did it differently - facts for which there is no consent are not physically included in the profile at the stage of its assembly. No agreement - texts of requests and references in the letter and matching don't hit at all, and not “they get there, but we hide them.” The difference is fundamental: in the first case, a forgotten check = a leak, in the second - simply a lack of data.
The rule we would give to anyone building a system like this is: default - closed, disclosure - positive user action, verification - as close to the data source as possible, not to the screen.
Disclosure channels - of varying severity
- In chat, at the request of the user himself - impersonal facts and already public leads are more easily accessible: the person himself asked.
- Proactive mail (the system itself writes “there is a match”) - stricter, only by subscription and double consent.
The logic is simple: the less the user expects disclosure, the higher the bar for consent.
Bottom line
The most difficult thing here is not machine learning, but data flow discipline. If you are making recommendations or matching on user data, it is interesting to discuss where you place the consent check. You can see what the system knows about you in the section privacy.
Frequently asked questions (FAQ)
Question: How to get the best result from a neural network?
Answer: Use detailed prompts (descriptions) in English, set the style and details of the scene.
Question: Can these materials be used for commercial purposes?
Answer: Yes, the generated content is entirely yours.