Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. At the end of 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 Dan Romero. Dan is the co-founder of Farcaster and former VP of Operations at Coinbase. Farcaster is a decentralized communications protocol that uses Ethereum as a username registration service. Farcaster promises users a direct and uncensorable relationship with their audience. It promises developers permissionless access to all content on the network. No API key required. In this conversation, Dan walks me through the early days at Coinbase and what he learned interfacing with global banks. We discuss the technical architecture of Farcaster and how its security model maximizes decentralization while limiting risk for users' Ethereum assets. Instacaster.xyz developer, Zach Terrell, joins the show to lend his perspective as a builder working with the Farcaster protocol. Few things in this world are more challenging than launching a successful new communications network, but Dan's design for Farcaster is an exciting attempt to recreate the open and permissionless access of Web1 with the trustless assumptions enabled by blockchain and the rest of the Web3 technology stack. I hope you enjoy the show. Welcome, Dan. Welcome to the show. How's it going?

Dan Romero: It's going well. Thanks for having me.

Nicholas: Absolutely. So today we're going to talk a little bit about Farcaster, but maybe first you could give us a little bit of background. I know you worked at Coinbase previously. How did you first get interested in crypto?

Dan Romero: It's a bit of a longer story. When I first moved out to Silicon Valley in 2013, I knew one of the co-founders, Fred Urshom of Coinbase from college, and he pitched me pretty hard on joining as the first employee. I was coming out of consulting. They just raised their Series A and had this huge customer support backlog. And I dismissed it completely, thinking that Bitcoin seemed like a Ponzi scheme, magic internet money, not what I wanted to work on in Silicon Valley. And then about a year later, I actually kind of came back hat in hand saying, wow, I'm really interested in Bitcoin now. I finally have read the white paper. I think just being in Silicon Valley for a year, I spent a lot of time with smart people and they all seem to have an opinion on Bitcoin. And I honestly didn't. So when I finally went and read the white paper, it clicked for me that Bitcoin and then later I think Ethereum is going to be this kind of new computing primitive that a lot of new apps and services are going to be built with. And as a result of that, I just kind of got obsessed to the point that I was working at a SaaS company at the time and then kind of really just wanted to make the switch and ended up joining as employee 20 at Coinbase.

Nicholas: Awesome. And what kind of development work were you doing before you got into crypto?

Dan Romero: I'm actually not a developer by trade, so kind of all design and kind of like front end stuff. So at Coinbase, I was the VP of operations and so kind of managed all the bank relationships and the fiat on ramps and then a bunch of other functions while I was there. I worked with Varun, who's my co-founder on Farcaster. And then after leaving Coinbase in 2019, took some time off and during COVID reconnected with Varun. And then we just kind of started hacking on just kind of some prototypes. And the original idea behind Farcaster was, could we take RSS, kind of decentralized protocol that is still quite popular today, maybe not on the news and information side of things, but all podcasts are basically distributed by RSS. Right. And could we could we kind of like make RSS more competitive with something like Twitter? And so for the first year or so, it was just Varun plus me. And and then we were kind of working together on the initial prototype of the client and the protocol. And so I did all the front end and he basically did everything from kind of the smart contract all the way up into kind of the middle of the stack.

Nicholas: Wow. I want to focus on Farcaster, but your work at Coinbase, I think, is the. I've always been really impressed by Coinbase because it is that hard work of the operations of getting it to actually be legal and functional all across the world. That's what separates Coinbase from everybody else who says, oh, it's so obvious or something like that, that hard work. So that's pretty incredible. I don't know if you have any any reflections on that period of time that are easy to capture in a few sentences, but I mean, I came into the scene much later than that. So is there anything you can share about that period of time that informs your work on Farcaster today?

Dan Romero: Yeah, I joined in 2014. I didn't know at the time, but we were going into the kind of first major crypto winter. So Coinbase just crossed a million users. And at the time we had an open API. And so I calculus was, OK, Bitcoin is going to be this thing that people build new apps and services on top of. Coinbase is going to kind of be this API layer and you're going to have all this crazy cool innovation that happens. One, we had to shut down the open API because our bank partner in the US didn't like the idea that anyone could have unfettered access to a Coinbase account from a developer standpoint. So that was incorrect. And then I think the second thing was Bitcoin. Obviously, it's still a massive brand. The market cap is twice that of Ethereum today. It serves a purpose, but it never ended up being the kind of computing platform. I remember when I first joined, we went to Bitcoin 2014 in Amsterdam and Mike Hearn, who had been a developer at Google, was prototyping a Bitcoin based like Kickstarter equivalent called Lighthouse. It was a really, really impressive piece of technology, given how difficult it is to write kind of like the Bitcoin script code. And it just never took off within the community because I think that, you know, you ran into the block size debate and then the just general focus, I think, for Bitcoin, which may be the right choice for Bitcoin, has always been on kind of being more conservative, focusing on decentralization rather than something that is turning complete like Ethereum. So I was completely wrong on joining Coinbase, thinking that it was going to be the app platform. And then what ended up happening was when we shifted in 2016 to adding Ethereum and then later other cryptocurrencies, I think it, in retrospect, is a little bit more obvious that being a crypto on ramp, given how big the category is overall, is an incredibly valuable thing to be. Right. And so what I got lucky with is I ended up working on the international expansion when I kind of that first year I was there and I found a bank partner for Coinbase in Europe. And I still think they work with them today. The bank is in Estonia, but it gives you access to the entire Eurozone. And so we were able to kind of expand from being a US based company to a European market company. And then we expanded to the UK and then later Japan and other countries. I also took over the US bank relationships at a certain point and so got really intimately involved in understanding how you can kind of maintain these like very strategic bank relationships for crypto on ramp, which allows you to kind of enable that easy flow from fiat into crypto. There's a whole bunch of stuff that goes into that, right? You have to be licensed and regulated. So there's a lot of compliance stuff that you have to think about. There's obviously the whole security angle of that, both being able to pitch the banks that you're working with that you're not going to lose the Bitcoin because that becomes a reputation risk for that bank. And then there's actually a ton of fraud. that happens when you are trying to convert fiat payment methods into crypto payment methods, because for the most part, especially in the US, fiat payment methods are reversible. So if someone actually debits your bank account, you know, fraudulently, you can just call your bank up and then the bank has easy recourse to just pull that money back. It's actually one of the reasons why wires require phone confirmation most of the time, because it's actually one of the few payment methods in the US that is irreversible or very, very difficult to reverse. But if you force everyone to wire money into Coinbase, then it's a really bad user experience versus the ability to just debit from the bank account kind of feels magical. or even better use a card like a debit card or a credit card. But in all those cases, if a fraudster, you know, fishes, grandma and gets her bank account or credit card, all they want to do is show up to Coinbase, buy as much Bitcoin or Ethereum as possible, send it off Coinbase. And then as soon as it's enough, Coinbase, obviously that's an irreversible transaction. So and then 30 days later, Coinbase ends up with the fraud. So I think one thing people don't appreciate is how much fraud prevention Coinbase has. And obviously, part of that is the data set for being the business almost 10 years. That machine learning model that Coinbase has as a proprietary model is actually extremely good at detecting potential fraudulent accounts. And that's actually one of the reasons why I think you don't see as many on ramps that are as competitive in the US with Coinbase. It's not for like the lack of regulation, because I actually think a lot of people have gone and got the licenses. It's actually the fraud mitigation makes it really difficult to offer people really high limits. Right. So when you sign up for Coinbase, I think it's something like you could buy 20,000 or 25,000 dollars right out of your bank account, whereas most other companies, they limit it to like five. And that differential is actually mostly driven by fraud.

Nicholas: Fascinating. I have to ask you the question that comes to me as someone working in the space personally. I take it you don't have a background in law, but you are working with a lot of legal compliance and banking compliance. How do you manage to make progress on these issues without just getting into these sort of endless conversations with lawyers about how to mitigate the dangers of engaging in activity that's like genuinely innovative?

