Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. Today I'm joined by Matt Galligan, co-founder of XMTP Labs. XMTP is a messaging protocol built atop EVM wallets. Situating itself in the lineage of email protocol SMTP and Jabber IM protocol XMPP, XMTP aims to make DMs, notifications, group chats, and more available to everyone with a blockchain wallet. XMTP Labs, Matt's new company, is the primary developer of the protocol. In this episode, Matt shares what it was like to be one of the very earliest Twitter users. We discuss his prior startups, SocialThing and Circa, and his motivation for creating a decentralized communications protocol atop the existing blockchain infrastructure today. Matt sheds light on why developers may choose to send messages using a shared protocol rather than building their own solution or using a centralized service provider. It was great talking with Matt about XMTP. I hope you enjoy the show. Matt, welcome to the show.

Matt Galligan: Yeah, thanks for having me.

Nicholas: I'm excited to talk about XMTP. It's a very ambitious project. And before we get into that, I wanted to know, you know, I was looking at your bio on Twitter and I've seen you around Twitter for years. I've been on Twitter for a long time, but I was really impressed to see that you've had your Twitter account since 2006. That's OG as hell.

Matt Galligan: Yeah, yeah. My official user ID is 607, but a long time ago, somebody did like analysis of what the actual counts were because there's a whole lot of like incremental change in those early days of user account numbers and all those things. So actually somewhere I might be in the top 140 of earliest accounts. So kind of wow. Yeah, but I've been on here. How did you from the beginning?

Nicholas: How did you find out so early?

Matt Galligan: Well, it's interesting because like at the time and I was pretty dang young, but I was into podcasting in 2005 when it just got started. And as maybe some people know and maybe some people don't, but Twitter started out actually as a side project of Odeo. Odeo was a podcasting company or they had built some podcasting tools and a place to publish your podcasts and things. So I was a user of Odeo at the time and had actually gone through like the very first podcast convention and at the podcast convention, met Noah Glass, who was one of the early founders of Odeo and subsequently Twitter really just got kind of looped into that crew early on. And then one of my friends and now longtime friend, Derek Owen, who also did a podcast at the time, he got an early invite to Twitter. So it was actually odd, but a lot of us early podcasters were some of the earliest folks on Twitter. That's how I got it. It was Derek sent me an invite. He says, check this thing out. And I did.

Nicholas: And I've been here ever since. That's great. I remember Odeo. I remember when they launched Twitter. I remember the South by. I wasn't at the South by, but I was an avid TechCrunch reader and I think high school student at the time. I remember that era of the transition into Twitter. Were you on the SMS version or was there a web version yet?

Matt Galligan: Oh, yeah. There's a short little story that I'll share, which is that one time on one particular evening, I was enjoying some holiday festivities with some family of mine and had decided that the absence would be a great time to try that and had actually started texting with a friend about my experience with it. But it turns out the entire time I was not texting with a friend, I was texting with Twitter and it was publishing all of those tweets. And it's a pretty hilarious thing. that happened way back when that I think people just don't seem to have an appreciation for these days because the SMS short code was pretty easily accessible. Just pop it open, get into your messages, start texting Twitter. It was a odd thing. But yeah, I definitely did that early on.

Nicholas: Yeah, it had a little bit of a feel. I feel there's some connection to XMTP just in the sense of it being more something that you can access via SMS. It had this feeling and Twitter's always had a little bit of a feeling of all the platforms of being the most like it wants to be a protocol underneath it all. Oh, totally.

Matt Galligan: And those earliest days were definitely like that feeling for sure where you had SMS as one way in. But then there was a huge proliferation of apps in those earliest days of where you could consume the feeds and all kinds of different expressions of Twitter. And obviously that clamped down over time. But it was a really very protocol like feel in those earliest days.

Nicholas: Wasn't there a sort of disaster in Haiti or something? And Twitter really took off because of the SMS compatibility. This was before smartphones were widely distributed. I don't know if you recall that that period of time.

Matt Galligan: I do. I do. That was a pretty, pretty crazy time. But it was, I believe at the time that was the most number of tweets that were being sent. I mean, there's been a number of those kinds of events over time where they break the records. But that was definitely a record breaking time. It was a wild time. But yeah, SMS was the one thing that got through.

Nicholas: Crazy. So have you always been interested in communications or I know you've worked on other projects circa social thing. Is it communication that consistent through line through your projects or is it more about social networking? What's the fascination for you?

Matt Galligan: The through line through pretty much all of my projects that I've worked on is just that I had some sort of specific need that I had felt and wanted to go after. Communication is definitely one that has been persistent in my career. In the very beginning, social thing was a by now it would be called a social media aggregator, but it was a place where you could kind of break free from the silos and punch in all of your various credentials and have a single interface to check your Twitter and YouTube and Flickr and Pounce and all of these networks that have long since died. But yeah, communication has always been something that is near and dear to me, especially because I grew up in a tiny little town of middle of cornfields in central Illinois. And my connection to the outside world was the Internet. And it was adiom and instant messaging and chat rooms. And so I really credit the ability to communicate on the Internet with pretty much my career as a whole. And so it's always been something that I've been deeply fascinated by.

