The minimal possible cooperative group is two people: Alice and Bob. One day Alice needs some tea, and Bob has some so sends it over. Another day it is the other way around: Bob needs a hat, and Alice has one spare. Now Alice has to decide: whether to send the hat to Bob or not. That decision is the crux of the cooperation. And it can be straightforward: Alice keeps a record of all interactions with Bob, and checks it. In the past Bob has helped with some tea, therefore helping Bob with a hat now is sensible. Bob also keeps such a record and can decide similarly. So we have a successfully running cooperative group.
But there is one main possible security failure. An unknown third person, C, impersonates Bob in asking for a hat. Then the record of Bob's interactions is misapplied: C is taking advantage of Bob's good record. So the problem is this: to ensure the identity of participants: when someone interacts with you, you want to be sure they are the same as the person in your records.
Identity seems a rather ordinary, well-understood security concern (though not necessarily easy), and not something new and special to this kind of cooperative system. So we can feel calm about that: it seems do-able and not demanding anything of the basic design.
The next question is how this generalises to groups of more than two. It roughly seems to do so straightforwardly, but that is not yet clarifed. (It seems basically the same structure, but with each interaction being ‘on behalf of’ the rest of the group.)
... Taking a bit of a jump, the generalised solution to the ‘cooperation decision’ seems like the following. How to decide whether to give to someone else? Try to find paths across the network of previous interactions, where each step receives something from that other person's direction – i.e. they give to Y, Y gives X, X gives to you (not the same object, just that flow of giving). Inspecting the network shows the other person has contributed to the group, and hence also you, and so are a good choice to give to.
If someone set up a million fake bots all interacting with each other, might that not create a false appearance of cooperative good-will? But if they never actually give anything to the rest of the group they will never create any paths to anyone else, and so no-one else will trust them. Their isolated interactions count for nothing. And if they do give to others, they are actually being cooperative. This is the key point: cooperation is inherently verified by others.
That seems to offer some reassurance about the basic security concerns.
Now there is another question of privacy. One might say economic interaction is essentially public – by definition you cannot keep an interaction to yourself. But we can still consider degrees of interaction. Interactions are not all with everyone, and we might deliberately want some to be strictly limited, within sub-groups. But we should be inclined to leave this for later – it seems non-critical, and also separable.
Both Bitcoin and Ripple are highly concerned about consensus (a very centralised idea). Yet this network-based/non-currency system seems to be missing that. Is that a fault?
No, because the essential problem is not about currency but about cooperative structure/behaviour, and cooperation is intrinsically distributed and does not require consensus. Bitcoin (etc.) is working too hard, or rather is too focused on the wrong main problem: it is primarily trying to simulate material objects – their objective limitedness. That is money's mechanism. But that mechanism is accidental, or only peripheral. The real main purpose is to make a system for cooperation, and the mechanism there is about sharing, communicating, storing the non-rival good of information.