I actually get that question right away when I talk about our project to build something that is less subject to the vagaries of laws and regulations. Apparently the people who ask only create maximum guaranteed secure infrastructure and use software that cannot be unsafe…
You know, those people send you a WhatsApp message (Meta) about what they have done and it is then posted on Facebook and Instagram. Or even nicer, when they tell you that they don’t suffer from censorship because they vent on LinkedIn (Microsoft).
There also appear to be many people who believe that if it is “Open Source”, then it is good. They then post their code on GitHub (Microsoft). The fact that “their” code can then be used worldwide by the community that also writes code is great. And commercially interested people like Microsoft don’t look at this, right?
But now about IPFS… For the project Abundomy / 1coinh I have everything IPFS converted. And to strengthen the “swarm” of IPFS nodes you can add more nodes that are part of this swarm. (By default, IPFS will select about 20 nodes to set up “hashes” so that the files can always be rebuilt when someone requests the files.) And yes, not without reason, this question came up and I immediately had the impression that it was an answer from an AI chat:
“Using IPFS for sensitive information poses substantial privacy risks, as all traffic and content are public unless encrypted, making it easy for third parties to monitor and access data. Additionally, once content is published on IPFS, it becomes accessible to anyone, which can lead to potential misuse or exposure of sensitive data.” Is the system you use encrypted?
Honesty gives this answer (which is hocus-pocus for most…):
Can data be manipulated?
OrbitDB entries are cryptographically signed. Every write to the database is signed with the writer’s private key. Someone who tries to insert a fake transaction without that key will be rejected by the network — the signature is incorrect.
| Attack vector | Possible? | Why |
|---|---|---|
| Adjust IPFS block | ❌ No | CID = hash of content, immutable |
| Forging OrbitDB entry | ❌ No | Requires the private signing key |
| Change existing transaction | ❌ No | Immutable log — OrbitDB works as append-only |
| Inject fake transaction | ❌ No (unless key stolen) | Signature verification at network level |
What are the possible risks?
VPS compromise
The relay (12D3KooWAdaFx…) and the API (https://167-233-171-25.sslip.io) both run on the VPS. If the VPS is compromised: relay drops (app cannot connect), but the OrbitDB data itself remains cryptographically intact — no one can inject fake transactions with stolen access to the VPS without the application’s signing key.
Private signing key
The only way to insert false transactions is via the private key that the app uses to sign entries. If that key ever leaks (e.g. hardcoded into the app bundle at IPFS), that is the critical risk.
relay.json is publicly readable
This is done on purpose — peers need to know the relay and store addresses. No problem. But it does reveal the relay’s VPS IP and libp2p PeerID, making targeted scanning easier. But that is a decision we had to make because Abundomy is based on openness, and hopefully therefore also trust.
IPNS pointer on the app
The abundance app IPNS key on the VPS points to the current app CID. If that key is stolen, an attacker can publish another relay.json pointing to a malicious relay — connecting users’ apps to a fake environment.
Conclusion
The content is cannot be manipulated. The transactions are cryptographically protected via OrbitDB signing. The system is architecturally sound as far as the IPFS layer is concerned. The vulnerabilities are in classic security areas: VPS access, management of the signing key, and the IPNS key for the app. These are already covered by the VPS hardening that has been set up.