13. Even the raw blobs need a ticket
Your blocks are paired with a block access token, a secret from which a node signs each request (time-limited, naming the block, tied to the node's key, not lendable); one token per chunk, inline and mirror kinds; a node that fetched a block with a valid token can serve it on under the same token.

13. Even the raw blobs need a ticket

Your blocks are paired with a block access token, a secret from which a node signs each request (time-limited, naming the block, tied to the node's key, not lendable); one token per chunk, inline and mirror kinds; a node that fetched a block with a valid token can serve it on under the same token.

It closes the gap between "encrypted" and "unobservable".

On plain IPFS, anyone who knows a hash can fetch the block. Ciphertext is still a leak. Sizes, and which blocks go together.

Peergos pairs your blocks with a block access token. No valid token, no block. A node that fetched a block with a valid token can serve it on, and enforces the same token.

The token is a secret. From it, your node signs each request. Time limited, naming the block, tied to your node's key. That signed request cannot be lent. A ticket with your name on it.

Every five mebibyte chunk has its own token. So the server still cannot tell which blobs make one file.

Two kinds. An inline token, for one block. A mirror token, for a whole user, so another server can copy everything you own.

Check yourself. What cannot be lent: the token, or the request signed with it?

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime

Comments