Nicholas: That definitely resonates with me, especially since starting to work in crypto. The one that I was more familiar with was friend feed with social things, something like friend feed aggregator.

Matt Galligan: Yeah, the difference being that what we were trying to accomplish was that you didn't have to have, say, friends on friend feed. So friend feed was. I go and I sign up and I connect all of my accounts. But then the consumption experience is that then I also follow all the same friends again on friend feed and would have that sort of curated feed of the friends on friend feed and their various activities with social thing. You could be the only user on social thing and it would still be aggregating, say, all of your friends and their activity on all of those social networks and publishing it in one feed. So it was just a different take toward a somewhat similar goal.

Nicholas: Fascinating. So we should dive right in, really, because I think people want to know to start what is XMTP and then we can roll it back and ask some more fundamental questions about why. What is XMTP?

Matt Galligan: Yeah, XMTP is a generalized communication protocol for Web3. It is a secure Web3 messaging protocol, if you will. And the goal of it was to set up a new primitive in the space. So whereas today your wallets can transmit money and assets and things like that, but they largely weren't responsible for, say, being able to responsible for or enabled to move messages around and certainly secure ones. And so as a primitive, we've set up a fully end to end encrypted protocol where users leverage their existing wallets to log in and send messages to other blockchain accounts. And the messages themselves, they are encrypted, but the payloads can be very extensible and flexible. They can look like a DM or they can be an email or a push notification. So it's really about setting up this very primitive infrastructure that we can tap into with Web3 and use for all kinds of different use cases.

Nicholas: Got it. The first thing I noticed about XMTP is the name, which reminds me of SMTP. Is there a reason for the relationship? Is it a reference, first of all? And if so, why?

Matt Galligan: Yeah, it actually it's pretty spot on, but it goes one nerdy level deeper, which is there was also another protocol XMPP, sometimes referred to as the Jabber protocol. And when I was trying to think through what to call this thing, the one thing that stuck with me was that this was going to be a protocol where any kind of communication could happen on whether it be email or push notifications or DMs or whatnot. And so I did the very nerdy thing of just what are other protocols named? You know, what can make something feel immediately familiar, though you've never seen it before? And so looking at SMTP and XMPP, I was like, well, here you go. Here's two communication protocols. And I smashed them together. Doesn't go much deeper than that. But, you know, the value being like we've heard from a lot of folks that, you know, hey, I've never heard of XMPP before, but I'm assuming that it has to do with communication. So it serves a purpose for sure.

Nicholas: Awesome. I was looking a little bit at the SMTP Wikipedia page and actually now XMPP and SMTP was like a replacement in the 80s for what they were messaging over FTP, whereas XMPP is like more like late 90s innovation more around chat, like the Jabber protocol. I remember I used was it Adium? we used back in the day. Oh, yeah. Love that app. The little bird. That was great.

Matt Galligan: Used it for sure.

Nicholas: But really, XMPP is what is it like or what makes it different from the closest comparison in the market today? What makes it special, basically?

Matt Galligan: Yeah, I mean, at its core, it really is a protocol of protocol. But, you know, all that we have learned over time about some of these protocols is the devils and the defaults, the things that you decide on matter quite greatly about how they would be used. And, you know, some sort of from a first principles perspective, we wanted to make sure that this was going to be encrypted, fully encrypted and to end that, you know, everything default encrypted. And that is definitely a big departure from, say, what you would see in SMTP and things like that. The other thing was that we believe very strongly that this needs to be decentralized network or at least progressively decentralized, where over time we can be able to enable other node providers to start running the service and that it would be distinct from some other communication protocols that have been federated. So you can think of XMPP as being federated, where all of these different XMPP servers exist out there. Each of them are propping up the service, but my use of it is being funneled through a particular server. And then I can communicate with you. You may be on a totally different server, but we're able to use this sort of common protocol. The same goes with SMTP. I'm using Gmail, maybe use ProtonMail and SMTP is using or is the thing that is used to transport those messages. In the case of Federation, you know, if your server that you're connected to is, say, censored by other servers, that's a problem. If your server wants to censor you, that's a problem. If your server makes specific decisions about, say, what communications can come into it, which is absolutely the case today and why email has become centralized over time, it's because they can express that desire to to stop those communications on the inbound. And so when we thought about this, if I were to scale it back even further, it's that an Ethereum address by nature belongs to you. You are the one who has created it. You are the one that has the keys. It is self-sovereign, which means what does it mean to have a federated communication network in this space? What would it mean to just have one server? Well, I mean, I have an identity. It's my identity. So that means that it needs to be broadly accessible. And in this case, the idea being that whenever I connect XMTP, it's connect to a server, a node in the network that will be able to facilitate whatever it is that I'm wanting to do in it. And so that's where it departs quite greatly from its predecessors. But there's obviously a whole lot that we've learned and think that there's a lot of value in in the open networks that exist today, the open standards for communication that have existed to today. So a whole lot of that from a spiritual standpoint is in XMTP. But some of these very distinct differences we lean heavily into.

