If our entire database were stolen tomorrow, by an attacker or a rogue employee, the community data inside would be unreadable.
That is the technical goal. Here is how we enforce it, and where it ends.
Who we are actually defending against
Security claims mean nothing without a threat model. The realistic threats to a building's shared data are not intelligence agencies. They are a stolen database dump, a curious insider with database access and an ex-resident who kept a way in.
Everything below is sized to those threats. At the end, we list the limits, because they matter just as much.
Assuming the breach
Most platforms measure security by the strength of their walls. They talk about firewalls, access controls and perimeter audits. That's useful, but it assumes the wall holds. We assume it won't.
Pinitto's architecture starts with a different question. What happens after a successful breach?
The answer has to be nothing useful.
One community, one key
Every community on Pinitto gets its own distinct encryption key. Every community is an isolated island. Decrypting community A's data tells an attacker nothing about community B.
Each key is stored locked and can only be unlocked inside a managed vault. Every unlock is logged by our infrastructure provider. Not by us, by them. That distinction does real work below.
Encrypting the data, not just the hard drive
Disk encryption is the usual baseline. It protects data when a server is unplugged. But the second the database is running and queried by the application, the data sits there in cleartext.
Pinitto uses field-level encryption. Your name, email, phone number, forum posts, wiki pages and library item descriptions are stored as individually encrypted bytes. To read a single post, the application must ask the vault to unlock that community's key.
If someone dumps our database, they get a pile of unreadable bytes.
How you search in the dark
If everything is encrypted, how do you search for a neighbour's drill? You can't search inside encrypted text directly. That defeats the encryption.
Instead, we use hashed trigram indexes. When you write a post, the system hashes three-letter chunks of your text. When you search, it hashes your query. The database matches the hashes, while the actual text stays entirely encrypted. We only decrypt the exact hits for your screen.
Email lookups work the same way. We use a single, platform-wide secret to hash emails. This allows our login flow to verify it's you without ever seeing your cleartext email address. That shared secret can compare hashes, but it cannot reverse them back into your email or decrypt your community content. It is not an encryption key.
Physical borders matter
All Pinitto data is processed and stored on servers in Germany.
We picked this constraint on purpose. The infrastructure falls under the EU's GDPR and German federal data protection laws. We apply this standard to every Pinitto user, regardless of where they live in the world.
We do not transfer community data outside Germany, and we don't feed it into third-party analytics.
Deletion means deleting the key
When a community is deleted or you close your account, its encryption key is destroyed with it. Once the key is gone, whatever data remains goes back to being unreadable bytes.
That is also how the right to erasure works here. Backups hold the same unreadable bytes and age out on a fixed schedule. Once they do, the erasure is complete everywhere.
Reading your data leaves a trace
Here is the part most privacy pages skip. Pinitto is not end-to-end encrypted. The application must decrypt content to render your pages and run your searches, which means we, who operate it, technically hold that ability too.
The reason we don't is the one that matters. We run no analytics and build no profiles. Nothing at Pinitto makes money from reading your content, so nothing pulls us towards it.
And we could not do it secretly even if we wanted to. Reading anything means asking the vault to unlock that community's key, and every request is logged by the infrastructure provider, not by us. We cannot casually browse an apartment building's wiki, and we cannot quietly decide to peek. Access happens through the front door or not at all.
What this does not protect against
A valid court order can compel us to decrypt data, as it can compel any company that is not end-to-end encrypted. What we could hand over is bounded by how little we collect.
A compromised or unlocked phone sees exactly what you see.
Other members can screenshot what they can already read. Invitation-only membership keeps that circle small and accountable, not infallible.
If you are organising a community and handling sensitive information (names, addresses, daily schedules, family dynamics), do not trust marketing claims. Trust technical constraints, stated together with their limits.
These are ours.