I think IPFS is a great technology, and the protocol appears to be fairly well designed but to be frank, I tried to use go-ipfs and it is a very junky implementation. There are numerous issues that show an overall lack of good quality standards in the codebase.
- Pin management is far to simple for any real use case.
- GC is a complete GC on an arbitrary threshold.
- API is based on the CLI and really weird (ex GET /api/v0/cp?arg={src}&arg={dest}, why don't the parameters have names? Why is it GET?)
- They don't prove a way to upload a directory with references to existing IPFS objects, so you need to manually encode the data.
- The manual encoding uses go-style names, they seem to have let their language choice leak into the protocol.
- Lots of minor issues, such as the API implementing block size limits by simply cutting off the input data at the size limit, this is even before encoding it into the format where the size limit should be calculated and cause data corruption in some cases.
- Their one abstract API for creating directories (MFS) has a number of issues.
- It is incredibly slow for some reason.
- It kindof but not really automatically pins all content recursively references.
There are other weird choicess such as their directory sharding using hashing. It isn't clear to me which use case this improves over a btree but someone probably thought it sounded cooler. Additionally the sharding appears to be a single layer of sharding which means that it still has a size limit (just larger).
I ended up sinking a ton of time into https://gitlab.com/kevincox/archlinux-ipfs-mirror/ and in the end the number of small quirks were incredibly frustrating. I might go back and implement their hash-sharding logic to get the mirror working again but at this point I don't really want to interact with go-ipfs again.
I thought it would be an interesting project to get involved in, and I have a lot of expertise that would be valuable however it appears that it is all a bit of a mess which is a real shame.
Maybe with more success it can be re-written in cleaner fashion, as I said most of the issues are with the implementation not the protocol so there is definitely hope. I do honestly wish all of the success to the project.
- Pin management is far to simple for any real use case.
- GC is a complete GC on an arbitrary threshold.
- API is based on the CLI and really weird (ex GET /api/v0/cp?arg={src}&arg={dest}, why don't the parameters have names? Why is it GET?)
- They don't prove a way to upload a directory with references to existing IPFS objects, so you need to manually encode the data.
- The manual encoding uses go-style names, they seem to have let their language choice leak into the protocol.
- Lots of minor issues, such as the API implementing block size limits by simply cutting off the input data at the size limit, this is even before encoding it into the format where the size limit should be calculated and cause data corruption in some cases.
- Their one abstract API for creating directories (MFS) has a number of issues.
There are other weird choicess such as their directory sharding using hashing. It isn't clear to me which use case this improves over a btree but someone probably thought it sounded cooler. Additionally the sharding appears to be a single layer of sharding which means that it still has a size limit (just larger).I ended up sinking a ton of time into https://gitlab.com/kevincox/archlinux-ipfs-mirror/ and in the end the number of small quirks were incredibly frustrating. I might go back and implement their hash-sharding logic to get the mirror working again but at this point I don't really want to interact with go-ipfs again.
I thought it would be an interesting project to get involved in, and I have a lot of expertise that would be valuable however it appears that it is all a bit of a mess which is a real shame.
Maybe with more success it can be re-written in cleaner fashion, as I said most of the issues are with the implementation not the protocol so there is definitely hope. I do honestly wish all of the success to the project.