Dan Romero: I think a lot of it's trial and error. And I'm generally a curious person. And so we had some really talented folks on our regulatory and legal team early on at Coinbase. And so I spent a lot of time with them. Because if you think about it, it's this weird situation where I was doing sales to the bank partners for Coinbase. It's kind of not a normal thing, right? Normally you can just walk in off the street as a company and a bank is actually trying to sell you on using the bank.

Nicholas: Right.

Dan Romero: But as a crypto company trying to get a bank that's willing to process the fiat payments for the crypto company to kind of make the on ramp work, that's actually you have to do this kind of reverse sales. And the only way you're actually going to get that deal done and the bank willing to work with you is you have to convince the compliance people at the bank that you guys actually have a high quality compliance program. And so you kind of run into a situation where on average, the compliance and regulatory people aren't really salespeople. And so if you put your compliance and regulatory people in front of the compliance and regulatory people for the bank, it actually tends to not work out as well as you'd think. And so kind of being this intermediary where you're kind of thinking about, like, OK, how are we positioning what you're actually doing? Right. You can't fake that, but take what you're actually doing and packaging it up in a way, whether it's kind of a presentation or being able to answer thoughtfully the questions and then also be able to think about the actual product experience that you're trying to drive. That's kind of like this thing you fall into where if you have enough conversations with the compliance people internally as well as externally, you start to speak the language enough that you can kind of communicate. I don't think you can kind of actually go write the policy or think through the real deep legal ramifications. But then again, you can always kind of work with those people and then bring that in order to kind of get whatever you're trying to do done.

Nicholas: It sounds like there's when you're dealing with the banks, there's a lot more like we need to get to this specific goal, like increasing the limits or enabling less KYC restrictions, etc. And so there's a very clear path to what you want, whereas working personally more on the Dow side, often it's a little bit like, well, there's three or four different ways this could be done. We're not really sure which of them is the best course of action because we don't actually know how these things will be regulated directly in the future. It's interesting to hear your perspective from that time.

Dan Romero: Yeah. And I think one other thing that's interesting. early on at Coinbase, we were very much in the technology company point of view, you know, kind of the Facebook era of like. you want to minimize onboarding friction.

Nicholas: Right.

Dan Romero: And what we found with that is so KYC is not optional. Like at a certain point you have the certain limits. You just going to have to have a certain level of KYC. And we made a shift in 2017, 2018 that ended up working really well where we would front load all of the KYC. So counterintuitively, you add more friction upfront, but people would get through it. But then once they were in, they actually had this really nice experience where we weren't asking them for more information. Whereas in the early days, what we do is we try to make it as easy as possible to sign up. But naturally, as you got deeper in and bought more Bitcoin, we had to come and reach out in a pretty aggressive way to say we need more information from you, which actually kind of makes you almost feel like a criminal. And it was this terrible customer experience. And so if you actually do it upfront, people just kind of say, oh, I guess this is what's required. And if you notice, like most. Banks do a lot of stuff up front, but then kind of once you're in, it's you can kind of do everything and all the requisite information has already been collected.

Nicholas: Interesting. It would be interesting to see DAOs take a similar approach for a membership or even for launching DAOs. OK, so let's jump to Farcaster, maybe for people who aren't familiar. What is Farcaster?

Dan Romero: So Farcaster is a centralized social network that has two guarantees. One, a user can always have a direct relationship with their audience or their follow graph. So there's no kind of intermediary between the person casting something, tweet, cast, same concept, and who's following it. And the second guarantee is that as a developer, you have permissionless access to the network, both at the kind of data layer, but also the ability to kind of like build any app that you want. And if a user wants to use that app, you have that ability. So there's no terms of service or quote rug pull that a centralized company can say, oh, well, we're not allowing this type of application. So in that regard, it's very similar to email or the web, where you kind of have these very simple base level protocols that allow, again, any individual to kind of have a direct relationship with their audience and developers to be able to build whatever their creativity sparks.

Nicholas: So much more like that RSS example you gave earlier. It's more like a protocol and less like a centralized database.

Dan Romero: Yeah, it very much is a protocol. But I think sometimes when we pitch forecasters a protocol, you start to see people's eyes roll over and they fall asleep. So I think for practical purposes, the way I pitch it to kind of a normal person is we're building a social network and it's built a lot more like email or the web versus something like Facebook or Twitter.

Nicholas: Interesting. And maybe could you shed a little bit more light on what the technical architecture of the protocol actually is?

Dan Romero: At a high level, we only use the Ethereum blockchain for the username registration and the mapping of a given username to an Ethereum address. And we use the Ethereum blockchain to do this for good reason, right? So anytime you're using a blockchain, there's going to be some amount of cost to it and complexity. But what we feel great about using Ethereum for this is, one, we don't decide who owns a given username. It's a completely fair process in the sense that if you go and register, you know, I don't even know how you pronounce your handle here, Nicholas?

Nicholas: Yeah, just Nicholas is fine.

Dan Romero: Right. But if you want that specific username, you can go to the contract, register that username, assuming someone already doesn't have that username. And then once you have that username, you can kind of own it forever. And what the other nice property about using Ethereum is we can give you kind of admin access to that single row in the database, if you think about it, right? No other person can come in and change that entry between Nicholas and your Ethereum address. And that's actually as much as I know anything about other technologies, I don't think anyone's come up with a database where you could give row specific permissions without having an overall admin key for the entire database. And so that's actually a uniquely enabled experience by something like Ethereum. But the rest of the social network exists off-chain because from our standpoint, once you've onboarded, so going back to that kind of Coinbase analogy, do the friction thing up front, you should be able to use the social network without ever having to think about, oh, do

Nicholas: I have enough

Dan Romero: Ethereum

Nicholas: in my wallet?

Dan Romero: or what are gas fees? It should kind of almost be like this all you can eat buffet, right? You pay to get in and then once you're in, you can use the social network just like you'd use any other Web2 social network. And the way we're able to do this is because every Forecaster client is a wallet, we have the private key that maps to the public key. that's on chain. And so every time you cast, you follow someone, you like a cast, you update your profile. That is a signed kind of message, just text with a provable signature that, yes, you are Nicholas or I am DWR when I'm doing something on Forecaster.

Nicholas: But those keys are managed by the Forecaster service or the application that you're using?

Dan Romero: Managed by the user controlled application. So when you're using the Forecaster mobile app or the desktop client under the hood is an Ethereum wallet. And that's one of the reasons we actually create a new Ethereum wallet for every user. We just make the assumption that you don't have an Ethereum wallet. And even if you do have an Ethereum wallet, if you kind of just run through that architecture, I would suspect most people, if they have some sense for security, wouldn't download an application off the Internet and then just drop their mnemonic in it. So if you're not willing to do that from a security posture, the only way to effectively make sure Forecaster has the ability to sign every message that Ethereum addresses to just generate a new Ethereum address when you sign up.

Nicholas: So you're simultaneously solving two issues. One is I don't really want every time I tweet or like to have to sign a message for one. And for two, I also don't really want to be signing so many messages with a wallet that has anything of value in it in the first place, particularly if, let's say on a social network, my NFTs are in the same wallet that's associated with my posting. I don't really want to be constantly hitting that sign button. Just increases the surface area for a malicious website to trick me into signing away my board apes or what have you. So instead of signing directly with my wallet, you're creating a new wallet in the Forecaster app and it's being associated with my existing Ethereum wallet if I choose to. Is that right?

