Leggo My Legos – Panel Discussion

thank you all for coming this panel named by Matlock here is named leggo my Legos and is largely about how we build composable applications in the blockchain ecosystem and how that differs from the way that blockchain or other applications in the past have been built and on the panel today we have a variety of different projects each of which we think captures a different aspect of what it means for us to have a composable ecosystem whether that's a dev tooling whether that's domains whether that's kyc so what I'll do me first is just go around here and have everyone do a quick introduction tell us a bit about just your name the project and through what you're excited about in sort of 2020 with your own ecosystems and for my itself to start my name is Scott Moore I work on the get Coyne team we do public goods funding and open source funding mainly in web 3 and I'm really excited about the future of quadratic funding hi everybody I am Brad I'm co-founder at unstoppable domains we are a blockchain domain registry and we also build tools for decentralized websites so the idea is that we want a free and open Internet that cannot be censored we think anybody in the world should be able to publish and say what they want on the internet without censorship and right now the current Internet has two major points of censorship one is domains GoDaddy or whoever your domain registrar is can take you two main away from you and Amazon Web Services can turn off your web in five minutes and they do and it happens so if you move your domain name onto a blockchain and you move your storage onto ipfs or another decentralized storage network you you solve this problem hey everybody my name is Kevin Seagraves I'm a founder and head of product at a company called charge big headline is charge is credit cards that can't be stolen so thinking about e-commerce and more traditional payments in this space we are providing credit cards on the blockchain so any digital good where that's an NF T or a service you can now fiat in fiat out and then leverage blockchain values without having to go through all of the rigmarole of UX and buying gas or buying crypto and paying for gas etc that's three products so that's a payment processor that is a user Wallet app and that's a kyc module so kyc we think being a big component that this ecosystem can benefit from as well hi I'm you neva co-founder at the graph we're an indexing and query protocol for web 3 so we index data from atheria by PFS and make it really easy to query that data using graph QL so we launched a hosted service over a year ago and we've got really cool projects using in a production like unis flop down stack Aragon Moloch gnosis a bunch of others and we're going to be launching our decentralized network later this year nonprofits reaming projects we also have one name for all your crypto currency wallet that also can't be similar to the mains we also supply best websites warm websites Cortana need addresses arbitrary information with text records by even DNS records we'll need to bring the same security to DNS records as well we are integrated in over a hundred wallets Dax person farmer and with textile dye oh and we develop developer tools on top of ID FS and other decentralized technologies we provide a bunch protocols and database tooling and libraries across desktop server browser and mobile and across languages go and JavaScript and other things and the goal is basically to make it easier for developers to develop web 3 technologies particularly on top of IP FS to the point where you can use ipfs without really happy to know that you're using IP offense or anything particularly fancy that's what we do oh and I'm excited I'm excited about the explosive growth development that I think we're going to see over the next couple of years due to a lot of the tool building and building block success that we're seeing over the last couple of years but even just once awesome so we wanted I think maybe give some context here for the audience unlike what we mean by and I gave a bit of this earlier but like what we mean by composability what we mean by like the idea of building blocks in the first place so for you maybe just we can go around or anyone who has like a particular opinion on this first off what does it mean for something to be composable what does it mean to be a building block and web 3 versus in sort of the traditional software webtoon ecosystem and how do you feel like that approach is is enhancing web 3 over and above how that's changed in web 2 so for example you know obviously back in the early 90s being able to build on a you would pretty much build everything from scratch then we got like the nodejs ecosystem we got package managers we got all these things they made it a lot easier to I think kind of work within an ecosystem that's already built for you how does that apply in your context in your and your sort of ecosystem yeah this a bit I can't really hear YouTube all actually either yeah yeah you probably heard me okay so we can start there and then maybe you'll get context from there yeah you can just copy me so the question was around like how you think about extensibility and building blocks and web 3 versus went to so for us for us you know a domain name is a key part of a website it's a key part of a website and web 2 as is in web 3 so domain names are just relevant to every application in fact if you're adapt and you're building you know trying to build censorship resistant tools or whatever they're not fully censorship resistant if you aren't if you don't have your domain name on a blockchain and if you don't have your content on ipfs or somewhere else like that something that we just launched here actually you may see some Flyers is an IP FS template marketplace so we want I P FS developers to be able to sell their wares on our website we have 200,000 domains registered we have around 20,000 users they have high intent to build an IP FS website because they just bought a blockchain domain name and so we're in the process of integrating tools and that's gonna be way easier than it would be in web to you know web do you have Shopify marketplace you'd have an application process you'd have setting up with credit card operators all that sort of stuff now you can just make a pull request to an open source repo we accept you can take ether you can take die you can get paid it's way easier so I think from our perspective it's gonna be way easier to have developer marketplaces and all the stuff is just sort of connect together yeah so I think a building block for my perspective is really it's an abstraction right so it's making things easier to either use or implement so whether that's building a you know easier to use interface for ipfs so you so you're you know you have a CLI command that's now creating distributed storage or that's abstract in a way like private keys like so our wallet tech we have a s CK that now you can you know you make some make some simple calls integrate with our platform and now you can actually have a you know a self-confident users so they don't know they're using blockchain but they can leverage value propositions of blockchain so just as an example so it's really yeah that abstraction so composability is all about reuse right so as the developer you don't have to build everything from scratch you can just pick up already made components in JavaScript I think there's really good you reuse of code already and in other ecosystems as well but what we don't have is really great reuse of data it's the way that you do reuse of data and composability in web 2 is over api's and the problem is you have to depend these api's that you're using so you know every time you want to use an API you have to decide do I trust this company to continue to be around to you know manage that service the way that I want that agrees with you know my community and you're taking on a lot of risk and so I think the composability that we're seeing that's new with web 3 is composability around reusable data and services so that it's actually you know the instance of the networks that we're building the liquidity all of these things that are also shared and reusable across services in a dependable way yeah so I mean there's different meanings of composability here I think some great I think what most miners say to people space is you have different like doubt protocols there are smart contracts on atheria that can interact with each other permission asleep right so I can I can build a dab some subset of smart contracts that interacts with someone else's says smart contracts without even talking without having to know them I can't even take this a smart contract and connect it to this one and build these things together into a smart contract system and a great thing about ENS of course it's on etherium so has all the benefits of composability your names on ENS are ERC 7:21 n ft compliant so it fits right into any heading any n ft marketplace or system right right away you can also have contracts own DNS names and do things to things automatically this also creates interesting situations that are not possible of the traditional DNS system for example you have names that nobody owns so you can actually register a name set up the records and then give control to a contract that now it owns it with the name still functional that's incredible thing you can have names do automatically let's say change ownership or change their resolver or change their contract based on other events on a scenario even that have nothing to do with me I think that is a fascinating kind of revolutionary feature so so in us being our theory of benefits from all doctor feasibility yeah I mean talking about I think usually I think about composability a pretty broad level and your example of the NPM well it's highly centralized system but the fact that we have all these modules that can be combined the ways that the original developers couldn't possibly have imagined and in fact you know there's no point in imagining that's the whole point of two building block building is that the ultimate thing that you build with it you you know but one of the sort of important things to keep in mind I think in terms of sort of reinforcing composability and reinforcing the reuse of your projects is designing interfaces and designing tooling that really makes it so that you can't you know the sort of example of web 2 api's that could just shut down any day you know what we have sort of immutable ledgers based data sets that you know are gonna be there and I could decide you know what I'm actually not gonna update to a new version or worry about I'm gonna stick with this immutable well-established universal - and you know my product works really well I never have to sort of change my tooling that I build on top of that I don't need to worry about it going away I don't need to worry about it upgrading under my feet I don't need to worry about something removing their package from NPM because it's it's there it's backed up in a nice way and so that's you know that's like that's an assurance that you cannot possibly have without web technologies and you know for our team we get really excited about all the cool things that people are be implementing in web 3 but we get really excited about the things that people are building in webs me that they couldn't have possibly built you know last year or two ago even if they could have thought it up you know like that's what that's where things get exciting is you couldn't build that until there was a public ledger or at a beautiful data store to back that up that's where things say that's where building blocks get excited can it can I do one more point yeah just like the ERC standard process I think it's actually a really valuable composability feature set of Athenian eco system like the fact that we have a or C 20 I know like 600,000 D arcy 20 contracts exists like that's a really impressive successful piece of software that people were replicate were able to replicate in and create value with that was just like a plug-and-play component right and like we saw it with when I was on the get coin team go and get coin grants like with one one three three seven the lead standard doing subscriptions in the blockchain we now have a sustainable business model that can be reimplemented and apps that is you know it did is plug and play it is composable and that has a lot of value I think that's a really interesting point like so there's a trade-off here in some sense or maybe it's not necessarily a trade-off I'd be curious to get everyone's perspective on this between having really strong standards and having these composable kind of atomic units and being able to make kind of on-the-fly changes and iterate on on your code base in a rapid way potentially so going to the aresty 20 standard again like there is definitely a really big benefit to having that at the same time it does restrict how we're able to use tokens as especially given that most of them are years to 20 in the 3m ecosystem in particular so how do you view those trade-offs with your own products and how do you see that evolving in sort of the coming years we think the standards are important so we use the RSC 721 tokens all domains or GRC 721 tokens because that's what's already supported in a lot of apps so and there's a lot of other companies using it so it was kind of a no-brainer for for us to do that so we we think it would be a little bit hard to to innovate on a standard if we're focused on ecosystem integrations and connecting in so it's a easy decision for us I think it's hard to start with standards you know if if you could always just develop perfect software the first time then it would be easy but sometimes I see people try to start there where you know they try to get four or five teams together hey let's collaborate on a standard everybody wants to pull in a different direction and you're always talking and you're never shipping and you know I think sometimes we take the track of you know why don't you just launch something see how it does learn from it and once it proves itself then you could have a conversation about okay this seems to be a really good way to do it can we kind of start to standardize on on something that's working that's on the mind of our team is you know the sort of the exciting thing is like let's design this thing so that does everything that we're going to need and everything we're gonna need in the future too but ultimately you know at the end of day you're like can I design an interface that is sufficiently generic that it's useful and that I can upgrade it or you know build something else on it moving forward but that I can actually use tomorrow and that people are gonna play around with it enjoy it like there are certain ways to be super pragmatic about that you know using like graph based structures and things like that are very very nice because they're very flexible but it doesn't work for all situations so being sort of very pragmatic about just getting something that works iterating on it quickly establish I'm Ian Zack Chua Lee do is become a standard is because there was actually quite a bit of iteration there weren't quite a lot of proposals that preceeded ended up standardizing on as an industry so you know I think that's a 100 percent right now we're at this sort of very exciting Wild West and web 3 and you know the best thing to do is play around find out what works and establish sub communities of standardization and I think that's what we're doing and I think we're doing a pretty good job awesome so each of you have I think very distinct applications with the exception on the stage of - domain name services unstoppable domains nina's so just in the interest of giving clarity for the audience do you have maybe just give a minute to describe sort of why you made the design choices you have with each of your your sister tools and how you see your role in the ecosystem not silly relative to each other but just through your own internal design choices yeah so I mean I think in general the most important thing to keep in mind is that the competition here is the traditional DNS industry which is calm 50 billion plus anything that's happening in the blockchain world is relatively small also in the treshold world you have lots of different registries so it's very likely that you're going to see more than one company more than one registry more than one player and as long as it's interoperable I don't really see why that would be a detriment I guess you know sort of in relation to us versus versus ENS so we actually built the first version of our app as a demo app on on DNS and we decided to build our own registry to solve I would say two main problems one is that we think that subscriptions which exists in the traditional DNS world are unnecessary so you know you have a blockchain asset you know what to pay a subscription on it there's no opportunity for it to be taken away from you for any reason and subscriptions have an attack vector so the registry can raise the prices or somebody can lean on the registry to raise the prices like a government and in the traditional world this has happened a lot calm is jacked up their prices or 3x their prices so the risk on the subscription side to a user if you have a domain name especially if you have one that is meant to have a censorship resistant website they might piss people off you wouldn't want to have subscriptions so it's unnecessary in the blockchain world it exists because there's a centralized party in the traditional world to pay the subscriptions so we eliminated that and then the other thing is around making sure that domain names get to the right people so you have this problem with the traditional world around brands and brand protection so let's say you have coinbase coinbase comm you know coinbase is established itself as a brand you wouldn't want a scammer or somebody else to get that domain so there's a there's a kind of big process in the trishal domain name world to make sure that companies can claim their domains first this was not done with with dotty and so there's a whole bunch of people that own company names so we went through a process of validating trademarks and trying to make sure that those brands get those domains and they can't be registered by anybody else once you have the domain itself custody but we try to be pretty careful about who we distribute the domain to in the first place so that we don't wind up with a namespace that has a bunch of fishing this away no great so I'll respond to some of those things our perspective on that and I'll mention some other things as well the first thing you said annual fees so I I just I disagree I think actually that the primary purpose of annual fees is anti squatting so if you have just one payment up front and then no ongoing fee that original payment is a sunk cost and so it has no anti squatting effect at all in fact I would say if that's your philosophy you have little need for fees to begin with your fuse could actually be very low just to register at one time so the reason we have ongoing fees is because it's an anti squatting mechanism we want it if you're not using the name if you're not getting value out of it you know release it let somebody else use it free up the names in terms of the security problem our our solution to that terms if you know because you forget to renew it or something like that is that you can renew ahead as much as you want so if you want to have it for five years so let's say it's five dollars a year for most names if you want it for one year it's five dollars if you want to secure for four for five then it's twenty-five or if you want it for a hundred years which is basically forever right that's $500 $500 so you have to pay more for that so there's an incentive that okay are you really gonna get value out of this or not so that's our reasoning there in terms of the name space that's true in terms of da teef for for names that were seven characters and greater we didn't have a sunrise period we had an auction system at that time we that was decided that was the most fair way to go about doing it for shorter names we did have a short sunrays so period although we didn't completely completely reserve trademarks indefinitely our philosophy about that is that da teef is primarily going to be used in the blockchain community by aetherium gaps that most brands aren't going to be concerned about it and in fact the way that we're expanding the namespace on our systems that were integrating the existing DNS namespace so we have da teef as sort of a demonstration of the full capabilities of a blockchain native name and I think the blockchain community is most interested in that but you can get most of but not all but most of the benefits if you just use your DNS name on ENS we already have that with XYZ luxe cred art in da club and we're gonna be rolling that out to the full DNS namespace here very soon so what that means is if you have Brantley com pretty soon you will be able to send Bitcoin to brently comm and it will be using ENS and aetherium in the background and like I said that will work on the over 100 adapts and wallets that were integrated in and and in the last point I want to make and I think this is another kind of fundamental difference in our strategy is our approach to the traditional DNS space and in industry our our approach is we don't want to fight it we want to upgrade the the tech stack for DNS we don't want to challenge the processes that been built up over the last two to three decades for the management of that namespace we want to respect that we think that's best for users we also think that it's most likely to succeed and I think that's not an approach that unstoppable domains has been taking about awesome I will I have a lot of questions there but I will leave them as we only have a little bit of time left so I wanted me to jump to you need for a minute you talked about obviously the graph is very much focused on trying to provide data validity how do you see your approach to date availability differing from what's existed in what to you know and what maybe exists with other products in the space and what do you sort see is like the most interesting use cases for the graph today so I don't exactly think of us as the daily data availability solution I think of the underlying networks that we support as the data availability layer and then we're like indexing that data and making it efficiently available to applications so you know as far as composability there's a lot of extra work that you need to do to make data readily available to an application to index it to organize it so that you can just run a query and get back whatever data you want really quickly so that work before the graph came along people were writing a lot of custom code and in web 3 that to me is kind of like a code smell where you say hey this is supposed to be dependable infrastructure that we can all use and there's you know a thousands of lines of code that's sitting on some server somewhere that somebody wrote you know in a hurry and and deployed and and I'm supposed to depend on that so what we did was we kind of standardized that process with this abstraction called a sub graph that defines how to index some portion of the graph and then make it available as an open decentralized permissionless API and what we hope is that more and more data is going to move to web 3 and in a decentralized way all of the developers around the world can collaborate on curating these decentralized api's coming to agreement on schemas for how that data should be organized and queried and linked to each other so we can have a global graph API on top of all of this web 3 data that'll just make it way easier for developers to build applications awesome one question just on dev tooling versus composability so for e IC dev tooling is like a fundamental good it seems like I think to me it seems like much more tangibly beneficial in both web 2 and web 3 whereas we see composability being I think discussed more actively you know in web 3 context principally how do you see dev tooling as I guess distinct from web 2 into web 3 and how do you approach that in the ipfs ecosystem yeah that's a great question and I think you know in a lot of lot of cases dev tooling is really just building it ends up in like bridges from sort of existing web 2 technologies on to you know web 3 platforms so you know a big example is I don't know how many of the gaps that are built here are built either you know using reactor view or something like that these are you know frameworks that people like that they were that work really but well there are a lot of investment in dev tooling that went into that but you know the way that those applications are deployed are very much designed for a web to like address or location based addressing type system so I mean we were just having a conversation about 30 seconds before this panel started about someone who was trying to deploy a view app on to ipfs and the whole thing sort of fell flat on its face because you know there's sort of fundamentally different ways of referencing information and data on the web and you know there are ways to work around that so a big piece of like building web 3 tech dev tooling is just building web 3 native tooling that is designed to work with you know content addressing is designed to work with you know data that needs to maybe be synced before it could be processed or data that is already distributed so those you know those tools need to be designed so that they can actually be deployed you know send information back or you know do some of the indexing locally so a lot of the that sort of developer tooling a lot of things that we spend time on are trying to make sort of native web three technologies either work on top of existing web 2 stacks or just say look that we're not doing that anymore that's not you know we can actually build a better product by just focusing on native web 3 technologies and that's we spend a lot of time thinking about that it and just one like definition that I'd like to kind of put out there is the difference between developer tools and infrastructure all right so there's a lot of developer tools which is really about making it easier to build applications and that's really important and we need a lot of that and sometimes I see confusion between that and infrastructure which you know I think of as being what the software actually runs on and so you know dev tools I think it's really fine if it's not like decentralized or a lot of times you know it can just be a local CLI it can be some South product that you're using and that's ok whereas for the infrastructure that's where it's really important that it's running on a decentralized network so you don't have these single points of failure so I really wanted to ask one last question the idea of kyc in this ecosystem I think we're just out of time though and I want to maybe do one quick round of like and this maybe tie into that what you're most excited about in 2020 for your particular projects and for that you could system at large and then maybe we can figure out a way to talk about kyc text very briefly so just me 10 seconds 20 seconds each so we're most excited about real decentralized websites and we think 2020 is the year where it's going to happen there's a lot of people building interesting stuff on ipfs and we're seeing the tooling get better we're seeing the apps get better so we think we think that the world's going to be able to get up get a peek at what the decentralized web actually looks like in 2020 and I don't think that was really true prior years I'm really excited about usability so we started out our thesis of how can we make this easier for normal people to leverage goods and services on a blockchain so using a credit card is a really good UX people are familiar with that in order to interface with this traditional financial system but still leverage value props of the blockchain we have to use kyc so where we have you know crypt we actually signed in credit cards moving that value onto a blockchain via the settlement system leveraging buying n FTS or perhaps a grant on grantor bounty on get coin and knowing that the customer is the ultimate beneficiary with kyc product I think 2020 is going to be a year that web 3 really becomes real so there's a lot of really exciting new protocols that are going to be launching and both in terms of you know underlying protocols and applications I think we're gonna see a lot of exciting products launch and get traction yeah I'm also excited about the large growth size web which we already have a lot of the pieces in DNS where they have a search engine we already have multiple browser integrations we are a have lots of websites using our system and ipfs us we already have that and I think that's gonna explode this year we also have some new things coming out on that also full DNS namespace integration to work on ENS very excited I think we're most excited about the fact that the last few years have seen a lot of rapid development and sort of tools maturing and I think 2020 the thing we're really excited about is all of these building blocks are now at the point where we can actually start using each other's building blocks and sort of really explosive growth of that so you know half the people on this panel I want to have a meeting with them afterwards say hey look I really want to build this let's do it and I think that's 2020 is the year where that's really where we're comfortable with our tools that we built and we wanted to start using it's been years in the making awesome love the optimism thank you so much everyone Cheers have a great one cuz everybody and enjoy the rest of the yesterday in rest panels [Applause] [Music] you [Music]