John O'Sullivan ~ Web2 Users in a Web3 World

[Music] foreign version the latest LTS which would be in the 10.15 series I do not at this time recommend a node version 11 install there are some API compatibility problems with the node.js standard Library um you would need developer tools on your machine so if you're on Mac OS that would be xcode for example uh if you're on Linux you would do uh it was a Debian distro you'd all right guys coming up we got John O'Sullivan from inbrex talking about web 2 users in a web 3 world or a tale of two webs how's everyone doing good excellent perfect so my name is John Sullivan just to get a poll how many people here are coders just raise your hand okay I like that how many people are here for more of the ux UI experience kind of talk even better cool so my name is John Sullivan so just to quickly introduce myself um I work at inbrex I work primarily on our back end managing uh our servers kind of working with our smart contracts and a lot mostly our data a little bit about me I'm really passionate about decentralized systems as well as how we can scale them but also bring them to the mainstream so getting our web 2 users into that web3 environment and on the side I'm kind of dabbling blockchain and iot and how we can kind of bring that to the mainstream my email Twitter and GitHub link is there if you'd like to check me out go for it so what is the problem well the problem is this in the real estate industry as it stands there is a lot of inefficiency when it comes to data and how we kind of take a listing once it's created and bring it to closing and this is due to bottlenecks bottlenecks geographically if you're to sell property in let's say New York versus in London and you the tools that you have to use for those two areas give a restriction to what data and what you can actually do with it uh transmission failures so different ways of sending that data if it's different fail and prevent you from having accurate data Acres API calls which can break the flow of data giving you again inaccurate data siled data which we can think of like our Facebooks our Googles and stuff where you have silos of listing data that data let's say you have one two three Apple Street on Zillow and it was updated yesterday and then I updated this morning it's updated on our site but it doesn't get updated on Zillow right away that's a problem because a lot of people who know Zillow I think we all know Zillow right everyone will go to Zillow first and see oh this price is too high but I lowered the price this morning to get more you know more leads and it just doesn't work out and on top of that we have a difference in how we standardize the data and actually transmit it with different networking protocols so for example an agent will have to go through either one or many of these tools just to get a listing from its creation to its settlement they would have to go through different mls's different crms and different ways of actually transmitting documents to get to that point where they can say hey here's our deal let's close and it's very inefficient so to kind of better represent how this looks I have this diagram so as you can see here all these different um let's call them portals are not sharing the same information they're actually relying on their own feed of information which is very inaccurate so if we were to go from let's say Zillow down there and we wanted to go to like Zip logic or like to uh property manager we would have to manually either email the data or like send it some other way but actually manually enter it into that system which is inefficient and can lead to discrepancies so what is our solution to this well we need a solution that is um pretty much built on top the idea of web3 it needs to be internationally available so that if I'm in New York and let's say I put a listing on New York let's say on let's say Broadway Street and someone in London's like ah I need to I want to buy some property in New York they can get the most real-time data to actually go and actually move forward with the transaction on purchasing that property so it has to be internationally available it has to be taught following that's a big thing and on top of that it needs to be censorship resistant as you get different types of data certain parts of it you want to share but certain parts people don't want to share like for on for example on Zillow if you've ever gone to Zillow you'll see that certain parts of the information is hidden and restricted which is not good because if I wanted to go on zillion I wanted to get the most up-to-date information the most accurate I'm not getting it it's slightly restricted we don't want that and on top of that we want one source of Truth so that if I want to get sell my property in New York and let's say I put it up for half a million dollars and then I realize tomorrow I need to sell it I'm going to knock off you know a couple uh let's say a couple thousand that anyone around the world will get that update in real time and say okay this might seem like a more reasonable offer so what's this look like well let me let me go back for a second interoperability is kind of the key here between these systems as you saw before we had all these different portals that weren't really communicating with each other so interoperability between these internal internal internal to external and external to external systems is very important and if we can get those uh systems to talk to each other we can have a more efficient way of transacting real estate data and going from creation to settlement on top of that we need to think about the data itself how many people have ever seen a real estate listing online who's actually gone and looked at property what kind of surprises you well let me give you a little hint how many how much data there is it's so convoluted you have different fields that represent different things and when you look at it kind of long term some of these fields are kind of non-porn anymore so a data standard is kind of key here if we don't have a data standard as we're kind of decentralizing it and sending out in real time we're kind of breaking our system because not everyone's going to get the same information and understand what the information represents so with that standard comes control of your data you want to control your data so if we have a standard and we give you the ability to actually use that data you have control of it so we came up with the idea of tegula so tegula is interesting tegula is a solution that allows you to own your data Implement a standard but also allow it to integrate and build and be built into different portals so for example if I went on to inbrex.io or Zillow and I added a listing if they had tegula running in the back end they could push that data out and have it sent to anyone who's actually running tegula and get the most real-time data now a big part of that is how do you restrict how do you ensure ownership so we have tegula which is open source and we have something called an owner key now how the owner key works is let's say I have a firm and I have 10 listings and I make a deal with Zillow to say hey you can take in my listings and use it I will give them my key and that key is kind of my identity so as they're getting a feed of data if that key can decrypt the data correctly then that's verification that that data is legitimate and it's coming from a valid source so how do we do this well we use ipfs to store the data we encrypt it and then we use orbit DB to actually store logs and actually allow that data to kind of be structured in a way where we can get real-time updates on the Fly and now the last component of this is the UPI we generate a UPI that allows us so a unique identify a property identifier that allows us to know what pieces of data need to be updated in real time and what notifications have to be sent out throughout the system so this is how it works an agent adds their listing on inbrex mbrx will hold that key and allow that data to be disseminated throughout the system now let's say I put my data on index and I then go to Zilla saying Hey I want you to pull in my data and you know display it I will then go get my key off in bricks and say here here's my key and using the protocol you can bring in my data so how it works is every time I want to make a change instead of having to make a change and relying on all these other systems to pull in the data and make those changes you know every 24 hours it's done instantaneous which is very important so um I can't make this any bigger getting better so I don't know if you could read it but so down here the agents have their key and what happens is the ethereum blockchain will index the UPI ipfs will store the attributes encrypted and then orbit DB will actually Store The Entity that is the UPI and the um yeah a UPI is a unique property identifier it's how we represent the property so orbit dpy actually uh store it and give us a log so when you and enter in the owner key it will actually give you a log of the real estate data so our solution is very powerful at least from a web 3 perspective on the back end and now I want to kind of talk about the web too real estate agents they want to do this but they don't want the technical part of it it's very difficult for the real estate energy industry to understand the technicals so we have to build a non-technical way of interacting with it so that's what we did we built a front end that is non-technical but allows you to actually benefit with all these technologies that we built in on the back end so this is what it looks like right now this is our most recent uh release you can go in enter in and address a keyword or something and it'll look up a property and give you all the details which are actually pulled in we parse it we give a unique identifier and we push it out to tegula so that anyone who actually wants to add a listing they can add a listing and then give that key to someone else and have real-time updates of your data so what did we learn what do we learn in this process going from going from a web to audience to a web 3 application well on day one we we learned really hard that metamask was not for everyone we realized that we lost half our users just on mad and mess go on so that's a really big thing you want to think about so we're going to talk about metamask you know wallets gas fees in chapter one and then we're going to talk about kind of asynchronous systems like what am I doing am I done and kind of how that affects the user's experience so chapter one gas fees so we realized from the beginning people did not want to buy ease we had people sign up and then it prompted them to you know have a wallet address to launch a contract to represent them their their entity on the blockchain and AD listings have upis and do all that and then we realized well no one really understood how to work with this so we we built a system around it this system was the subscription model and it was built on what we call the own model and the O model is a bunch of owner accounts that allows us to actually sign transactions on the behalf of our owners which are on the behalf of our users which would be our agents while at the same time giving our website Community the ability to use it as a traditional dap so what's this look like so bear with me I'll kind of explain it so when you would sign up you would have to launch a pseudo contract now this pseudo contract would allow you to actually interface with our whole Suite of contracts to add properties um flag different listings and actually modify that data through the contracts so let's say you're a agent and you don't really want to use a web web through Technologies like metamask you would sign up K and Fiat and then what we do is deploy the pseudo contract and the the parameters of the contract would be tweaked to where inside the owner contract we would actually check if you're a subscriber or not so that if you were to go onto the platform and add a listing instead of metamask prompting you to you know set your gas price and actually send the transaction we would send it to our back end where we would check um is this a pseudo contract that requires uh owner account to sign if so we would sign it and then send it to a listing contract whereas if you you're using if you're using it as a traditional Dap You would just hit the add listings method it prompt metamask and you can then go to listings contract and add a listing so this still led to some difficulties so what was happening was we had people interacting with the platform and because get the gas prices were really high our wait times were really long and this led to the UI not knowing how to render certain features so for example if you added a listing and it took 20 minutes to confirm before it render on the page well naturally an agent will be like oh this is broken so um they would keep trying again and this would then cause the actual um mechanism of adding a listing to break so the the buffer between the user experience and the actual back-end was a little difficult to lay out so what we did as we kind of moved gasps back and thought about how can we abstract the web 3 to make it easier while providing those same features so before you would have to deploy a pseudo contract to interact with any of our contracts on the main map you would get a confirmation confirmation email after that contract was confirmed and then only after that you're allowed to use the site so after that what we did was we kind of went back to the traditional way of web 2 where you would have your username password oauth you know with all your social media but what we did was we separated everything into a transactions API to where after you get onto the site you have the ability to use the site as a purely web 2 application but if you enable the uh the creation of a wallet on the site then you're actually starting to utilize the powerful web3 features without having any you know barrier to entry and what's nice is we kind of removed all the transaction tracking from the front end and moved it purely to the back end so that if they needed to you know add a listing or you know get a token transfer we do that on the back end and after the fact we then confirm with them that it happened so there's no um wait time up front and as a result users don't have to directly interact with eth which reduces our very barrier of entry into the platform but it also makes it easier for us to kind of reach a bigger Community because with real estate agents a lot of this technology was built in the late 90s early 2000s so there is some catching up to do chapter two asynchronous systems so before so how many people understand the idea of how you have to wait for a transaction to confirm before you can you know do a nerd transaction because they're kind of depending on each other that makes sense yeah so what was happening was to add a listing like I said taking away from five to twenty minutes and this was kind of problematic because our users didn't understand you know transaction latency and we went a hundred percent decentralized off the bat so we are actually tracking every transaction on the front end so you would have the transaction hash just sitting inside the browser so if someone closed the tab or like restarted their computer that transaction hash would actually disappear so then when they would log back in they would they wouldn't know if their transaction went through if it was still pending there was just no way of them knowing so what do we do we separated it out afterwards we have ethereum and the upis out of your ex out of the user experience and we do it in batch validation so everything that they do on the platform we verify on the blockchain on the back end after the fact so that they can interact with it in their web 2 in their in their traditional web 2 experience while still you know utilizing the futures so what's this allow us to do well it allows us to build UI the traditional way where people don't have to wait on a asynchronous systems to confirm their transactions and batching the transactions at peak times allows us to optimize how much gas we use when either doing a token transfer or sending a UPI so in conclusion what did we learn here well we learned off the bat users do not want to deal with gas when you're designing a UI you need to think how the experience of gas will be introduced if it's introduced at all because that will either determine if a user will come on board or not at all and with gas you need to think about how transactions will affect the flow of the user's experience if transactions are required off the bat you need to think okay I need a transaction and it's mandatory how can I make that transaction experience from a ux perspective makes sense but also convey it in a way that people will understand I need to wait and then after this I can then continue on so by doing this we allowed an application that had multiple web3 frictions to be abstracted out we allowed more users to join the platform while still utilizing the powerful features so these are our two chapters of of our webs right now but we actually have a nerd chapter we would like to discuss and that is escrow Commons so as we talked about how we need you know data to be in real time and data needs to have some type of standard built on the ideas of web 3 this all plays into what we're going to do next which is escrow Commons as I showed before there's multiple ways of you know getting your data putting in different portals to go from creation to closing the idea of escrow Commons is to create that Baseline with our data so that we can then introduce escrow Commons where we can use Smart contracts permissioning and ipfs to actually exchange the important documents needed to make a transaction so like kind of the legal documents payments and all that done in exchange to their contracts so that ideally the end result will be you could have a path for real estate transactions that's fully digital from the creation to the settlement all in one place thank you [Applause] I'll take any questions yes have you know so what we do is when we have to process a transaction we'll actually look at etherscan to see what the gas price was because before we are just using the estimation of gas pricing so when we were deploying pseudo contracts at the beginning it was costing anywhere from 35 to 40 dollars just to onboard one user yeah so optimization was a big thing so now what happens is we actually look at what the current um you know wait time is versus how much ether would take and then use that to determine when we would actually send the transaction via the transaction API we actually use East gas station I'm sorry foreign off the hand we were charging yeah we're just looking at the gas price on the Fly oh yeah [Music] so the confusing part comes when you you got to look at the industry as a whole the industry as a whole is pretty outdated for example there's something called the rets protocol which was first conceptualized back in 1999 and a lot of people are still using just email to send you know documents and stuff so it's it's more the user base and their standard of how much technology they know at the current moment so it come really comes down to that so for us we understand the importance of gas but that's in to explain that at an abstract level is a little overwhelming so the idea is to make it as easy for them because they don't care about gas they don't care and honestly they don't really care about how the blockchain works they just want their data to be reliable they want it to be in real time and all they want is that that will lead to leads for them to then settle and if this helps that's great but adding another layer of abstraction on top of that to explain gas and everything they'll just say okay we'll go to Zilla [Music] yeah so if you could like maybe later on we can rephrase gas as something else that makes more sense that'd be optimal but for right now it's it's a really hard barrier so what we were doing was the initial setup was enter you know username not username it was first name last name email and then when they deploy this contract we then get their pseudo contract and their metamask address that allows us to know you know what contracts are doing what we saw pretty substantial number of Records where people would enter those first three things and then they'll just drop off the signing off process so it made it very clear the minute they hit what is a wall address or metamask they jump shipped and we realized that um after the fact and spent two weeks completely removing it any other questions yes right now we're residential but we're hoping eventually to go into commercial as well yes so if I hear your question right is using the blockchain versus not using it change the users like their ability to reach their goal kind of foreign you have to speak up I really can't so right now the value is that it's immutable they have a history right now they don't see that a benefit right now but the idea is to build out to where by adding the data there we actually have a verifiable and actually a more accurate history you know history of a listing as it's going through time so right now they don't the they don't really see the benefit but ideally once we actually kind of better persuade them to see what it can do they'll actually understand the benefit of it does that answer your question you want to come up because of the business model so the business model right now like how it operates so right now how it operates is that we have a front-end application where people can you know it's like Zillow you can just search and everything but the business is actually done purely with the enterprise we bring in Enterprise data and the idea is to give them the ability to actually use what we've packaged to make it more easy to disseminate their data and actually get more leads because in the real estate industry it's all about leads that's why they go to Zillow in this that's why they kind of blindly give their data away because at the end of the day they just want to lead to make a sale for their commission the idea for for in our business right now where it comes down to is the Enterprises and how we can benefit them with their data because that's really the foundation of everything you can't build a house if you have a foundation that's all crack and leaky if we can solve the data issue which is a huge industry uh problem that's plaguing all I think all of the real estate industry we can solve that then we can build on top of that with different web web 3 techno apologies to benefit them going forward yes all right boys so right now how we prove ownership of data is through that key so if you have a property and let's say you want to put your house up for sale okay you go into inbrex you get a unique key you add your listing and that listing is you know disseminated and decentralized the ownership is that if someone was to tie into the protocol and use any other key that data would not decrypt and it'll just not come in so the the verification is that your key it's kind of like a private key that verifies that you own that data because you're the one who pushed it out that's how we're doing verification right now yes right now we're not that's not what we're really thinking about but integration would probably be the biggest thing we would go for yes oh yeah it's also open source there's a bounty for tegula so go check it out and see what you can do with it yeah everything's open source uh for the tegula protocol so go check it out yes so right now for just like dispute resolution with the data itself a hiccup like in you're actually so right now how we handle disputes is more on a case-by-case basis for example when we had an issue where people's listings were having issues populating are as inaccurate after a token like because uh once you validate a listing you you get a reward if that reward there was some issue with that we do that manually for right now any other questions I'd like to thank you for you guys time and go check out tegula thank you