Dan Romero: A hundred percent. You couldn't say it better myself. So I think that if you actually just think through the security implications, teaching people to use their kind of like core wallet for every application to me is a ticking time bomb for security. You will do something at some point. And I think there was even a soft thread on either Twitter or Forecaster yesterday talking about how you can even sign a message, which I had always thought like, OK, if I sign a message that that's not an on-chain thing, but certain signed messages can actually delegate privileges or I didn't actually even have a chance to really digest it. But all the more reason that I think teaching people that, oh, yeah, you kind of mint an NFT in the hot wallet that you also have, you know, your really expensive NFTs and then also use that on social media. I think it just gets to a point where at some point someone's going to get phished and then you lose everything. And so for us, I think having a separate wallet that you can use in a kind of lower risk security environment for social media feels like the right tradeoff. And so I actually think we need as an industry to get better at just being able to manage multiple wallets. Right. If you've ever tried to manage multiple wallets in frankly any of the wallets, it's like barely functional. I think Rainbow does the best job of this. But MetaMask, like you can only import one mnemonic. Like I think for the average user, the idea that you can import a private key on MetaMask, but you can also have a root mnemonic is just like way too confusing. So obviously we've made a lot of progress, but there's still a lot of progress to be made. And so one of the things that I think behind the reasoning for building Farcaster as a wallet is we just have full editorial control of the user experience. And as you'll notice, if you use a Farcaster client, it's mostly abstracted away from you, right? Like you just use it and it feels like you're using a Web 2.0 social network, but the entire back end is decentralized and every action you're doing is cryptographically signed in a user controlled manner.

Nicholas: So basically the wallet is signing on my behalf every time I do any kind of interaction on the network. But it's doing that invisibly in the background. However, it's not custodial in the sense that it's not happening on a server somewhere. It's happening on my local client. I'm curious, how do you manage the connection? I created my account on the Mac app, but then I logged in on my phone. How is the connection made?

Dan Romero: You use the mnemonic to log in. OK, so you're logged in at the root level, both in your desktop app and your phone. Now, Farcaster V2, the kind of upgrade to the protocol that we've been working on most of this year that comes out this fall, it's going to have a slightly different model and it's actually improved security posture because here's the challenge. So we have a bunch of app developers who are building on Farcaster today. Farcaster's V1 protocol is very simple to permissionlessly index all of the content. And I see a couple of, you know, Katsuya and Zach are both in the chat. Like both have built, you know, multiple Farcaster apps and you can index all of the content pretty easily. But the ability to write content to the Farcaster protocol is actually quite difficult because the way the architecture is today, it's flat file hosted. We host the content on the user's behalf. Whereas in Farcaster V2, we're moving to this concept of delegated signing keys. And, you know, people's eyes in the crowd probably are rolling over. But the simplest way to describe this is what we've kind of come up with is this decentralized version of OAuth, which if you don't know what OAuth is, it's whenever you connect your Facebook account or your Google account to something or, you know, even Twitter, those centralized companies issue a cryptographic token to the app developer. Right. So if you sign in with, I don't know, Google into Airtable, Airtable now is able to maintain a connection between, you know, the Google service and Airtable. But Google has the right to revoke that at any point. Right. It's centralized. OAuth, by definition, is administered from a centralized entity. In Farcaster V2, what we're allowing is the user. Remember, every kind of core Farcaster client is a wallet. The user can actually delegate a new key, an app specific key to an app. So let's say I built, Zach was on the call and he built Instacaster, which is kind of like this Instagram built on top of the Farcaster dataset. In Farcaster V2, you could just kind of easily one click install Instacaster to your Farcaster, you know, just like account. And then when you use Instacaster, you're able to post back into the overall Farcaster protocol with this signing key. And that signing key is actually not an Ethereum address. So what's nice about that is it's even lower risk than having an Ethereum address with that app because that Zach is not taking security seriously. Let's say Zach's Instacaster, for whatever reason, got hacked. The worst thing that would happen would be that app, that key, someone could go post a bunch of content. But because I have a root key, my kind of core Farcaster wallet, I can revoke that key and all of those messages would go away. And so what you get is this really nice system where you're going to actually be willing to test out a whole bunch of Farcaster apps because you know that no one can go and steal your actual Farcaster username or your NFTs or anything of actual value. And then separately, all of those app developers, they can actually host that key on their server and not actually have to worry about being regulated. And so this is a thing that I learned at Coinbase is if you're actually holding an Ethereum address on behalf of the user in the state of New York, for example, you have to go get a bit license like that as a regulated activity. Whereas if I give you just kind of a standard cryptographic public private key. that again is like on the Farcaster protocol, like kind of linked to your core account, then that's no different than just any other way the way the Internet works. But in this case, we've done it in a centralized manner. So I know that was a lot, but I think that to summarize, one of the things that we've learned over the first year of our beta is we need to significantly improve the developer experience in a way that improves the default security posture for users so they don't even have to think about it, but also enables developers to actually have a really, really easy way for people to install an app that's kind of Farcaster enabled and then be able to contribute kind of like post likes or whatever back into the actual core Farcaster protocol.

Nicholas: Very cool. When is that launching?

Dan Romero: Probably in October, maybe November. But I think we're heads down on it right now. Working on it's all being built in public on our GitHub.

Nicholas: Awesome. Truly awesome. So I think what you're explaining with the Farcaster security posture is really interesting because as the popularity of sign in with Ethereum grows, this issue of connecting and signing with your one of your main or near main wallets becomes increasingly important. I'm curious, the Farcaster app experience, the main Farcaster app experience right now is very similar to Twitter. It feels a lot like Twitter, but I want to know more about these other apps and experiences that have been built on top of the protocol. What else is out there so far?

Dan Romero: Yeah, so I think maybe just to address the kind of core app feels like Twitter. I think we started out trying to make something that was different, you know, following the conventional wisdom that the next thing is going to be different than the first thing. Right. And what we found is that people said, oh yeah, I want to do something different. I don't want to actually use something like looks like Twitter. I'll just keep using Twitter. But the revealed preference is actually a lot of. the core functionality of what Twitter has today is, in my view, table stakes for building a social experience. And of all the social networks, Twitter is by far the simplest, right? It's kind of text based feed. Yeah. Twitter has all these additional features today, but the core of it is, you know, you type some text in a box, right? Right. In theory, Twitter is the only major social network you could build a command line client for. Right. And I think the table stakes social functionality that we finally have got to has enabled. There's a small number of people using forecaster today. It's roughly 2,500 people in the beta. 500, 600 people are using it every day. But there's enough conversational liquidity that I think you can attest to this. If you're on Forecaster, there's enough new posts and conversation happening that it's at least interesting enough to check the app. Right. Whereas a year ago, it was basically Varun, it was me and maybe two or three other people posting per day. And it was kind of like a more of a prototype. And so I think that the table stakes Twitter features have helped build a community of people who are using Forecaster every day, which I think then has made it more appealing for people to build apps on top of Forecaster. And again, a couple of the people on the chat here have built things. So Katsuya has actually built Forecaster News, which is a really interesting, it's essentially aggregating all of the links that are shared on Forecaster every day. Again, totally permissionlessly and showing them in a UI that looks much more akin to Hacker News. But what's cool about it is he doesn't have to worry about having people show up to Forecaster News to submit new links and do upvotes. He can just by kind of permissionlessly indexing everything, take the links and then see the ones that were shared the most plus the ones that had the most comments and likes and just pull all of that content in in a completely different UI paradigm. And so that I think is a really powerful example of you actually start to take a single pool of liquidity from a social standpoint and you can actually cut it in any way you want. Whereas, yes, in theory you could do that for Twitter, but Twitter doesn't actually give anyone for the most part access to the full firehose. So to actually have an accurate version of what the Hacker News of Twitter would be every day is I don't think possible unless Twitter actually wanted to build it or enable that set of APIs. Another app Zach has built is Instacaster, which again, relatively simple but I think very cool, is. he basically just takes every image that's been shared on Forecaster and presents it in an Instagram like UI. So if you're kind of less, I don't really want to read text right now, but I just kind of want to scroll all the images, which are a combination of people taking photos but also people sharing charts and the natural stuff that you'd see on Twitter. It's kind of a much more Pinterest like feel or Instagram like feel on top of the same data set. The last app that I am really excited about. I mean, there are a whole bunch of them, but Searchcaster is another great example. We don't have native search in Forecaster clients. Right. And so people have been asking since last year even, hey, I would love a way to be able to search all of the cats. Greg Squirloff, another developer, user of Forecaster, indexed everything, built a search engine and has added additional features on top of it. So Searchcaster.xyz. And again, it becomes this thing where Twitter could do this. And actually, if you go back to the early days, there was a company, Semise, which Twitter actually acquired and then created native search. But they don't give full access to the firehose. And a great example of this, just because I've played around with the Twitter API, Twitter's likes API only goes back to something like 3000 of your likes. So if you have 15000 likes or 10 years or something, there is no way to programmatically access the likes number 9000. Like they just don't support it in their API. And maybe they change that. But I think that, you know, I've been using Twitter for 15 plus years. I was an early Twitter developer. I built this app called Straw Poll, which was prior to native polls on Twitter. You could do text based polls and then we would summarize it. But, you know, I was in the era where Twitter was all about their API. And Paul Graham has this amazing essay he wrote in 2009. If you go to like paulgram.com slash Twitter dot html, he talks about how Twitter is basically one of the only companies he's ever seen that effectively captured a protocol or what should be an Internet protocol inside of a single company. And he's like, I'm not sure why that happened, but that is what's happened. And in that era of third party Twitter clients, there was a ton of innovation. Pull the refresh was invented by Lauren Brickner, who created Tweety, which ended up being acquired by Twitter and ended up becoming the default Twitter client, which now every app you think of pulled the refresh. But that was a Twitter UI invention from a third party developer. And then ultimately what happened is they had to shut the API down because they ended up having a competitor who wanted to go buy a bunch of Twitter clients and swap out Twitter. Bill Gross. But they also needed to monetize via apps and figuring out a way to monetize via third party ecosystem, at least in 2014, 2015 wasn't in the cards. Right. I think they kind of tried to pursue a strategy of being like Facebook, which I don't think has worked for them. But I think stepping back, ultimately, what's awesome about Forecaster for me is this ability for any developer, if they have an idea, they can go and just build it. And every single one of the apps built on Forecaster today, again, all pretty early, they didn't need an API key from us and frankly didn't even need permission.