Nicholas: So the basic intuition is it seems like people are more and more getting their own private keys, running their own EVM compatible wallets. And there is this like missing piece. We can't talk to each other, so we can't even communicate without some kind of centralized intermediary. At least it's not obvious. There are many different options, but it's not. there's no obvious choice for how we could negotiate about the price of an NFT or I don't know, even just communicate generally using the existing private key infrastructure that we have already with our wallets. So XMTP is going to give us smart, decentralized solution for communicating with one another. I'm curious, what's the difference between like you mentioned this federation problem where, say, if everything goes through, if a significant enough portion of the email through Gmail servers, then really running your own email server is not that significant because you can't really hide from the eyes of Gmail. How is XMTP model different from the SMTP model or federation model you were talking about?

Matt Galligan: Yeah, it's that over time as we take the node software, open source it, allow others to or invite others to run those same nodes. It's that the responsibilities that they have is to process the messages. It's to move them about. And so you wouldn't necessarily be connecting to one specific server all the time. And it's that server that is responsible for your profile and your hit messages and all those things. But not unlike, say, how we use Ethereum today, where if I'm using MetaMask, you know, now imagine like a messaging client and I want to swap the network that I'm connected to the whole RPC function. If I want to change what Ethereum node I'm connected to, maybe even run run in my closet. If I want to change that node to send all of my Ethereum transactions through that one, I can do that. So that's definitely a desire of ours in building XMTP. that, you know, whatever servers or nodes that you want to connect to that you feel comfortable with, you could do that. But then if you don't know any, if you don't own any, if you're not specifically looking for that, but it would at least work at a base level. And the next level being where are these messages stored? That's the part that is so different. In a federated network, they are stored by individual servers. In this network, they are stored at least temporarily by the network itself. And so it's the network's responsibility now, this coordination between nodes that will be responsible for, say, persisting those messages and making sure people can access them.

Nicholas: Got it. Does each node have the responsibility to maintain all of the state of the network or only that of the users that are interacting with that particular node?

Matt Galligan: It's a big thing that we are digging deep into right now. The likelihood is that no, every node wouldn't be responsible for all messages in perpetuity. So some assemblance of sharding, possibly, you know, different types of nodes that would be responsible for different types of storage or subsets of the network. That's probably the direction that it heads in. But as of right now, all the nodes are storing all the messages and for the foreseeable future, that's OK. But there's definitely a point in the future where we want to start to look at that responsibility.

Nicholas: And so it's more than just a messaging protocol. It's also a data storage protocol, at least in the current iteration.

Matt Galligan: Yeah. And we do want to kind of keep that as lean as possible. So you can think of it as there is a bit of coordination necessary for these messages. So when you have an encrypted message, in our case, we're using something that is, say, a derivative of the signal protocol. So when you message me, the SDK, the developers, any developer can go and download this or using it today. But when I go and use the SDK and I, as a developer, let somebody message through it, it takes care of the whole encryption handshake. So I go to message you. The message is encrypted, but it's encrypted with a shared key, something that means that that communication is accessible and decryptable by both of us. And for the period of time where you send that message and it's waiting on me to come online, it's still stored and accessible in the network. But once I come online, now both of us have copies of that message. And so whereas today everything is still stored and held on to by the network, eventually there would be this the second part of the process where now I get to custody the messages that are just for me and my copies of them and perhaps even encrypt them in a different way so that I have greater, say, guarantees or security guarantees around my own personal messages. So there will be sort of this separation of responsibility and how storage works. We don't want to, say, have to go and replicate all the work that a Filecoin did or an RWE to kind of handle this massive amount of storage that would otherwise be required. So to try to keep it as lean as possible. But there is a benefit in the way that it works today and say how we'll manage the SDK for this personal storage moving forward. And that is that you have this concept of a portable inbox. And so in the same way that when you log in to different Web3 sites and your Ethereum transactions, your NFTs, your ENS domain, all that stuff just travels along with you. The same will be said for the messages that exist in XMTP. So you plug into any front end fire up. I don't know the Uniswap front end or Zapper or Lens or whatnot. And your messages are just there. So there's definitely a lot of interest we have in making that very seamless.

Nicholas: That's interesting. You mentioned this. It's a derivative of the Signal protocol. Actually, I don't have a great understanding of how Signal works, but it does seem that they hang on to messages long enough that if you connect with a second device that has been offline for a while, it's able to receive the messages that it missed while it was offline. Do you know in the Signal protocol? Is there a duration, a time limit for that? Or I guess they're running centralized servers to do that. So it's more feasible to do so.

Matt Galligan: Yeah. And also the way that they're making it work most of the time is that when an offline device comes online and grabs the message, then the message can be removed from that server. But it is now on my device, which means that if I want to go and authorize another device to use the messages, there's actually this sort of what we call out of band. So meaning like outside of Signal transport of the messages from device to device. And so there's probably some similar things that we can learn from there. When I say that there's like a Signal-like protocol that we're using for encryption, it's more that of how their handshakes work and how it is a shared secret. And it's not just, say, the way that encryption over email with PGP and all that works. So always in the interest of making a more secure connection and ensuring that that end to end encryption is very strong. We have some really high interest and high bar in that secure interaction.

