diff --git a/proposals/pubsub.md b/proposals/pubsub.md new file mode 100644 index 00000000..56415201 --- /dev/null +++ b/proposals/pubsub.md @@ -0,0 +1,182 @@ +# PubSub enabled by default + +Authors: +- @gozala + +Initial PR: https://github.com/protocol/web3-dev-team/pull/53 + + + + + + + +## Purpose & impact +#### Background & intent +_Describe the desired state of the world after this project? Why does that matter?_ + + +As of this writing [pubsub][IPFS pubsub] is considered experimental and is disabled in go-ipfs (due to increased resource usage on nodes that do not make use of it). + +> Can be enabled by starting a daemon with `--enable-pubsub-experiment` flag + +In practice however many teams building products on IPFS use and depend on pubsub: + +- Textile nodes have pubsub enabled. +- Ceramic uses pubsub for queries and log replication. +- [OrbitDB][] depends on pubsub to do replication. +- Fission team would like to use pubsub (has user requests, but found it unreliable) + +It also fragments network by (JS) nodes having it enabled and nodes that do not making IPNS unrelaible. + +> IPFS in browsers use IPNS over pubsub (no DHT for browsers) while other nodes do it over DHT. + +Enabling PubSub would populate network with more nodes, which might make specific popular topics more resilient / reliable. + + + +#### Assumptions & hypotheses +_What must be true for this project to matter?_ + + +- Teams building products need pubsub. +- Disabled pubsub makes an ecosystem more complex. +- Building (near) real-time application on IPFS requires pubsub. + +#### User workflow example +_How would a developer or user use this new capability?_ + + +They would just be able to use `pubsub` without `--enable-pubsub-experiment` flag. Feature becomes usable to ipfs-client's that use IPFS HTTP API. + +> **From Fission**: +> +> If we expect apps to be independent and run on the IPFS network -- like they do with HTTP servers -- then whatever else can be made available natively can be powerful building blocks +> +> Having more capabilities available out of the box for developers is a better reason to build and host on IPFS natively. Pubsub out of the box gives a host of real time and messaging opportunities that our customers would love to use. + +#### Impact +_How would this directly contribute to web3 dev stack product-market fit?_ + + + +- PubSub becomes more reliable with more nodes on the network. +- Bulding (near) real-time products becomes easier, IPFS nodes are suitable out of the box. + +#### Leverage +_How much would nailing this project improve our knowledge and ability to execute future projects?_ + + + +- Improves velocity of teams building products requiring pubsub by removing additional burden. +- Enables development of new features that require pubsub. + +#### Confidence +_How sure are we that this impact would be realized? Label from [this scale](https://medium.com/@nimay/inside-product-introduction-to-feature-priority-using-ice-impact-confidence-ease-and-gist-5180434e5b15)_. + + + +Level 3 + +- We know teams building products that depend pubsub. +- Features like IPNS over pubsub depends on this. +- [ENS users complain about IPNS on `eth.link` gateway being slow](https://discuss.ens.domains/t/eth-link-fails-through-gateway-but-ipns-hash-works-fine/375/6?u=lidel) + + +## Project definition +#### Brief plan of attack + + + +- Measure what is the overhead on nodes that do not directly use pubsub +- If overhead is neglegable ship a release of go-ipfs with pubsub enabled (see [ipfs/go-ipfs#6621][]) +- Enable / upgrade IPFS nodes operated by PL. +- Measure overhead & reliability on node operated by PL. +- Raise awareness (blog, tweet, support community transition) + +#### What does done look like? +_What specific deliverables should completed to consider this project done?_ + +- Shipped release of go-ipfs with pubsub enabled +- Increased number of pubsub enabled IPFS nodes in the network. + +#### What does success look like? +_Success means impact. How will we know we did the right thing?_ + +- Various projects (like OrbitDB, [Forest](https://github.com/forestpm/forest)) no longer have to explain with instructions how to enable pubsub. +- Teams like fission deliver pubsub to their users requesting it. +- Pubsub becomes more reliable due to increased number of enabled nodes. + + + + +#### Counterpoints & pre-mortem +_Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_ + +- Everyone enables pubsub already anyway. +- Pusub prooves (more) unreliable even with increased number of enabled nodes. + +#### Alternatives +_How might this project’s intent be realized in other ways (other than this project proposal)? What other potential solutions can address the same need ?_ + +- Alternative messaging primitives (e.g. Federated SSB like pubs) + +#### Dependencies/prerequisites + + +- none + +#### Future opportunities + + +- Improving IPNS (through IPNS over pubsub) +- DNS Service Discovery (DNS-SD) but over the global IPFS network through PubSub. + +## Required resources + +#### Effort estimate + + +- Small to Medium + +> I am not really qualified to answer this question. If we find overhead reasonable, enabling it should be metter of switching defaults. + +#### Roles / skills needed + + +- go-libp2p contributor (or go-ipfs contributor with some guidance) +- someone from infra to help estimate impact + +[IPFS pubsub]:https://docs.libp2p.io/concepts/publish-subscribe/ +[OrbitDB]:https://github.com/orbitdb/orbit-db +[ipfs/go-ipfs#6621]:https://github.com/ipfs/go-ipfs/issues/6621 +[SMTP]:https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol