What is the relationship between XMTP and Waku?

On 1/20/22, @galligan wrote:

As we get closer to launching our SDK, it's important that we're all on the same page both in the details and the narrative around the technical choices that we're making in the early days of XMTP. One of those decisions that we made was to leverage the Waku 2.0 protocol to send and store messages for now. Because at first glance it might be easy to reduce the conversation to "well then what does XMTP do" we need to get into the weeds with it.

This is meant to be an open conversation. It would be great to see everyone's perspective here, and then we can make sure that we're all in alignment.

Part of the stack

First, Waku is just part of the stack for now as much as a method for connecting to ones wallet is. When deciding on a message storage and transport medium, we certainly could have chosen to go with a centralized solution like Firebase in these early days. No doubt that would have been cheaper, easier, and faster. However, using Firebase doesn't align with our long-term goals and ethos as a project. From there it basically gets solved one of two ways: taking a bunch of time to develop our own ideal solution, or using something that gets us 80% of the way there for now.

I've seen too many times in the past where the choice is to go fully in house with something in the earlier days, and how that leads to long delays and misspent cycles. We also need to de-risk so much more of our story than just the message sending parts. Using Waku as this part of our stack for now makes sense—it's a way to solve some of our core problems while shortening our time to market.

But equally important as time to market is a long-term strategy. It's quite likely that Waku will not serve our needs forever, or that perhaps the focus of that project diverges from our desires for it. That's where we need to make sure we're preserving optionality and ideally exploring our own solutions from an early stage. Furthermore, we should do everything we can to not be wholly dependent on external things that are very out of our control.

Waku is just a piece of the puzzle. Just as Ruby was once a core part of Twitter's stack, it now uses Scala and Java to operate. To scale, they needed to build towards an alternative solution. We may use Waku for now, but that detail shouldn't be important to the developers building on XMTP, or the end users sending messages. What matters is their stuff just works and we take care of the rest.

What does XMTP do above Waku?

Even as core as Waku is to our stack is today, there are many things that XMTP is doing that means the two are not equals. Here's the breakdown:

• Standardization
  • Messaging clients need to know what to expect
    • By making core choices around message formats, encryption standards, sign-in methods, etc. we're able to ensure that all developers are working within a common language for building their clients.
    • This allows for more diversity, not less as it ensures that there's a baseline that we can all agree on.
  • Unified inbox
    • Only through this standardization do we actually achieve our goal of a unified inbox
      • Imagine otherwise that developers all have to manage different message formats, encryption standards, etc.…it would be so much more difficult to develop clients that send messages
• User Experience
  • The user experience surrounding a unified inbox is so clearly superior to fragmentation across messaging clients within web3
  • Having a consistent set of expectations when interacting with messaging clients will go a long way.
    • End users may demand more from other clients because XMTP sets a higher bar.
  • Much like Apple's strong UX because of its vertical integration, there are many things that we can simplify for developers which in turn leads to a better experience for end users.
• Network
  • The network effect compounds with each and every new developer, organization, and end user that comes on board into XMTP
  • As XMTP Labs we're in a position to drive a ton of network growth through our investors, partnerships, and grants to the ecosystem
• Developer Ecosystem
  • Supporting developers in building on XMTP is just as much a product as anything else is here
    • Having world-class solutions to enable building of messaging clients, as well as strong support and collaboration will go a very long way here

These are just a sampling of differences, and some of my thoughts. Would love to have anyone else with thoughts add to the above, as well as critique whatever may be in here already.

---

On 1/20/22, @mkobetic wrote:

I haven’t spent nearly enough time thinking about the backend yet, but at this point it seems to me that the primary function of the network is reliable decentralized storage of messages. Pub/sub is a good fit to implement notifications for new messages, and as such desirable as well, but seems somewhat secondary to me.

From what I’ve seen with Waku it seems to have these priorities reversed. Pub/sub seems to be its primary function and storage is secondary. Consequently the storage layer seems somewhat anemic and likely insufficient for our purposes (Steven will correct me if I’m wildly off here) especially once the scale starts to be important.

So I think Waku can probably get us through the initial prototype stages while we have a few nodes that we can configure by hand and everything fits into one or few nodes, but longer term we’ll need more scalable solution (IPFS, upspin, perkeep, …?). At that point if we still want to keep pub/sub we’ll probably go to lower level solution like bare libp2p or something.

Again, I’m handwaving frantically here, but that’s the way things seem to me at this point.

---

On 1/20/22, @shanemac wrote:

• Standardization
  • Messaging clients need to know what to expect
    • By making core choices around message formats, encryption standards, sign-in methods, etc. we're able to ensure that all developers are working within a common language for building their clients.
    • This allows for more diversity, not less as it ensures that there's a baseline that we can all agree on.

The founder of GM.xyz said this today “If you had Sendbird APIs and SDKs, that’s exactly what we use today and what we want. We need the layer that makes it easy for all developers to choose to build on you because it’s so simple. If you have the same documentation and resources as Sendbird, we’d be using XMTP. That’s much different than us as a team having to go figure out Waku"

I also believe that the layer which helps developers adopt in the least friction way possible is a massive value add. This compounds

Then by having a network view of the world, we get more valuable each and every person who joins the network.

I truly see our biggest challenge as network orchestration. Getting everyone to want to adopt a universal way to do something together.