If our database were stolen tomorrow, by an attacker or a rogue employee, the community data inside would be unreadable.
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.
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 encryption key. Each one is an isolated island. Decrypting community A's data tells an attacker nothing about community B.
Your account is an island too. When you register you get a key of your own, separate from every community, and it protects your account email.
Each key is stored locked and can only be unlocked inside a managed vault.
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 forum posts, wiki pages, library descriptions and the name and contact details you show inside a community are stored as individually encrypted bytes under that community's key. Your account email sits under your own key instead. To read a single post, the application asks the vault to unlock the right key.
If someone dumps our database, they get 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 search on hashes. When you write something, the system hashes your text in small pieces. When you search, it hashes your query the same way. The database matches the hashes, while the text itself stays encrypted. We only decrypt the exact hits for your screen.
Email lookups use the same idea with a different key. Alongside your encrypted email we keep a hash made with a single platform-wide secret. That hash lets the login flow find your account and confirm it's you, without touching the stored email. That one is decrypted separately, on every signed-in request and whenever we send you mail. The shared secret can compare hashes, but it cannot reverse one back into your email or decrypt any community's 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, its key is destroyed with it. When you close your account, your own key goes the same way, and your email with it. Once a key is gone, whatever it protected 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.
We could read it, and don't
Most privacy pages skip this part. Pinitto is not end-to-end encrypted. The application must decrypt content to render your pages, which means we, who operate it, technically hold that ability too.
We run no analytics and build no profiles. Nothing at Pinitto makes money from reading your content, so nothing pulls us towards it.
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.