Nicholas: You mentioned that if I were to log into a DAP like Uniswap or something like that, that it would my messages would be populated because I'm using the same wallet in the current model. Things is it? the SDK is something that the DAP would have to load into their website and then that will make the connection. Or do I need to have some additional wallet infrastructure on my local machine?

Matt Galligan: No, no additional infrastructure. Any DAP can go and grab the JavaScript SDK from our GitHub repo and immediately start using XMTP. And they can do different things like maybe filter the messages to just a particular context or maybe they only want to display notifications or maybe it's there's one cool project that has come out of this called Relay that another team is working on where these like chat widgets that you've seen on various websites that like pop up in the right hand corner and you can talk with support or whatnot. They've built that but for XMTP. And so, you know, DAPs can go in and grab that today and drop it on their website and enable their users to communicate or enable themselves to send communications to those users. It's pretty cool. But yeah, it's totally permissionless. Grab the JavaScript SDK, deploy it on any website and then any website that I go to that is connected like that. Messages are there.

Nicholas: Very cool. So you mentioned that there's nodes that currently XMTP is running, but ultimately this will be a decentralized protocol where other people will be encouraged to run their nodes. What's the foreseeable kind of incentive scheme that would cause me to want to run my own XMTP node?

Matt Galligan: Yeah, this is what I would call more of an intrinsic motivation. So let's say that you are running, I don't know, let's say you're OpenSea and you want to be able to facilitate communications negotiations between users or you want to be able to facilitate, say, NFT creators to be able to message their, you know, the owners and the collectors of their works. There's a lot of value in sort of infrastructure. And so to be able to provide that feature, yeah, you can drop the SDK on the website. And we've it however shallow or deeply you might want in your experience. But, you know, ultimately there would be an opportunity for these websites and these these products and these protocols to also run a node. And let's just say cache the messages for those users. In this case, it's sort of similar to how IPFS works, where I can pin certain files for greater availability or ensuring that, you know, whatever files I might be trying to get at that I'm just gonna say, hey, yeah, these are super important to me. I'm going to pin them on my own server so that I can definitely be sure that they are. they're available fast to get to. And so if you can think of any one of these websites as typically running their own servers for the obvious reasons why they would want to serve on the website, they may want to also run a node that would carry a subset of all communications and they'd probably focused on what users they might have that are using these communications. Really, it's just to be able to have a higher level of service or faster or whatnot. So it doesn't have anything to do with the token or anything like that, just as much as, you know, hey, I want to provide good service. So therefore, I'm going to run a node for this particular purpose.

Nicholas: So OpenSea could, for instance, is pinning the right term or what would you call the hosting term?

Matt Galligan: That much is still, you know, left to be determined. But as far as the concept is concerned, it would not be too far off. Yeah.

Nicholas: So OpenSea could pin filtered subset of all of the messages on XMTP that are, let's say, between people who have signed the message that they agreed to the OpenSea terms of service with their wallet or something like that.

Matt Galligan: Totally. And there will be some things that we even deploy in the next few weeks and months that help to facilitate some more of

Nicholas: that filtered

Matt Galligan: aspect, because while the protocol does support this portable inbox in that any messages that are sent to you over XMTP will be available that we, no matter where you go, if you're logging into something that displays all of your messages, they're there. But if you go to somewhere where they are intentionally filtered, then they would be able to do that and just display things maybe that are in the context of OpenSea.

Nicholas: So, for instance, there's sort of two choices that provider like OpenSea could make. One about what they're choosing to pin and one about what they're choosing to display. They could even be displaying things that they're not pinning because they could find them through the gossip protocol or whatever the protocol is to talk to. Yeah.

Matt Galligan: Generally speaking, yeah. And I would also say that there's benefits in a website being able to display messages that are in the context of that particular application. And that's where we could really see, say, engagement in Web3 apps improve because the one thing that's missing from the space and that would otherwise be available to developers in Web2 and something we take for granted is re-engagement. It's the idea that when somebody signs up, I can hit them back with a push notification or an email or whatnot to let them know, oh, this person followed you or, oh, hey, there's an update about this. We just can't do that in this space today. If those messages are more prolific across my experience in XMTP, better everybody's experience will be. So if I'm on some website and there's some tab that allows me to check the messages that are happening in another context, then I might be able to use that to jump around in my experience and re-engage with the apps that I want to check out or that I've been using.

Nicholas: So if we take this example a little bit further, let's say something like Gem. Maybe you could imagine Gem surfacing notifications from all of the marketplaces that Gem is integrated with so that you're not only getting your OpenSea related messages, but every kind of notification about offers across all of those marketplaces. Is that a good example of what XMTP would be good for? And actually, I'm really curious why someone like OpenSea would choose to use XMTP rather than AWS or something that they roll on their own. Is it for the network effect and access?

