Design Feedback

[chafey]

I am building an application using IPLD on top of IPFS and am currently using the IPFS DAG API. I am struggling to see the benefit of using the js-block API vs something like the IPFS DAG API. As an application developer, I have no current need to work with actual blocks at all - decoded objects and CIDs are all that I need (which is what IPFS DAG API provides). If I ever did need to work with blocks directly, a separate Block API (which IPFS also provides) would suffice. js-block seems more like a building block that a persistence service (like IPFS) would use in its implementation rather than something that an application developer would use.

[mikeal]

js-block seems more like a building block that a persistence service (like IPFS) would use in its implementation rather than something that an application developer would use.

This is mostly accurate. Block should be used either by a persistence service or by any application or library that wants to be persistence layer agnostic.

As we build out tools, new data structures, and all kinds of other libraries, it’s highly beneficial not to tightly couple those to a persistence service. If you’re building an application this separation of concerns is less important, you’re going to pick a distribution strategy for your application and it’s going to be tightly coupled to a persistence service. But if you’re building a library to be used by many applications, which is important as we work towards building out an ecosystem, it’s severely limiting to be locking into a specific persistence service.

[chafey]

Can you elaborate on what types of persistence services you are envisioning and how they might differ from each other from an API point of view? The only example we have right now is the IPFS block service and I am not sure why we need more than a simple get/put type interface to avoid the tight coupling you are referring to