Nicholas: We have public docs.

Dan Romero: They can go index all the content. And that, I think, is much more of the ethos of, frankly, WebOne and the broader idea of what the web is, is that Google is a great example of a company that is built on top of a decentralized network, which is the web and is a massive centralized company that indexes all of it. But the nice thing about the web is I don't need to use Google. I can use DuckDuckGo or I can use a URL in a browser and directly connect to a website. And Google is not somehow the only way that you can get around the web. Obviously, most people use it and it has a lot of influence. But I think that is a really powerful concept that, frankly, we've lost over the last 10 years. And I'd like to bring back with Forecaster, at least as it relates to social content.

Nicholas: Yeah, absolutely. I remember in the early years of Twitter, this feeling that it would become the database everyone would use. The API would be the best way to communicate anything that could be shared via a hyperlink or a short bit of text would be stored on Twitter. And our imagination was exploding with what you could do with it. And then ultimately, yeah, I guess through the tweet deck, the fear of a primary interface being acquired by a competitor and maybe some scaling issues. I don't know, maybe some monetization problems, preference over having the advertising model. I remember the limitations being placed on the API that caused tweet deck to shut down and or to limit their own growth. So I guess before we move on, like architecturally, Forecaster has data storage model that allows it to scale infinitely. Is that a fair assumption?

Dan Romero: Well, I think infinitely is always a bold claim, but I think what we're approaching with V2 is we've moved from so V1, all content today is hosted in flat file JSON blobs and they're kind of nested. So you have a high level blob. that's like called a directory. It's kind of your profile information. And then you have different nested blobs that are for your posts. But here's a good example. I have like 8000 Forecaster posts. When you try to open up my blob, it just like takes a while and it kind of has this massive, massive file. And so, yeah, you can do pagination, but then it's like, OK, what happens when you actually with these flat files, like every time you add a new cast, once you have pagination, it like bumps. So it actually is just kind of like a very clunky interface. So in V2, we've moved to this model that the best way to describe it is. it's like it's an Ethereum node and BitTorrent had a baby. That's what a Forecaster hub is. And so it's kind of this server that's dedicated for the Forecaster network. It'll be on GitHub. It'll be open source. You spin up a hub. It peers with all the other hubs kind of like BitTorrent and it will sync all of the entire kind of Forecaster universe. Now, at a certain point, that would become prohibitively, you know, storage expensive. But first, let's focus on we don't have that many people using the network today. Let's get this really great developer experience because now a developer can just run a hub and have the entire access to the kind of state of the network. And then naturally what you get out of this, though, is one, you can do sharding, right? You don't have to worry about double spends on the network because you can double spend on social media. I can type hello world and then type hello world again. And it doesn't actually cause a catastrophic loss of faith. Right. Like you can't do that with money, but it does allow for the ability to say, OK, these users are on this hub or, you know, you can have these models. And then I think that there's a second component where actually one of the default decisions we're going to make with hubs is we want them to, by definition, be focused on the present. And so there's going to be an ephemerality to hubs that would say maybe it holds the last 10,000 messages per user or maybe that even gets lower over time. And what I think it will allow is a marketplace of different service providers to say, hey, if you really want your old cast, right, which my personal view is most people should just delete their old tweets because old tweets tend to only like hurt you later, especially if you change your opinion. But then you didn't get rid of the old tweet. But I think that you will have people do backups. Right. So IPFS, ceramic, all are weave. You'll have paid versions and then you'll have nonprofit ones. Right. So if you're a person of influence, people will just back up permissionlessly your cast, which is provable because you've signed it to something that's equivalent to like the wayback machine for tests. And so I think that the network itself, because it is opinionated, will allow for other people to kind of solve the gaps.

Nicholas: Right now, I guess everything is running on one or a handful of hubs.

Dan Romero: Currently, we don't have hubs yet. So right now it's V1. The way to think about it right now is we just store everyone's blob like their JSON blob. It is a kind of flat file on our AWS S3 bucket. One of the things that I really pushed and Verun and I really believe is so V1 does work in a decentralized manner. We've had a few users who've basically built their own command line clients, self-hosted their blob, updated the record on chain, and then were able to kind of cast from their own, you know, not using any of our company's Merkle Manufacturing, not using a single Merkle Manufacturing API. So it does work in a decentralized way, but I think it is prohibitively and not practical for people to do that. Whereas I think in V2, we're going to see pretty quickly an ecosystem of, I think, to start basic clients, but it'll allow people to opt out of using a Merkle client or maybe use two different clients, right? Like they want to use their primary client, like they can do whatever. And then if they want to use the Merkle app, they can because the Merkle app can also have a delegated key. So it will kind of allow for you to kind of pick your own interface in the same way that you can have multiple browsers on your own computer.

Nicholas: Got it. Zach, welcome to the show.

Zach Terrell: Hey, how's it going?

Nicholas: Good. Maybe do you want to talk a little bit about the app you're making on top of Farcaster and what your developer experience has been so far?

Dan Romero: Yeah.

Zach Terrell: So Dan was mentioning Instacaster, which is an app that I built maybe a couple of months ago. It's so cool. Dan really nailed it. as far as like the developer experience. I made Instacaster in like two days, maybe. And like most of what you see it Instacaster.xyz is what I built. In that period, I'd change a couple of things. But yeah, it's insane that I don't even have to get an API key or get my API key revoked or buy some compute from Amazon or Google to go and index a bunch of data. You know, like it all exists on the protocol. So the data is already there. I just had to build a front end. And that's basically how we did it. I mean, Instacaster is just a proof of concept that you can build an Instagram type interface on top of Farcaster, which I think is legit. But yeah, that's one of the things that I worked on that Dan mentioned. Yeah, I'm working on a couple other apps as well. I just want to reiterate, like whenever you're developing on Farcaster, it's like this is the future. This is a future of development. Like this is a future of open source and everything. Like this is how it should be. Like all this data on this protocol. This is how the developer experience should be. We should be focused on, you know, tailoring user experiences and and, you know, manipulating data as opposed to, you know, fetching data and, you know, getting permission from APIs. Like that's not what we should be focused on. We should be focused on building, not getting permission, you know?