Matt Galligan: Well, there's a bunch to dig in there. First off, I would go back a few seconds and wish I had like a sound effect button to say ding, ding, ding, ding. But you've got the point right on its head. Where? because it is permissionless, because anybody can tap into this and start using it immediately and because they can send these messages in this way. Yeah. If you're Gem and you're an aggregator, it would totally make sense to be able to pull all of these different things together. But if you are, let's say, an individual marketplace, I would say, one, do you want to make it your core business to do secure messaging in this space? There's a whole lot that is behind the scenes that is quite challenging. It's like, how are these messages stored and what kind of liability is being taken up by an individual company that is now going to store those messages versus a protocol? And how is it going to be encrypted? And how do you ensure that there aren't sort of people, let's say, if I'm a user, like if the service itself is sort of keeping track of who is talking to who? And there's just all kinds of reasons where a service may just want to start using a protocol like this. But beyond that, it's that they already have, in a lot of cases, a committed to this semblance of open permissionlessness. And so even OpenSea and building the Seaport protocol has made a very clear commitment to that. They moved away from their very, you could call it centralized, but it was a contract for NFT trading that was exclusive to them into something that was more open. And there's a lot of value in that. So I think that it's more about the sort of spirit of this space, but that you're not going to push everybody into these siloed experiences. There's a lot of benefit that can come from that. And as the network improves, as more participants in the network come online and more dApps start to use it and wallets and things like that, there is an immense amount of value that can come from that, you know, that network effect.

Nicholas: Yeah, it seems like it would be maybe even possible that services that are even more decentralized than something like OpenSea, like Uniswap or I don't know, other more true Web3 dApp infrastructure, permissionless smart contracts with no company attached potentially, would be really incentivized to be the first adopters of something like this because they don't really have an interest in doing messaging. They just want to be able to notify users when their transaction finally processes. or what have you. And then maybe through the network effect of those dApps adopting it becomes something that more centralized offerings are drawn to because people start to install some kind of iOS or Android app that gives them notifications from XMTP. And so if you want to get into people's lives, it's maybe the best choice. Is that something like your go to market strategy?

Matt Galligan: I need that ding, ding, ding again, but you're doing well here. The story does kind of tell itself. It does start to make sense once you can unpack all of the ways in which this works today and can work. But I'll give you two examples, which is that this whole thing got started because I had a conversation with a friend of mine, Robert Leshner, who was telling about the challenges they had in building compounds and how they couldn't reach their users. I mean, $10 billion sitting in a smart contract. They know it's almost as though they knew the phone number of every person that was a user. Imagine a bank that had the phone numbers of every one of its customers, but there was no phone service yet. So that's kind of how this whole thing began. It's like, yeah, the decentralized protocol. You need to get in touch with their users. How on the heck are they going to do that? And they're certainly not going to prop up their own sort of custom way of doing that. And the far other end of the spectrum is there's a school protocol, OSON protocol, that is using XMTP with their next big evolution. So V2, when that comes out, they allow this sort of like tokenization and transfer and trading of like anything so physical or whatnot. It's a settlement layer for all kinds of other use cases. And they are using XMTP as a transport protocol for offers and all of this other, all these other kinds of things. And they can do that and they're interested in that because they want to be decentralized. So they did build in this sort of very decentralized and open fashion. And as a result, they do have to use a video. They would be interested in using something like that. And the same was going to be said for Web3 social and protocols like lens where primitives from the ground up are decentralized. So you've got to use something that is looks a little bit more like what XMTP is doing. And at the end of the day, we're just trying to break out of like. we don't want to repeat the sins of the past. You know, you think about email and and how prolific and usable it is. And I can use any app to tap into it. But when you get into Telegram and Signal and WhatsApp and iMessage and Twitter DMs and all of those, those are all silos and they don't talk to each other. And so we're really sort of setting up this future where there's much more openness and people's ability to communicate and accessibility to to communicate with people and facilitating that.

Nicholas: You mentioned lens protocol. I did want to ask you about that. But from the sounds of it, it's XMTP is not competitive with lens. It's instead sort of the notifications layer that lens could tap into. Is that a appropriate interpretation?

Matt Galligan: Totally. Yeah. The idea that there are tons of features that could be leveraged by lens or any dApp that is building with the lens protocol or whatnot. Yeah, absolutely. It's something that is that anybody can tap into today. And lens is certainly one of them.

Nicholas: We've talked about this really in terms of like messaging or even a little bit notifications. The first thing I want to ask is when iPhone app, is that something that you're funding or hoping that somebody will build of their own accord?

Matt Galligan: Yeah, there's a handful of companies that are building iPhone apps, some of them native, some of them react native that are looking into communication and DMs and things like that. We've already done some of the work to get a react native SDK in place. That's up on our on our GitHub and excited to have people check that out and give us some feedback. But, you know, going a little bit further. Yeah, there's definitely interest. I think that we are super keen to work with teams that are building an awesome experience around Web3 chat or interested in that, but want to use, say, a more open protocol to make that work. We've already been talking a handful of teams to that effect. But yeah, I'm I really want this on my phone, to be clear. So I'm pretty keen to find somebody to go do that.

Nicholas: Yeah, that seems like a great grant or series of grants for parallel teams to work on different things. But it also seems like maybe the more natural first place for this to show up would be in dApps that people are already using. Or have you seen anybody use it in an NFT context? I wonder if the social communities of NFT collections are maybe a prime location for messaging as well.

