Skip to content

Latest commit

 

History

History
182 lines (127 loc) · 7.95 KB

pubsub.md

File metadata and controls

182 lines (127 loc) · 7.95 KB

PubSub enabled by default

Authors:

  • @gozala

Initial PR: #53

Purpose & impact

Background & intent

Describe the desired state of the world after this project? Why does that matter?

As of this writing pubsub is considered experimental and is disabled in go-ipfs.

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 uses pubsub to publish thread updates among it's participants.
  • 3Box uses pubsub for 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 making it more 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.
  • Improves pubsub reliability by adding more enabled nodes to the network.
  • Enables development of new features that require pubsub.

Confidence

How sure are we that this impact would be realized? Label from this scale.

Level 3

  • We know teams building products that depend pubsub.
  • Features like IPNS over pubsub depends on this.

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.
  • 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) 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)
  • SMTP support in IPFS nodes (you can email any node by email address)

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-ipfs contributor
  • someone from infra to help estimate impact