Nicholas: Absolutely. So typically you need an API key in order to, you know, alleviate like griefing of the service, people making too many requests and costing the service provider too much money. Who's hosting all these images right now?

Zach Terrell: Dan, if I'm not wrong, then it's you're hosting images on Imgur, right?

Dan Romero: Yeah. So again, I'm scarred from some of the kind of regulatory aspects of Coinbase in terms of there's just a lot of work to get right and you can't mess up on them. I think one of the things we wanted to be thoughtful about up front is if you have centralized image hosting, actually is the quickest way to get yourself regulated as a social media platform, because there are, at least in the US, there's very little text that's technically a label, right? Like First Amendment goes pretty far. There are images and I think everyone can kind of quickly figure out that if you are hosting those images and you have them, it's like just a whole headache in terms of just compliance. And one of the cool things is Imgur has an open API. So when you upload an image on Farcaster, we upload it to Imgur and then we just display that in line. And if you actually go back to the early days of Twitter, Twitter didn't have native image hosting. So there was TwitPic and a whole bunch of other companies. And of course, naturally for Twitter, it made sense to bring in images as kind of natively hosted. But I think one of the perks of having grown up in the early Twitter era is there are actually a lot of patterns that you can kind of use to help scale faster while also reducing the amount of overhead that you have to think about.

Nicholas: Yeah, Reddit did the same thing. Reddit also didn't host their own images or videos for the longest time.

Dan Romero: Exactly right. That's actually Imgur was the Reddit image hosting.

Nicholas: Right. And frankly, it was fine.

Dan Romero: Will that last forever? No. But I think like what I'm hoping is actually you'll have like the IPFSs, the ceramics of the world will actually say, hey, you know, you can install a kind of almost like a default search engine in your browser. It's like you can change it from DuckDuckGo to Google. You could change your default image upload to IPFS or ceramic or Imgur or another service that's paid. Right. And I think the more we can do where we create marketplaces for different services, at least in the early days, I actually think power users are fine with that. I think as you scale and eventually get more normie users and mainstream people, I think you're going to have to have a more kind of just like unified, simplified default experience. But I think we're ways away from that. And so for now, I think it works. I mean, it's kind of annoying, like GIFs don't work right now because like basically on mobile, you have to turn them into MP4s and it's like, OK, are we going to convert that? Maybe we could do it just through Giphy. But like, yeah, so I think that there are some downsides to this approach. But overall, we're trying to maintain the simplest surface area in our core product that we can and allow other people to add additional functionality. Search Caster being a good example of that.

Nicholas: If anybody else wants to come up and make a comment or ask a question, please feel free to request. I don't know if Zack, if you had any other thoughts you wanted to share in particular.

Zach Terrell: No, I mean, I came in a little bit late, but I think Dan nailed it.

Nicholas: Great. So there's an audience member, Joshua, at Exit Capital on Twitter and Farkaster, who provided a bunch of very interesting insider Farkaster questions. So I thought we could maybe go through a few of them. The simplest one, let's start with where does the name Farkaster come from?

Dan Romero: It's a reference to the book Hyperion by Dan Simmons, I think is how you say his name, not Simons. But it's just kind of like this portal to another part of the universe. And we were kind of trying to come up with names and Varun had just read the book and we thought it sounded kind of cool. And there's the broadcast sense of it, but also this idea that you can kind of be far reaching. So we kind of went with that. Farkaster is the protocol. I think we are going to as a company, we're a Merkle manufacturer. I think we're going to want to have some slightly different branding just because I think that naming the company that's building kind of like proprietary clients, right? It's like our clients belong to the company, whereas the Farkaster protocol is open source and kind of belongs to no one. It's kind of going to live on Ethereum and just be a protocol. I think we would like to have a little bit more delineation so that it doesn't feel like we're unfairly benefiting from that. So I think we'll rebrand at some point, but not for the foreseeable future.

Nicholas: Do you have any thoughts on monetization in terms of maintaining your ability to create the protocol and maintain it both for you and also for projects that build on top of the protocol?

Dan Romero: So I think about monetization in two ways.

Nicholas: You have the protocol and then the companies.

Dan Romero: Protocol, we are planning to charge for usernames and the way V2, in V1, usernames are the way you sign up. In V2, it's actually a slightly different model and for two reasons. So the first is people have actually wanted to upgrade their username on Farkaster. And right now, if you do that, you would lose all your followers, right? Because followers are assigned message that's user controlled so that you can't just go upgrade your username and have everyone redirect to you. It's like the client for each user would need to kind of do that. And so if you think about Twitter, the reason you can upgrade a username on Twitter is the way Twitter maps all followers and just how everything works is there's a. you are actually represented by an ID number in Twitter's database and a username is just a field. So in Farkaster V2, we actually have a concept of what we're calling an FID. It's like a globally unique identifier. It's just an integer, right? So each new person that signs up, it's kind of like if your old school ICQ just did this where it's like each new user, it's just like an incremented number. But underneath the hood at the protocol level, that's how you actually create the follow graph and map all the casts and everything that's happening. But then at the client level, usernames are useful. But usernames in Farkaster V2 are actually optional. So you can bring an ENS name in to Farkaster as long as you have that FID and you could just be represented on the network as your ENS. And so if someone replies you right at Nicholas.eth, it will just the notification, everything will work perfectly with that. And so what the Farkaster username will be is it'll just be really subtle. It just won't have the .eth at the end. Right. So it'll just kind of be like the canonical username. space in Farkaster will be the Farkaster namespace and usernames will be effectively. you pay for them yearly and that eth will go to the protocol. And I suspect people will who are serious about Farkaster will want a Farkaster username, whereas a more casual user may just use their ENS or something else. Right. And so I think that that also is important because it actually makes the Farkaster namespace have to actually compete, which is a good thing. Right. It can't be complacent and just kind of rent extract. And then I think in terms of the revenue that comes to clients, I think you're going to just see a variety of different business models. One of the things that Merkle Manufacturing with our clients is. we are going to implement subscriptions, I think, relatively early and put a certain set of what I would call power user features behind the paywall. And that, again, I think creates alignment with the users, because rather than having to worry about time spent in engagement because you're thinking about future monetization via ads, you actually worry about things like customer satisfaction or how much value you're driving for customers. So companies like Netflix and Amazon, I'd rather be thinking much more aligned with. how much more value can we be providing people. And then the last thing that we're going to manage for people who use the paid service with Farkaster or the Merkle clients is a recovery service. So if you, for whatever reason, lost your private key that's for your custody address, Farkaster v2 actually has what I think is a somewhat elegant on-chain recovery system. And what you would do is you'd actually delegate Merkle Manufacturing to be your kind of recovery agent. And then we would handle that for you. And so kind of. in that yearly subscription, you're getting kind of a security benefit as well as a kind of additional client feature benefits. But look, I imagine just like email, you're going to have free services that monetize via ads. You're going to have paid services that are more enterprise oriented. But what's nice about it is everyone can choose what kind of client they want to use. Right. Maybe you choose to use a client that's open source and it doesn't have as many of the kind of nice cloud features that a more paid service would have. But at the same time, you can actually be truly sovereign and not have to touch a corporate API. And I think that's important, too.

Nicholas: On the subject of actually two things. One, the record that's on that is controlled by your wallet that is on Ethereum establishes the association between your in the future version, your sort of user ID and username and wallet as well. Ethereum wallet as well. What all information is in that record that you can modify on Ethereum?