Matt Galligan: Yeah, that's something that I'm really keen to see how it plays out. There's a bunch of NFT communities that I think would benefit from this greatly. I do think that there's a couple of ways that this could express that it'd be very powerful, which is I imagine NFT creators being able to talk to their collectors, you know, ones maybe to promote some new project they're working on or whatnot. But going a step deeper, it's like, hey, if there is support that you want to provide, what's our recourse today? It's like you go into Discord and you fire up these channels and they say, hey, we'll never DM you because that's too much of a risk. And so off the bat, you're seeing this deficiency that's established because of scams and all this stuff. And it's because we have this sort of separation of identity. You know, you have your private keys and they live inside of Web3 world. That's not somehow transferable or even really trustworthy in the context of Web2 where it's a loose connection at that. So even if you had a login on a Discord or something, that's not that you can inherently trust that that is who you're talking to. And it's the case of XMTP where if you're sending me a message, cryptographically speaking, I can verify that that definitely came from the wallet that it says it did. And so there's a lot of value in, say, even being able to provide support. You know, so if you're thinking about community communication, lots of possibilities there, you know, communication from NFT creators to their collectors, lots there, support. But even from a, let's say, commerce perspective, we haven't seen, say, some full blown projects yet like that yet that have launched. We have a number that we're talking to and have been working on implementations. But there have been some really cool hackathon projects. I remember one in particular a few hackathons ago that had built, say, a, they composed the Seaport protocol and XMTP so that you could negotiate with another NFT owner and then execute the trade via Seaport.

Nicholas: Very cool. All from within the same interface.

Matt Galligan: That's right.

Nicholas: Very interesting. I think it's a great point that you make about the support and the spam and phishing, etc. impersonation on Discord, on Twitter, whatever. And actually, that does seem like a wedge where really something like XMTP or any kind of protocol that's using wallet signing as proof of identity would be superior to the incumbents. Like, of course, the natural problem for like an NFT project adopting something like XMTP is that in all likelihood, they really want to propagate on Twitter more than they want to propagate on a network with less users. However, this totally support is a major one. I'm curious how you foresee the interaction between XMTP and Ethereum. Do you think it's something where people will use like something like HATS protocol or Orca or NFTs or something in order to say these are our community support people? And if you talk to people with these wallet addresses, then you know you're talking to the real project team. Or how do you see the interaction between XMTP and like verification of identity through Ethereum?

Matt Galligan: Well, the good thing is, is that we have this awesome public good in ENS, you know, so I have the Galagan.eth, which is my last name. We have as a project, we have XMTP.eth. And let's say that we were we were trying to do support through that channel. I don't know that we would, but let's say that we wanted to set up support.xmtp.eth. By doing that, you are already establishing that, hey, this is an official channel. And cooling up to the subdomain in ENS is that you can absolutely know that whoever is registered as the controller of that subdomain is in control of that, say, EOA, that blockchain account and that ENS domain. So if it resolves to the right ENS domain inside of XMTP, you can have a certain amount of guarantee that, hey, this is definitely who I'm talking to. And we're working on, say, the next level of that from a protocol perspective. that would then enable delegates to play a role. So and what I mean by that is like whenever you're using Zendesk or whenever you're interacting with somebody on one of those support chat widgets, ultimately you are talking to a particular person at the other end and they have their systems that have granted them access and all of that. Well, you know, how do you take something like a support.xmtp.eth and divvy it up to people to communicate? You can't just give out the private key because that would be insecure and increase the potential that it could leak. And, you know, maybe then you're not talking to the right person. So we're very keen to add in features where you can delegate that access. And so now you might delegate that to another particular user who can message on behalf of that DNS domain. And you can trust that, you know, only the owner of that DNS domain was able to set up that delegation. There's still a whole lot to consider. There's still more that can be done. You could even go a step further and put like mat.support.xmtp.eth and have further guarantees. But yeah, it's no question an important thing. And I think that looking at ENS as a way of accomplishing that would make a ton of sense.

Nicholas: Yeah, that's very cool. I'm excited to get my hands on it in the future. Is there any application that I can use today? that's you mentioned Boson? What does Boson do?

Matt Galligan: Yeah, so Boson protocol being a protocol for transferring and trading like other things maybe than just NFTs. It's kind of more broad, but they're looking to tokenize real world assets and have all kinds of different sorts of exchange that would be possible. But you can check out relay.cc. I know they have a really cool experience where they have built a way to send messages that is based on XMTP. They use XMTP. So relay.cc. We have XMTP.chat, which is accessible. I'll say that right now the network works for users who have also initiated their XMTP profile. So it uses your Ethereum wallet as authentication, but it does create a separate public key, you know, one for messaging and encryption, but also because we believe it's important to separate the sort of how you store your assets and how you handle your communications. And so right now, it's only people that have already initiated that can communicate to each other. Anybody could jump onto any one of these and say, message me at matt.galagan.eth and I would get the message. But another thing that we're working on as a way to send a message to any address, even if they haven't, say, used a app that has XMTP in it yet. Yeah, there's a bunch of different places you could go today. We are looking to do a better job of propping up a website that could showcase all the different places it could be used.

