Evaluation of the IPFS paper #5
Conversation
evaluations/ipfs.md
Outdated
| - Object pinning (§3.5.3) inevitably leads to centralized gateways to IPFS, such | ||
| as Infura and Pinata | ||
| - There are no self-describing multiformats for encryption and signing (§3.5.5) | ||
| - IPFS uses variable size blocks instead of fixed-size chunks (§3.6) |
There was a problem hiding this comment.
I don't think this is a hard imposition, CIDs can be anything and lengths can be anything as well.
There was a problem hiding this comment.
No indeed, none of these are hard impositions. Just that fixed-size chunks might make a marketplace and incentives mechanism a bit simpler.
| as Infura and Pinata | ||
| - There are no self-describing multiformats for encryption and signing (§3.5.5) | ||
| - IPFS uses variable size blocks instead of fixed-size chunks (§3.6) | ||
| - Supporting version control directly in IPFS feels like an unnecessary |
There was a problem hiding this comment.
Not sure what you mean by this, any content address store implicitly supports some level of version control, because event slightly different content will produce completely different identifiers?
There was a problem hiding this comment.
In paragraph 3.6 they describe a model that is very close to Git, including things like commits. I don't think that this is a necessary component of a decentralized storage protocol, but could better be built on top of it.
For discussion, see: #5
|
@dryajov, I updated the evaluation based on your comments, what do you think? |
There is a description of the key that is used for signatures in SignedObject, and its questionable whether you should want the encryption scheme to be publicly available for EncryptedObject
No description provided.