 HackMDWhat if every w3s space gets it's own PeerID?
When a user wants their stuff to be available over ipni+bitswap (aka ipfs) their client creates a new key pair for that space.
The user (not us!) can then create and signs the ipni advert saying "these blocks are available from hoverboard + <this new random peerid>" and sends us the adverts to send on to cid.contact.
We store the ads in their space 'natch, billable, noice. We store the mapping of space to peerid key (new but trivial).
So now results for IPNI queries for a users blocks will come back with a multiaddr for hoverboard+per space peer id.
On bitswap/libp2p read, the public peerid is sent as the request path, and hoverboard will go look up the secret key to use for that request. It finds it and away we go… We also just got back some data locality as we know we're only gonna be looking at cars for the space associated with the peerid. AND WE CAN NOW ASSIGN ALL BITSWAP TRAFFIC COSTS TO A SPACE if we want to or whatever I'm not excited you are.
Go further and we can store a key pair per car, and then we know the car from the peer id! But maybe that be madness.
This fixes issues with this proposal (https://github.com/web3-storage/specs/pull/85) (and our current IPNI) stack
- we can now avoid having 1 single mega long advert chain for the fire-hose of all uploads, where a single mega uploader slows down our ipni advert publishing becuase the they are linked list so we cannot parallelise their creation! if we have an ad chain per space we fix that!
- we dont have to sign adverts on behalf of users. They can sign their own damn adverts. (and index their own cars etc https://github.com/web3-storage/RFC/pull/9)
Maybe we can apply this to trustless gatway CAR requests too, as we now advertise that endpoint over IPNI too, but it would be best effort as the PeerID there is just for show rather than authenticating the session, but still it might be a hint that we require clients to provide.
