Camlistore is a simple secure datastructure, but it uses signatures in a way that exposes it to implicit trust. camlistore uses one way hashes to link json objects to make immutable datastructures, this is completely fine. But camlistore also uses signatures to make mutable datastructures, but this isn't done in a completely safe way.
To make a mutable datastructure a camlistore user creates a permanode this is just a json object with some entropy in it, and a pointer to the owner (the key who will sign updates). Then, the permanode owner can create claims (which are just signed json objects, that point back at the permanode) with which add or remove attributes from the permanode (things like set a key, or remove a key, add tags, or add something to a set)
Since claims are signed, it's infeasible for an attacker to forge a claim. However, since there is no way to know whether you posses the entire set of claims for that permanode it's entirely possible for a Man In The Middle to manipulate the meaning of the permanode by "forgetting" certain claims. If the owner makes a claim that some key is X, but then another claiming another key is Y, and an attacker could benefit from Y but not X, then that attacker could replicate the claim with Y but not X. Although attackers cannot feasibly forge claims, they can leave claims out.
This problem can be partially resolved by linking the claims into a chain, so that each claim points to the previous claim (ordering claims per owner). Now, if a MITM drops an old claim, that will be detected. However, it's still possible for it drop a new claim.
Nodes can never be sure if they have the latest claims, but they can be sure about what they do have. The best way to avoid this is to replicate through multilpe paths - via a gossip protocol. As long as some honest nodes have the new claim, then they will pass it on one way or another. A MITM cannot fool another node unless it controls all the communication paths to that node.
I have been building that kv thing (although it's actually a path -> value thing, and you can also link into other people's paths - enough to build a package manager)
I think there are some situations where we actually want the truncate attack. Say someone is harassing me, and I want to block them. I could ask my friends not to relay my information to them, and they would shun that node, pretending that I have just stopped publishing messages. This is essentially a coordinated truncate attack, performed by honest node against a malicious node.
I think it's being able to block a harasser is more important than being able to guarantee freshness.