Nicholas: Very cool. We've talked a lot about it in terms of like one to one messaging, but I suppose it's a more generic communications protocol. Do you think that XMTP is something that is applicable for one to many communication? And also, I suppose the notifications thing is a little bit of an answer to that, but also many to many like something like Reddit or Discord. Is this something that XMTP is applicable to? Yeah.

Matt Galligan: Yeah, definitely. And the one to many use case can already be done to an extent today. It's just got to build the tools to to be able to do that broadcast. And so if you wanted to do something like, hey, I want to reach everybody that owns this particular Po app, then that's definitely a really cool use case and could be done today. But if you wanted to do something like I want to set up a group chat with all of these Po app owners, interestingly enough, the folks that did relay had come up with a way to essentially do group chat directly over XMTP as it stands today because it's extensible and all that stuff, which is cool. But we're really keen to see this be a first class citizen, a first class feature. And so group messaging is very much on the horizon and something that we're exploring as we speak and how we get it done. But group and encrypted chat is challenging. We have a couple of different approaches that we are exploring right now to make that work. But yeah, eventually, if it looks like being able to have, say, Discord like rooms or Slack like rooms or or even in a smaller context, it's definitely something that we are keen to get out there.

Nicholas: Very cool. How does XMTP compare to something like Lit Protocol? Is XMTP only interested in communications or do permissions also become part of the mix once you have wallet signed and authenticated communications protocol?

Matt Galligan: Yeah, I think the permissions are super interesting when layered into something like XMTP. And we've already seen an example where a handful of projects have used Lit and XMTP together to say filter inboxes or to share certain secret codes. So there's even one where a developer took Lit and added like another layer of encryption, which is kind of crazy. But like I can send a message to you that's like another kind of encryption that I then have to go and pull the key down from Lit to decrypt it, which is really neat. You could imagine that it's like, hey, I'm going to send out this message to all NFT owners of this particular collection. But what if you want that to be predicated on the current ownership? So it could be that it uses something like Lit where I'm going to add this additional layer of encryption. And only when you prove to me that you own the NFT currently will that message decrypt again. So there's some cool things that could be done there. But as far as asset proving and things like that, that is no question something that we are keen to explore or work on with the community where, you know, if I want to be able to say that, hey, anybody with a, oh, I don't know, a board Ape or a Moon Bird can just directly message me without any sort of gating or cost or whatnot, that they could do that. Proving that stuff will be very important. And in that case, it's more like attestations or you're going to see the term verifiable credentials come up in the space quite a lot. Those are the kinds of things that we're interested in. I love Lit. I think there's so many cool things that they're doing. So there's more that we would probably compose with as opposed to compete with.

Nicholas: You mentioned the idea, and I've read a little bit about this idea inside of XMTP, that you could put a bounty on sending a message or receiving a message. I suppose this is more on the general theme of spam. You mentioned earlier the idea of sending a message to anybody who has a certain poll app or something, and right away we get into the territory of spam. How does XMTP think about spam?

Matt Galligan: That's a really good question. There's a few different things that we are, different tracks that we're digging in on right now. But I would say the longer term vision is that if I want to be able to send a message to somebody and I have no pre-existing connection with them whatsoever, there's no proof that I have interacted with them, know them, and that user has not provided consent to be messaged by just anybody. Could be that there is a transaction cost associated with that. So think of it like a postage fee, literally putting a stamp on something to send it. It's to be able to prevent the sort of widespread abuse of the system where today there's no disincentive to send spam email, period. Why 90% of all email is spam is because there's nothing to punish those that are abusing that privilege. And so in this case, it's more like, hey, we want this to be open. We believe it should be open, that anybody should be able to message anybody. But there could be some kind of economic barrier to be met, which may look like some sort of base fee. And then I as a user could also have the discretion to perhaps add an additional amount. You know, the stuff that, say, Biology did years ago with Earn, where I can put a higher bar to be met, to be messaged me for whatever reason. You know, presumably that is something that we are keen to see as well. But finding some way to manage spam through economic means is really important. And that's because from a core principle standpoint, if we are default encrypted on everything, the same kinds of ways that email handles spam are gone. If we are permissionless and decentralized, that means that you can't exactly block all the messages that are being sent from a particular IP or a server. Those concepts don't exactly work the same way in this world. And so once again, you need to find other means to manage that. And we believe that probably through economic means, possibly soulbound tokens, other kinds of ways to be able to prove identity and credentials, all of those ways could be could be explored.

Nicholas: Right. Because there is also this problem, even if in the world of email, where the messages are plain text or at least visible to someone like Gmail, the spam filtering is done on a centralized service versus in this system, you'd maybe have to do it on a local client. But if you have potentially like infinite notifications coming in that your computer is having to parse and decrypt and decide if they're spam or not, it becomes an untenable system. Do you think the base fee is something that will end up going to the recipient or something that would go to the node operator or somebody would just be burned? How do you think about that?

