Peer Cloud

Peer Cloud is used to distribute static resources.

Resource Request

The most basic request takes a hash and returns the resource that matches it.

Partials

This is meant for efficiently distributing larger files or breaking up the sharing. A resource map can be requested which will break the resource up into 10k chunks and produce a Merkle tree. Individual chunks can then be requested.

Resource Pointers

A resource pointer allows for a resource to be referenced that has not yet been defined.

A resource pointer is built around a keypair. The PKHID is used as the pointer. To resolve the pointer, a record is created with the full public key, and the hash of the resource being pointed to signed with the corresponding private key.

In earlier versions, the plan was to allow resource pointers to be re-pointed. But I believe I'm going to say that they cannot.

Burn Notice

A resource can include meta-data. Meta-data can include a burn PKHID. That can be used to issue a burn notice which will cause the recipient (if they are following the rules) to remove that resource from their cache. The idea here is less about resource control (because that's a joke) and more about storage management. If Alice sends Bob and email, once Bob has received it, he can issue a burn notice. That can be broadcast somewhere Alice's friends are likely to hear, and eventually it can be sent back to Alice. This lets Alice's friends clear the message from their cache sooner than letting it expire.

Privacy

There are some significant privacy challenges here. Peer Cloud can't just fulfill requests blindly.

Alice and Bob are friends but they don't want Eve to know. Eve suspects this and want to confirm it. Eve gets Alice to send her an email Eve is not online and Bob is. If Bob has a copy of that email, Even can now conclude they are friends. Rather than requesting a copy of the email through a public channel (which would provide Bob with anonymity), Eve directly sends a request for the email.

I believe this is going to take several iterations of improvement to really get it working. For starters each resource can be tagged for transmission. Any resource can be sent anonymously. Only resources appropriately tagged can be sent directly. Any application wishing to access Peer Cloud needs to indicate whether the request is anonymous.

Another fix to help this is that when Bob gets a resource, there should be some probability that he passes it along to someone else.

Cache Exchange

I've only started to think about this, and I don't know how "solvable" it is.

Peers should be able to exchange promises of caching. Ideally, this means Alice and Bob can send each other data and they will hold on to it for some time (until it expires, is burned or is the least-accessed in cache). But it is very hard to say what this promise means. The promise is between Alice and Bob, but they both have many devices. Also, Eve could abuse the system, over-using the caches extended to her while not caching anything herself. It doesn't need to be perfect, but there should be a way to catch Eve if she's too blatent in this.