What is this?
For areas where we have heard multiple complaints of “X should be better for my usecase” and where we want to encourage developers to solve it their own way but they seem stuck waiting on us to fix the problem, we demonstrate some examples to pave the way forward.
We expect this to be more of a reactive workstream. Rather than type out a github or slack response yet again to an issue before, we may make the judgement call to take the 2-5 day hit to create an example that we can then link to in the future.
Why is this a good idea?
We have some evidence from working with developers that despite the flexibility we enable in our stack at the specification and network layers, that we still get “is it in kubo, and if not when will it be” kinds of questions.
One way to approach this problem is to build some simple example solutions to common problems and tell people about them. For example, despite the lack of serious support for the pnet libp2p component, some blog posts across the web showing how to configure kubo with pnet to get some level of privacy have helped make the practice somewhat common.
It also has a useful side effects such as:
- Forcing dog-fooding of maintained libraries (code, documentation, etc.) and protocols (flexibility)
- Giving a useful creativity entry point/outlet for people
- Freeing up time from user-support / devrel as gives a tangible entry point. (We have already linked to the couple of examples we have multiple times)
What we need to do
- Implement (and publicize) some commonly requested features that are difficult for kubo but are straightforward in a more specific implementation such as:
- Implement (and publicize) minimal examples of areas of the stack where we want people to explore more
- Data transfer protocols optimized for specific use cases:
- Easy (and inexpensive) onboarding of incrementally verifiable file data with webseeds-like data transfer
- Interoperate with some existing system that uses content addressing or hashes already
- Take one of Arweave, BitTorrent, Git and demonstrate how IPFS tooling can be used in a complementary (rather than competitive A vs B) way.