Matt Galligan: I think that the changes that Ethereum made and EIP 1559 and burning that really helps to keep that a very neutral network where it's not, say, being earned by any one individual. I think that in messaging, it gets even more challenging because you can imagine that a certain kind of malicious actor would try to capture it for themselves. So maybe there is some reputation system that somebody has built on top of XMTP and like, say, the volume of messages sent that are successfully sent and not treated as unwanted or spam might increase that reputation for that particular user. The problem is, is that can be gained so quickly if that fee can be captured by the person on the other end because maybe you are the same person. And so to have those fees, even in a sort of base fee sense, be burned means that no matter what, you have some sort of system, some sort of entropy where I can't just keep going with the same attack over and over and over.

Nicholas: Interesting. That's going to be challenging. But I look forward to the solution you come up with.

Matt Galligan: No doubt. No doubt. There's a lot of. there's a lot of things that we're still exploring. And to be clear, like those things matter a whole lot more when there is, say, a permissionless node operation, because there will still be ways to manage spam in the earliest days when it's, say, a whole bunch of providers that are able to more so work together to figure out where abuse in the system is popping up and things like that. And not exactly easy ways to stop that from happening, but at least it can be identified and managed in some other fashion. But the moment that we start heading towards this fully permissionless world, having ways to prevent these communications from happening where it's just totally malicious and tons of spam running about the world, that's a problem. We have to figure that out.

Nicholas: What's XMTP's business model? How could you possibly make money off of an open protocol? Do you think it has something to do with this base fee spam protection or does it not matter to you?

Matt Galligan: Yeah, in this case, we'll separate, say, XMTP, the protocol from XMTP labs, you know, so you have like compound and compound protocol and the compound lab. In this case, you know, XMTP labs as a company is very keen to build this protocol out. And anybody that goes and builds a protocol or an open source project knows that there are plenty of other business models to be built on top of that open source work. I mean, it's so much of how, say, commercial open source software is seen today. Like you've got examples like WordPress, where, you know, WordPress builds WordPress dot org and that's an open source project. But there's so many other ways that they can say have a business model on top of that and plenty of ways that we can explore that with XMTP as, you know, say experts in this particular protocol. From a protocol perspective, what we care about the most is that it balances, right? It's that there's enough activity going into the system, say the nodes would be able to earn for the work that they're doing and providing relay and storage in this in this network. There is enough activity in the network to say balance that those emissions with earning of tokens where largely speaking, it's a self-sustaining network. That's the main goal. And it's not that it's like putting out tons and tons and tons of fees that would be captured in some other way. It's that it is able to work as a as a public good of sorts. There's a lot of value capture that can be built on top of it. I think that the whole question of bounties and and other sorts of, say, fee mechanisms probably could be layered in somewhere beyond the base fees. There's also God knows how many opportunities for service providers to build features. like you want to go build a MailChimp or if you want to go build a Zendesk, if you want to go build a SendGrid, all of those opportunities are going to exist. So really, we have to kind of spread out all the different ways that business models can be built and focus on, hey, what part of the stack are we talking about?

Nicholas: Is XMTP Labs a VC backed operation?

Matt Galligan: Yes, it is. Yep. So we had gotten VC funding over a couple rounds last year, you know, A16Z and a whole bunch of really amazing investors jumped in with us to see this thing get built. But yeah, this is a there's no question a really pretty big undertaking. And so getting early funding was important to be able to achieve all the goals that we set out to find our way through.

Nicholas: Are you able to share how many people are working at the labs right now?

Matt Galligan: Yep. There's 15 of us, although I think we might have. we're up to 16 maybe. And we definitely have quite a few more opportunities that are open. So XMTP.com, you know, the project will be hosted at XMTP.org. That's XMTP the protocol. But XMTP Labs, the company is just XMTP.com. And there's a good resource on there to find all the open positions that we have. But, you know, engineers looking for DevRel, UX, product managers across the board, you know, we're growing for sure.

Nicholas: Very cool. Do you think we covered the world of XMTP as it stands today? Is there anything I missed that I should ask you about?

Matt Galligan: It's pretty. it's pretty deep and pretty wide. There's a whole lot going on. And over the next few weeks, like, you know, some of these projects that have been built with XMTP and this secure Web3 messaging will be coming out. It's going to be really cool to see how all that is by the community. But then, you know, as far as all the parts of what we're trying to do here, I think we got a good chunk of it in. I'm sure that after we listen to this again, I could point out all the ways that I maybe missed the the talking points. But I think we did a good job. This was definitely dense and went pretty deep. And so for anybody that's interested, like happy to dig into more subjects, either, say, on our discord or just shoot me a tweet. I'm just at MG. The project is at XMTP underscore on Twitter. But yeah, discord or GitHub, you know, for anything that we might not have covered, I'd love to dig in with anybody on.

Nicholas: Awesome, Matt. Thank you so much. This was really interesting learning all about XMTP and I look forward to see it integrated in product soon. I'm going to go play with Relay next. I think that's my first homework.

Matt Galligan: Fun. Yeah. Shoot me a message. Just Matt.Galligan.Econ there.

Nicholas: Cool. Thanks so much. And thank you, everybody, for coming through to listen this week. See you again next Friday.

Matt Galligan: Thanks a bunch. Yeah, appreciate it.

Nicholas: Cool. Thanks, Matt. All right. Talk to you soon. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter at Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at Web3GalaxyBrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.