Irakli Gozalishvili

One extra thought that would go along with a general sentiment here: - Each node already has a peer ID backed by PKI. - Devices have unique IPFS nodes (two...

I think there is yet another reason to prefer device level granularity over user level. When you query for all user pins it would be useful to: 1. To query...

I have spend little more time thinking about this and I came to following conclusions that I would like get feedback on: There are two very different user groups that...

> * Most likely means DAG import will be also limited to a single file upload Can we left this requirement ? We are already running into issues in cloudless...

> To keep things easy for everyone (users, services) import+pin operation should be atomic. > > * Request is `multipart/form-data` (follow behavior of existing import endpoints) > What the rational...

> 2\. How to handle incomplete graphs? What is the intention of the Pinning API if it can't resolve all links of a DAG for a given CID? It's entirely...

> 3\. How to handle unknown codecs that can't be traversed for the purpose of figuring out the entire graph. Say I upload a graph encoded entirely with dag-cose blocks...

> I think so too. Is there an easy way to tell that CAR has more than one root, before ingesting entire thing? Ideally, service would fail fast with info...

Here is my general feedback consolidated together: 1. Please lets not try to be future proof and try and generalize API too much. In practice those are harder to work...

> * Write the blocks in this CAR file to your Blockstore. > * Pin the root. > * Return when the pin is available This is exactly what I...