Dan Romero: Yeah. So to think about the FID record, it's just the integer and then the Ethereum address that currently owns it. And so when you follow someone, you're following the integer. Right. So if I then take that, if I want to change that Ethereum address, maybe I want to roll my keys for security reason. You can do that and you wouldn't lose your followers. Right. Same thing with the username. The username is just the kind of like 16 character, you know, limited to Latin alphabet. Right. Actually, one thing that's interesting about DNS is there are tons of potential for homoglyph attacks because of its compatibility with DNS. So I could use a slightly different Unicode version of N and make it look like I'm Nicholas. And if you're not a discerning user or your client hasn't done kind of homoglyph protection, I think you're susceptible to potentially impersonation and phishing. So think about like Twitter bots that impersonate with the display name. But now you're doing the username level. So I actually think like some of that stuff for social media is like really, really important to get right. And so the forecaster username space is extremely limited in terms of character scope. So it dramatically lowers the risk of homogloph attacks. But I think the username is just a username to Ethereum address. And again, you can remove the username and swap it in ENS or you could upgrade a username. And then magically what's happening underneath the protocol is once you are following an FID, the client hub, you know, dynamic is looking up, hey, what's the current username for that FID? Okay, great. So average user is never going to know about an FID. But I think it's an important distinction of if you actually think through some of the things that users care about, the ability to upgrade a username or change a username to do that. If you basically only have a single username as an NFT, that doesn't work. Right. You'd have to get people to resign. So maybe people say that's worth it. But I actually think this system allows for people to do something that people quite often do on Twitter. Right. You start out maybe less famous. You have a worse username. You get more famous. Maybe you have some money or as a company, you're able to go and acquire the better username. And to say people don't care about that is like that's patently false. People really do care about their usernames.

Nicholas: Totally. I think you said it there, but I'll also be able to reassociate my FID with a different Ethereum wallet if I choose to upgrade or change wallets.

Dan Romero: Right. Which again is an important thing that if you associate based on the wallet and then you have a security issue, obviously you want to be able to roll your wallet and not have your followers all get lost.

Nicholas: Absolutely. Soulbound tokens are going to have these problems.

Dan Romero: The other important thing about the FID that I didn't mention, it's gas only. So you don't pay to get an FID and you own it forever. Right. It's just an integer. And so and it's not meant to be kind of directly shown to users. It's kind of more of an underlying protocol thing. So the way to think about it is you can sign up for Farcaster. You pay gas, whatever. It's like a very, very de minimis gas fee for that contract. And then once you have that, you could use Farcaster forever and never, ever do another on-chain transaction, even if you didn't want a username.

Nicholas: Very cool. Joshua. Exit Capital mentions this question from Eric Thornburg and Josh Ellman about if you foresee some kind of Arab Spring event for Farcaster, kind of déclencheur, an event that makes the network become popular. Do you have any idea what that might be?

Dan Romero: I think I told Eric recently, he's a good friend, that the Arab Spring may not be the best example because that's a narrative that everyone got excited about. But the reality is, kind of look at the Arab Spring 10 years later, there wasn't actually that much fundamental change. In a lot of cases, there was regression. So I hope that we don't have something like that with Farcaster where it's like, talk about it, not actually being the case. That said, I don't, I mean, you can't anticipate the stuff, so maybe something like that happens. I am very much of the mind that this is going to be built more like Linux, where you just make incremental progress every single year and it will be developers coming up with new kind of use cases and just building stuff that will actually continue to grow the ecosystem forward. We're really focused with the Merkle clients on just continuing to onboard what I would call high quality, smart, curious builder types in Web3 to kind of be the seed group in this network. But the analogy I would use is for the whole 90s, once Linux came out, everyone kept saying this is the year of desktop Linux. Never happened. Right. And then Windows, it never replaced Windows. But today, Linux and Unix broadly has outcompeted Windows on a global scale because all mobile phones run on some version of Linux or Unix. And so I think that that is a, analogies are always tough, but that's an analogy that I like better in the sense that it's actually going to enable something completely new. And it's not about competing head to head with what exists today, but it's the foundation for what gets built in the future. And kind of what Zach had said when he came up, it says when you start to experience building a kind of social app in a completely permissionless way, there's no looking back. Right. And so I think that if we can continue to make week over week progress, month over month progress, year over year progress with growing the number of active users of Forecaster clients on the Forecaster protocol, I think that Forecaster as a protocol becomes more and more appealing to developers, especially as they start out. Right. It's like I want to experiment with the social idea. Getting a whole bunch of users to try something is really difficult. But if I build it on top of Forecaster, I already have a captive audience, whether it's I already have followers as like a Twitter like user or it's just the native distribution that happens within Forecaster is actually, you know, because of the permissionless aspect of it is I can push information into the feed in a way that there is no terms of service. Right. It comes down if users want to follow it or not. And a good example of this is there's an app being built on Forecaster right now called Pearl and a couple of Forecaster users, Alex Kwan and P. Kim, have been building it. And there are actually a bunch of users that are kind of annoyed right now by it because it's actually taking over the feed. Right. People are purling these different tasks as kind of a bookmarking system. And I think we'll solve something at the client level to kind of allow people who want to opt out of that. But it's also been an amazing distribution channel for them because now people see this, you know, handle and they're like, what's this? They click through. They see the app. They see other people doing it. So it actually kind of becomes this, I think, a really powerful flywheel of you build apps. There's distribution at this kind of native social protocol where people can actually show what apps they're using. And actually to go back to a Web 2 analog, which there's a funny story here, Facebook's is the company that came up with this term Open Graph for the web developers here. It's kind of how you do image previews if you share a link, right? Like you share a link on Twitter and there's like a nice big image that's using this thing called Open Graph, which was actually developed by Facebook. Right. But the original purpose of Open Graph was actually that everything you were going to do on the web. This is the era where there was a like button on every page, but also every song you listen to on Spotify or anything that you were doing was inevitably going to go back into your Facebook newsfeed and it was going to become a potential social interaction. Now, one thing I think users got overwhelmed with that, but I think you could solve this by having smart machine learning or some kind of smart defaults in the client. But also what happened was Facebook actually realized that that wasn't a strategy that they wanted to pursue and they effectively killed it overnight. So they rug pulled everyone who had been building into pushing information into Facebook because they realized it was kicking people out of Facebook. Right. Like Facebook's whole goal is to keep you in Facebook because that's where you'll see the most ads. But if you actually take that concept of Open Graph, I actually think that there's a way to do that in 2022 where giving users the choice on the types of apps they want to see in their feed. You can imagine Farcaster and there will be a bunch of different clients that will show this, but you can imagine Farcaster is when you open it up, you actually see what people are doing both on chain, but also what apps they're using in hopefully a tasteful and high signal way. And I think that that is an example where it was tried in Web 2, but because of the fundamental business model of Web 2 social networks, they kind of moved away from it. Whereas at the protocol level for Farcaster, the business model is you rent a username, so it's effectively you're renting access to the network. And at that point, clients can choose however, whatever experience they want to show people. And if you decide that you don't want to show those apps, but another client does, and that actually is what is appealing to users, people switch to that client.

Nicholas: Do you think of that in terms of, let's say I'm doing some kind of activity, I don't know, some NFT trading or DeFi or something, and I star an ENS on ENS.Vision, that information would then be if I simultaneously be logged into the website with my Farcaster and they would be publishing to Farcaster on my behalf, or rather the clients would

Dan Romero: be

Nicholas: proactively going and searching for things like activity on Ethereum in addition to the information that's published on Farcaster directly.

