If our entire database were stolen tomorrow (by an attacker, a rogue employee or a foreign court order), the community data inside would be unreadable.
Not "slow to read". Not "encrypted with a key stored right next to it". Just unreadable.
That is the technical goal. Here is how we enforce it.
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 absolutely nothing useful.
One community, one vault
Every community on Pinitto gets its own distinct encryption key. We do not use a master key to lock everyone's doors.
Each key lives in a secure vault that is audited every single time it opens. This means every community is an isolated island. Decrypting community A's data tells an attacker absolutely nothing about community B.
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 actively fetch the specific community's key from the vault.
If someone dumps our database, all they get is a massive pile of opaque blobs.
How you search in the dark
If everything is encrypted, how do you search for a neighbor'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.
This isn't a compliance checkbox; it's a hard operational constraint we gladly accept. The infrastructure falls strictly under the EU's GDPR and German federal data protection laws. We apply this exact standard to every Pinitto user, regardless of where they live in the world.
We do not transfer community data across borders, and we don't feed it into third-party analytics pipelines in other jurisdictions.
Deletion means deleting the key
When a community is deleted or you close your account, its encryption key is destroyed with it. We don't crawl the database hunting down every encrypted field. Once the key is gone, whatever data remains is unreadable, to an attacker and to us. It goes back to being the pile of opaque blobs we started with.
That is also how the right to erasure works here. The platform loses the ability to read your content the moment the key is gone.
We can't read your stuff either
Field-level encryption isn't just a shield against outside hackers. It is a self-imposed blindfold for us.
We, who build Pinitto, cannot casually browse your community's content. Reading the wiki of an apartment building or the borrowable items of a co-living space requires the community's specific key, fetched through audited requests.
If you are organizing a community and handling sensitive information (names, addresses, daily schedules, family dynamics), do not trust marketing claims. Trust technical constraints.
These are ours.