I have noticed that there are quite a lot of similar topics where people want to integrate external systems which make sense to be combined with IPFS. Because of the monolith design of go-ipfs it needs to be authorized and approved since it will be included in the core one way or another. And that’s understandable but…
What if we create a portable modular kit based on go-ipfs where everyone can create a fork and integrate easily without affecting the core? That way we would have custom user versions with different sets of services exposed and it will make the whole ecosystem more open.
In my case I currently need an integration of orbit-db so that I can call it directly from the shell because my client app is in Web Assembly and so it doesn’t have access to the host OS resources that orbit needs to establish the connection.
Here is an issue created where we can talk about it further:
opened 09:58AM - 23 Feb 22 UTC
open problem statement
<!-- Instructions: (duplicated here for convenience)
## Creating the open probl… em statement
The purpose of the open problem statement is twofold. Firstly, it should convince the reader that the problem you are presenting is worth working on. Secondly, it should provide enough background and understanding of the problem that all design decisions and requirements are comprehensively described and motivated. Feel free to deviate from the following template if you prefer, or answer the following questions as succinctly as possible for an easy open problem statement.
While this template was made to support the RFP program, the open problem statements themselves are purely for the benefit of the community, and there is no obligation to make or request an RFP for each open problem.
** Open Problem Template **
-->
# Create open, modular and extendable boilerplate kit from go-ipfs monolith
## Description
At present go-ipfs is a single monolithic binary and any attempts to make it more modular end up as new APIs rather than a full revision of the architecture. This prevents the exploration of new use cases such as using IPFS as a decentralized backend with plug and play support for custom components that serves self-contained WASM client apps in the browser.
Example: a wasm app can not access the host OS resources. Because of this we need to call the go-ipfs-http-client to gain access to the local IPFS node but if we want to use orbit-db or any other custom p2p component we don't have IPFS integration for it and we can't use it directly from the client app.
With so many great projects being developed in the IPFS ecosystem what we are missing is interoperability and deeper integration between them.
## State of the Art
This survey on the State of the Art does not have to be exhaustive but it should provide a good entry point to existing work on the topic. Later contributors can augment the survey via PR.
### Current approaches within the _PROJECT_ Ecosystem
> Existing attempts and strategies to solve the problem within the context of the relevant PL project
A good example of existing services that are exposed:
https://github.com/ipfs/go-ipfs-api
https://github.com/ipfs/go-ipfs-http-client
While both APIs do well at exposing existing functionality they are not aiming at opening up the stack for custom component integrations. The single binary architecture prevents that in the first place.
### Current approaches within the broader research ecosystem
> How do people try to solve this problem more generally?
There are various companies across the Protocol Labs Network that are working on creating application platforms(PaaS) on top of IPFS - such as Fission, Fleek and Pinata to name a few.
### Known shortcomings of existing solutions
> What are the limitations of current solutions within the project ecosystem and elsewhere?
The existing solutions are creating their own specs and build their own stacks on top of IPFS rather than being interoperable integrated parts of the ecosystem.
## Solving this Open Problem
### Estimated impact
> How would we and/or the world benefit from solving this problem?
We would be able to cover new use cases such as - IPFS as a plug and play service system, 3rd party integrations, IPFS as a backend, IPFS as a platform.
### Proposed solution definition
> What defines a complete solution? What hard constraints should it obey? Are there additional "soft" constraints that a solution would ideally obey?
A completely decoupled system either as native multi-binaries or microservices on top of a local cluster based on CQRS pattern with event sourcing which will enable features such as - global app state, events replay, real-time auditing and history logs, 3rd party integrations, adding custom functionality as microservices on top of the core IPFS functionality.
This will lead to many custom versions of the boilerplate kit which expose a different set of services covering various use cases.
Ideally all existing domains should be extracted to separate binaries/microservices and implemented on top of an existing open source boilerplate kit such as: https://github.com/vardius/go-api-boilerplate
## Supplementary Material
### Existing conversations/threads
> Link to prior discussions relevant to the problem
https://discuss.ipfs.tech/t/proof-of-concept-interplanetary-service-system/10245
https://discuss.ipfs.tech/t/a-preliminary-discussion-of-the-workswap-protocol/12320
### Extra notes
> anything else deemed relevant to the problem
Areas which are not covered in depth yet are: combining of open source licenses and the network layer abstraction in case the kit is based on a local cluster.
The idea is not related to the existing ipfs cluster because it's about turning IPFS itself in a cluster of its own microservices rather than a cluster of peers.
1 Like