Dan Romero: So one area that I think we're going to continue to invest in over the next year in our clients is bringing on on-chain activity into your feed. And today we do this with NFTs. So kind of if you connect a wallet and you're following different people, if they mentioned NFT today, it comes in kind of almost like that Facebook news feed type story. I can imagine us doing more DeFi stuff, although I think DeFi and I think Joshua had a question around the idea of like privacy, which I'm happy to kind of chat about. But the idea is DeFi probably is not usually done from your ENS, because I think people tend to want to do that a little bit more privately. But today, for the most part, people use NFTs in a more public way. I think that Mirror is a great example of something that you sign in with your ENS. So your Mirror publication is actually associated with a kind of connected address to your Farcaster address. So you don't even need to log in with Farcaster. We can kind of just permission to pull that in. And that information is stored on our weave. So you can imagine us indexing what's happening on our weave based on the Ethereum address that you've connected to your Farcaster address. And this all just magically shows up in your feed in a kind of like permissionless way. And so I think that that is an area that we want to continue to lean into. And what I'm hoping is more developers figure out lightweight ways to publish information on chain, because then that actually allows us to pull that information in. Separately, if people just don't want to publish information on chain, but they want to publish it within Farcaster, that's what we're hoping with Farcaster V2 is it makes it really easy to publish any information as a developer into the Farcaster protocol, which then can be consumed by clients in the way that clients see fit. So it's this kind of hybrid on-chain, off-chain activity that all kind of starts to flow into Farcaster. And it's up to clients to figure out the best way to display it to users. On the privacy point, if you just want me to address that question. I read all the questions Joshua had. They were excellent. I think the privacy point is, the analogy I'm using is, I think that we are in the 2012 era of Instagram with public wallets, where in 2012, if you were using Instagram, you'd take a photo of your breakfast. It was like kind of like. it was a little bit more irreverence in terms of what you were posting on Instagram. It was more fun. And as the network got larger and people had more of their friends and colleagues or whatever on it, people naturally started to post fewer things, much more polished and kind of like the idealized self in the feed. And then the way they solved the kind of like, how do you get back to the more social irreverent version of Instagram was stories. And I think that that's probably what's going to happen with connected addresses. And so this is, I think, a general trend. is like today, everyone has all their NFTs and an ENS. Obviously, there are some security implications of that. Both in the, if you're using it as a hot wallet, like you might end up clicking something that has to get stolen. There's also just this idea that in some ways, like, you know, having a CryptoPunk in a wallet is, it's no different than putting a Ferrari in your Twitter profile saying, here's what my car is, right? It's, you know, expensive item. And so I actually think what we will see as the zero knowledge proof space develops is selective reveals of different kind of on-chain assets or credentials for the different apps and services that you use. Right. And so if you do a token get it experience that requires you to have a CryptoPunk, maybe you just actually say, I'm not going to tell you which CryptoPunk I have, but here's a ZK proof that I actually do own the address that owns a CryptoPunk right now. And I think that that will be more common. But I think we actually took a hard look at this last year and continue to talk to the folks at Xerox PARC and a couple other people working on this stuff. But I think that the technology will get there in the next two or three years in a way that users will have maximum control over what they want to reveal associated with their public identities. And I think that's a positive move. Now, to go back to my analogy, I don't know what the stories equivalent is. And maybe what you do is you kind of have like a burner wallet that you kind of have some NFTs that you're willing to publicly show. And then the more expensive ones you can selectively reveal or things like that.

Nicholas: Yeah, it's going to be very interesting. Everything you're saying makes me wonder what, because NFTs, of course, DeFi has culture, a culture to it also. that's very specific. But NFTs have really demonstrated the power of these kind of pop up. I mean, what is the Kobe thing? It's like all coins with pictures. I mean, in a way, yes. And I wonder if there will be applications of Farcaster, if some of that culture be it DeFi or any part of crypto, make use of Farcaster in a way that really breaks from these Web2 skeuomorphs by using the network to bootstrap some kind of new social experience that has a communications element where uncensorable messages are an advantage. I'm curious to see what happens there.

Dan Romero: Yeah. And I think what's what's amazing is we don't have to invent all of that. Right. So I think by having kind of these very open and permissionless primitives, we can allow other people to create new experiences that if something really takes off, like we can either consider to incorporate into our client. Although I do think one thing about building protocol is we have to be really disciplined as Merkle Manufactory to not go in anything that's working immediately added to our client, because the long term goal here is actually to build the protocol. And so we have to have a little bit more of a protocol steward mentality that we do think building the Merkle clients as kind of these like first class, world class, hopefully app experiences that help onboard people into the forecaster protocol. But there's a term in the Mac ecosystem called Sherlocking, where Apple will take like what other people are doing and then add it as a feature. And for the most part, that probably makes sense for Apple at this point, because the iPhone is super successful and frankly is not a protocol. But I think Windows actually Microsoft is not cool. But traditionally, Windows is actually a lot more outside of office. They were a lot better about not trying to go grab, you know, kind of the other areas of the app or the platform. Right. So a good example of this is like Adobe was able to build a massive business with Windows applications. Right. Yeah. Contrast that to Google, that Google at first had all of these search categories that allowed independent companies to be built. TripAdvisor being a great example. But then Ben Thompson has written extensively about this. As Google has kind of reached its kind of maturity in terms of total growth, they've had to go back to categories like TripAdvisor with travel or Yelp with reviews and build the native Google experiences that they could sell additional ad units that don't ever kick you to those websites. And actually, it's something I think about quite a bit. Right. The original ethos of Google was Google measured how fast you got off of Google. Right. It was like find something for you and then kick you out to a website. Whereas I would imagine now Google thinks a lot about like, how do we keep the answers that they give you when you ask a question? You just never leave the Google page. And I think a lot about that as it relates to Merkle and the protocol. Like we need to actually do a good job of allowing people to build independent, sustainable businesses. We're not taking this advantage that we have of kind of having built the first client and, you know, immediately incorporating anything working into our product.

Nicholas: Yeah. You see that with things like Google Amp. Totally. Even within Apple, you see this with their sort of mediocre service offering. Also ran music and etc. It starts to look like Amazon or Google. Everybody offers the same products. None of them is really stand out compared to the rest streaming services, etc. So even the services model, hopefully there is some distinction with offering the protocol as a service rather than, you know, trying to increase services revenue as the iPhone business sort of tops out in terms of how many people are willing to spend a thousand bucks on a phone every two years.

Dan Romero: Yeah, I think a good example of this is my friend Eric Stromberg at Bedrock Capital came up with this term humble giants and contrasting the kind of like major, you know, the Googles and Apples of the world to something like Shopify, where if you think about what Shopify is trying to do or Stripe, they're constantly going back to this idea of like driving value for customers. They are trying to enable independent businesses to just be better. Right. It's like every new feature that Shopify launches in theory should help their customers sell more e-commerce or Stripe, adding more features in the payment stack to just make payments that much simpler or offer more countries and things like that. And so I think of that mentality as like you can build a really big, meaningful business while still being incredibly aligned with your users. And in our case, we have both the kind of users of the Merkle apps, but also developers for the protocol. And I think having that mentality is really important because you think more long term rather than like, oh, what's a near term way to add more money or value to a given company?

Nicholas: Yeah, I've often been quite critical of Apple and their stewardship of the App Store, seeing themselves as really trying to control and limit what developers can do in terms of, and I understand it, of course, the most popular apps on the App Store are the greatest existential threats to Apple. Nevertheless, it feels like a very antagonistic relationship with their app developer ecosystem, not only in terms of integration like Sherlocking, but also just limiting what they're able to do. And you can see it in things like the difficulty of creating crypto apps on an iPhone or anything that's at all political even. And same thing with things like Visa and MasterCard limiting donations to WikiLeaks, etc., creating the conditions that gestate something like a crypto movement that becomes their primary competitor.

Dan Romero: Totally.

Nicholas: I want to know, is there, because everything is public and available, is there like a dashboard for user metrics that people can check out to understand how Forecaster is evolving?

Dan Romero: We actually have two, both community driven. Happy to kind of tweet at you the link so you can share it out after the show. But Trendcaster is one, and Castalytics is another one, both of which they indexed all the data. And now you can kind of use it to get analytics on your own account as well as the overall aggregate numbers for the network.

Nicholas: Very cool. And one last question from Joshua Exit Capital's thread of them. Implicit in what we've been talking about is that there is no opportunity for you to censor what messages are on the protocol in general. But I guess in the current stage, it is possible that in the wake of things like the Tornado Cash, I don't know, deplatforming, censoring, jailing, it is possible that messages be shared that hub operator or whatever you call the prototypical hub software that you're running currently be required to remove some kind of message. Has this come up yet? Have you put any thought into this?

Dan Romero: It hasn't come up yet. We've put a lot of thought into it, even though it hasn't come up. I think the way to think about it is right now. we're in a limited beta invite only. You kind of have to ask me on Twitter for an invite, which I think has been a good quality control. Generally, the community has been, I'd say, very civil, curious, optimistic. So there's not a lot of negativity on Farcaster. As we open it up, that will happen. Like, I'm not naive, but I suspect what will happen is there will be varying levels of censorship is one word. But fundamentally, if you can't actually censor the content at the core protocol level, then it's actually just more moderation is what I would say. So I think different clients will have different moderation policies. Right. I don't think the Merkle clients are going to want to allow people to be like harassing and just general assholes to people. There's some reasonable set of terms of service that you could put together. But the core difference is compared to something like Twitter. If we kick you off the Merkle client, you have the ability to go use your own client or another client. And so one of the things I'd like to get to is to have multiple clients in the ecosystem. So then we have a plausible story that if we say, hey, we don't want to support you on the Merkle client, you're free to go use the open source client and continue to post to people who want to follow you. Now, let's say you get to some level of speech there. I think there are seven or nine types of speech in the United States that are not protected by the First Amendment. Then I think that hub operators will probably have some set of policies that they want to follow, that they may choose to not index that content. At that point, I do still think that the user who's kind of in this situation has the ability to run their own hub. And as a result, people who want to find that person's content, it will be like finding someone's website. Right. So if you have deplorable content on your website to the point that Google doesn't want to index it, you're probably not going to get a lot of distribution. But for people who want to go to your website, they have the ability to go to the website. You as the website operator are liable and responsible for whatever content you have on that website. Right. So if you're in the United States and you have some stuff up there that is not protected by the First Amendment, again, a very high threshold. that's on you and your web host to deal with if there are legal ramifications. And so I think that that's probably what will happen with the network long term. I don't think we have to solve for this today, but I do think it will inevitably come up over the next year or two. And so I think just having that very clear set of like this is how it escalates. But at the core, you will always be able to be self-sovereign. And if you can do that, then you're responsible for the content that you're putting out. But in the same way that email has spam filters, that's moderation. I think clients will have their own moderation policies. But then what's important is you as a user, right? Let's say you're not putting the content out there that a client doesn't want to support. You can make the decision to say, hey, I think this client is actually not censoring too much content that I'm interested in. You may either. OK, I'm going to use this client for this and then I'm going to use an open source client for the accounts that it's not willing to deal with. Or you might vote with your feet and say, I'm going to use a client that's actually more free speech oriented. And I think that that is completely fine and actually very desirable because what you have is a natural market force on every client to say, we're going to have to try to have the most reasonable moderation policy that applies to the largest group of people.

Nicholas: If that's what you're going for. Have you seen anybody do any kind of tagging of the messages so that clients can sort them into, I don't know, like the Pearl example you mentioned earlier, like only showing just tagged with a certain or not showing those?

Dan Romero: Well, I think Instacast was a great example of this, right? It just essentially goes through the entire index and looks for any cast with an image. I would imagine we're going to see a bunch more apps once V2 ships. There's a metadata concept so that clients could actually add kind of like, again, invisible from the actual cast text, but behind the scenes. that makes it easier to categorize things. So I would imagine we're going to see a bunch of that later next year.

Nicholas: Have you seen anybody do? We spent a lot of time talking about all the advantages of not having your wallet directly in the app all the time, but have you seen anybody do like an NFT purchase inside of a cast?

Dan Romero: Not yet, but I think part of the long term roadmap is if we continue to have the core Forecaster clients as wallets, there's nothing stopping you from loading some ETH into that wallet and being able to then have kind of like in-feed commerce. that's like one click, right? I think where our hesitation to do that today is just like that's a bigger security posture, right? If people start loading real value into their Forecaster address outside of their Forecaster username, I think we're a team of six right now. Like having been at Coinbase, we take security really seriously. And so that was to become a normal behavior, I think would have to spend a lot more time on security and not spend time on security.

Nicholas: What about a version instead where I'm using my regular Ethereum wallet to execute the transaction, but the buy and return issue?

Dan Romero: I think that would be much more likely in the near term. So you can imagine there's actually kind of this interesting, Twitter has some of these ideas and they never kind of like really push them. Twitter had this idea that if you use, prior to them launching their newsletter service, there was a certain set of newsletter services, this is pre-substack, where you could actually add a little meta tag in the HTML, which would allow Twitter to create this like little card that would allow you to one click subscribe from Twitter. And I would imagine us having something similar, whether that's a newsletter or drop your ENS or some of these behaviors that you see on Twitter, where it would allow you to kind of take a one click action. And maybe one of those one click actions is like mint, right? And so it'd kick you out to your, you know, desired wallet, rainbow, meta mask, whatever, and then you'd be able to do that, you know, two more taps, right?

Nicholas: Yeah, definitely. One last question comes to mind. I've seen some like people who are huge influencers on Twitter, who are on Farcaster, who haven't been as active in the last several months. I'm curious, do you find that the people who are the most engaged are people who are like almost native Farcaster, not celebrities, but who are more popular, maybe even on Farcaster than they are, or have a tighter knit community on Farcaster than on Twitter?

Dan Romero: Eugene Way's essay, Status as a Service, I had read it before working on Farcaster, and I don't think I had it internalized some of these concepts, but now two years into working on Farcaster, I think it's largely correct, 100% correct way you want to say that. Once you have status on another social network, it's extremely difficult for you to want to go back and start from ground zero. Now, if you're a big enough celebrity, right, if Elon joins Farcaster, everyone would follow him immediately. But I think as Farcaster continues to grow, the people who are Farcaster native are going to continue to grow their audiences because they are actually actively participating in the community. And Eugene Way, actually, he's not a crypto guy, but he uses Bitcoin proof of work as the analogy here of it shows proof of work, right? It's like you've invested time in the community, so therefore people are actually willing to follow you. And so what I'm excited is, is actually most of the people on the Farcaster trending list, which I think is roughly correlated with who's most active as well as like kind of generating conversations and things like that. I would say it's like 95% of the people in the top 100 I didn't know last year, right? I like when I first started onboarding people, all of my Twitter friends like biology and those folks, they have huge audiences on Twitter. So despite them being interested in decentralized social media, practically, it doesn't make sense for them to switch over because they have so much more reach on Twitter. Whereas I think the folks on Farcaster, they might have had fewer followers on Twitter and they natively clicked with the community earlier. And so they're actually the ones who are most active in building audiences. And I think that's terrific. It's like you're actually starting to get a differentiated social graph on Farcaster, which fast forward a year or two, then even if people say, oh, this looks too much like Twitter, I can intellectually honestly say, well, it's a completely different set of people and different set of content and norms and things like that. And I think that's actually pretty powerful.

Nicholas: Dan, it's been wonderful talking to you. I'm super excited about Farcaster and really excited to see these crossover integrations between sort of crypto culture and buying culture and things that the traditional social networks and app platforms just won't let us do. The Farcaster just might. It's going to be exciting.

Dan Romero: Terrific. Well, thanks for having me.

Nicholas: Yeah. Thanks so much. And thanks everyone for coming to hang out and see you next week. I look forward to seeing you there.