Sonr

GM, GA, GE everybody. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute window for members of the DAO to showcase something they are passionate about or been working on. This could be an awesome project you've been working on, demonstrating unit testing best practices, automation goodies, smart contracts, how to structure a project, etc. Basically if you've got a passion for something, this is your opportunity to share it with the community. And today I am excited to introduce to you Prad from Sonr.io who is going to be giving us a overview of his product. Take it away Prad.

All right. Um. Can you guys see this? Right. Um. The internet world is at an impasse. With increasing pressure from users for freedom of speech and unwillingness from monolithic companies to loosen their indoctrinated moral grip, humanity loses as a whole. The internet contributes to 12 percent of the global GDP and has grown seven times faster than any sector in the past four years. It's clear that something so substantial to our economy should facilitate the proper measures in order to ensure that users won't be exploited. Correct?

This is precisely the problem that my team and I have been diligently working on for the past six months. My name is Prad. I started coding when I was 12 making one of the first 5,000 apps on the App Store. Over the course of 2021, I wrote the fourth most code on the planet building key points of infrastructure that are used in Sonr today. And most recently, I was a guest lecturer at MIT Sloan school along with other notable speakers like Vitalik. Aside from myself, we have Michael, our resident MIT alum, Nick who can make a VGA cable out of a TV antenna, and Ben who's world class at limiting ads and maximizing our flows. Rebuilding the internet is not an easy task to explain. Luckily I'm not going to completely do the high level overview and here's a quick video demonstrating...

Hey Prad, I think you need to go to Discord and share with your audio.

Oh, you can't hear the audio from the video? No, just the video. All right, we can just skip the video part then. Um. Here's an open secret. We're not the only ones who are working on this. Um about two months ago we had Jack Dorsey introduce Web5. I know that they've been working really hard over there at Square with a lot of code commits. It's around 52 right now. I joke, but I truly believe that this is a good signal that there are people working on a technology that needs to be in place.

At Sonr, we are constantly trying to create various scenarios that involve different users, including how different apps would be able to connect, how should user onboarding look, how can we make developer friction as little as possible, what will be the first killer Web3 dapp and so on.

At our soul, Sonr is a team of artists and engineers. We all understand the real value of what we're building, but the only way for everyone to actually benefit from Sonr is to enable developers to be able to build at every level of our stack. We started by doing a thought exercise amongst the engineering team: what is the one tool every engineer in this room knows? The answer was Firebase. The number one tool my college hackathon teams used to go quickest to production. Based off of this insight, we went and developed a no-code dashboard called Speedway that will be releasing a little in the middle of next month. Speedway provides you with the simplest way to start building on the Sonr ecosystem. You will be able to define schemas for your application's data types, set up channels for your users to have real-time streams across different data channels, create functions for interacting with objects, manage your decentralized identity modules, and much more. We have also designed an open-source component library to plug into your app's frontend for easy integration with your Speedway service. You can focus on what truly matters: delivering true value to your users.

Um we've been heads down building for pretty much this whole year. Uh we are anticipating that the CLI version of Speedway will be releasing in the next two weeks. Uh we have our devnet which would be just an open faucet not incorporating our token model and will allow developers to have like a sandbox environment in order to develop on Sonr. Uh we'll be having our frontend clients with Motor, um be available for Android, iOS and Flutter. Our methodology is to be offline and mobile first, and we feel like this is going to provide the best opportunity for developers to build scalable decentralized applications. Uh October is going to be when Speedway launches, we'll be involved in a couple hackathons, uh the channel module will go live. November we're going to have our web implementation, a couple more architecture decisions, and December is when our token will get incorporated and we'll go into testnet. I wanted to show you guys a quick demo of how the CLI looks like in this instance and go into a little bit more details about DIDs before opening up for questioning. So while I'm getting this set up, uh how many of you guys have experience with DIDs before?

I've just started playing with them a couple days ago. A couple days ago. I mean what are your initial thoughts of them? Like do you feel like this is going to be a scalable solution to solve the identifier issue that we have? Personally I'm still at the stage like trying to wrap the concept around my head, um but uh I couldn't say one way or another at this point whether I think they're scalable, but um they seem pretty interesting at least at this stage of my investigation.

Right. Um so DIDs can replace everything from digital assets to physical. In the real world there is no way to test the authenticity of like let's say you had a serial number without the use of a third-party service. Uh like right now on your MacBook, let's say that you looked up the serial number you're only going to be able to source it through Apple. With DIDs everyone has the ability to provide that verification mechanism alongside that identifier that is resolvable across multiple networks. In a more practical example let's talk about our onboarding experience for developer dapp. Well me personally, uh like two days ago I was reached out to receive this NFT token, get through the access with Guild.xyz and then verify my Discord membership and it was like a multi-stage process. Uh a way that this could be replaced is if you had a DID document that was resolvable on any sort of blockchain you would be able to verify that this person Prad is exactly the person that is a member of Developer DAO and he is permitted to speak at this point. The way a DID doc is typically structured is in JSON format and this is the aspect that we keep on chain in terms of Sonr. Uh we feel like you can't put PII on chain, I think we all know that here. Um and the best way to actually be able to identify users uh we believe is through the actual devices that the users use to interact with the internet. This would be like let's say that you're logging in with your phone or a website. Uh if you guys have utilized biometric lock or Face ID, this would be what would be generating a credential in order to map that device to your user. We use this mechanism, we use this functionality called Multi-Party Computation to basically piece together all these different shards of data and be able to recreate that wallet and demonstrate that that person is that person regardless of what device they're accessing from. Um we can demonstrate this with a simple example from our CLI. So if we call register here, um enter a passphrase. This is what's being used to encrypt an IPFS vault where the rest of your keys are being stored and only this access key would be able to get it. So right now it's initializing the MPC wallet. This is typically what takes the longest in the process, we're working on making this more efficient. In our dev environment you'll typically be dealing with multiple accounts but in a real production scenario you would have one DID mapped to each person meaning it would be passwordless login without seed phrases powered by DIDs and biometric authentication. The shards are being created right now, DID document is being created... and it's done. In our CLI we store it in your system keychain. And boom, that's the available accounts on the system. And if we were going to log in in a typical scenario uh you wouldn't have to what is it select an address because you would be mapped one of these addresses to one person. But let's say we use the account that I just made, um and enter the password. That password aspect is what you wouldn't have to recreate on every one of your applications. As you can see, I didn't need to use a seed phrase, I just typed in a password and the wallet's being constructed. You can think of the password much more as a fail-safe to being able to access your account. And boom. This is how a DID is typically structured and the way that W3C um has created the spec this has uh the ability to be resolvable on any type of network. Like with Ethereum they have a similar concept with did:eth, um but I don't believe uh what is it MetaMask is utilizing this right now so I would have to find a different wallet implementation of this. Uh I am familiar that Multi-Party Computation is uh something that's being done um within the industry, but it's it's much more at the server level opposed to the device level. Um but yeah, that is a quick sneak preview of what we had. I wish we had more to share, but I'm sure we'll have a much more of our release next week.

Yeah, so I saw on your roadmap that you're releasing devnet if I'm not mistaken next week? Yeah, um so with our devnet environment you'll be able to access like these DIDs the same way. You'll be able to query them and see the full document, um and also be able to view different uh aspects of the application itself. Uh authentication and identity are obviously just building blocks that are required to building scalable applications. Um aside from this you need a way to be able to define data structures um and also provide uh a way that when users are implementing these data structures that the objects that are resulting from that are uh only accessible to the user. Meaning that it's it's a mechanism that facilitates user-owned data at the device level. Cool. And when you say at the device level, are we just talking um like laptop level or are we at the or is the vision for it to be at the internet of things level?

Yeah, yeah. Like um in our video that wasn't playing you you can actually see a fridge um running a Sonr Motor node. Uh our idea our idea is that we will create the Motor node SDK package. Let's say that you're using something like Flutter, Android, iOS. We have web in our timeline down the line... um got to fix a couple of issues because of uh what is it the biometric authentication. But um right now targeting mobile because of uh how it already has those native security features. But a typical development scenario would be like interacting with the CLI or interacting with Speedway, uh scaffolding up an application, using an existing frontend and just importing the Motor package into React or Flutter or whatever you use in that system.

Cool. Cool cool. And and Speedway is the blockchain on your network if I'm not mistaken? Um. Speedway is going to be our web portal. Um. That's that's what we're going to be using as our Firebase hedge. Uh we believe that the way to onboard at least the existing developers into this industry is to be making dev tools that are uh what is it a lot more familiar to them. Right. Like...

Yeah, um open up to any other questions. Uh I kind of want to hear the the origin story of Sonr. Uh I briefly took a look on your site, but uh I think the the crowd would appreciate it. Hehe.

Yeah, yeah. So uh in November of 2021 I was in the top 1 percent of Warzone wins in season 2. Uh and I hit this really sick clip across the map that I wanted to send to my friends in a group chat. Uh and I play on a gaming PC. And I was trying to Airdrop I was trying to send it to my iPhone. And what I usually did was just email it to myself and download it. But I ran out of Google Drive storage so I had to plug in a flash drive into my gaming PC, uh drag that file over, plug it into my Mac, and then I Airdropped it to my phone. And at that point I felt like the biggest moron on the planet. And I felt like if TCP, UDP and all these other networking transports are exposed over every single type of device, there needs to be a mechanism that allows for secure encrypted Airdrop across devices. And that was what was put into place last year. And that became like the basis for what Sonr is today. After you have that layer where every device can be interconnected in a scalable way, um then the next part becomes how do we identify that these devices belong to one person. And how do we know what kind of data is being sent across the network. And um how do we know which data belongs to which person. Where do we store the data when it's not being stored on the device. How do we manipulate the data that led to functions and smart contracts that we're actually implementing right now. Um and that was like the methodology for it. It was it was sparked out of Call of Duty.

That's sick man. Awesome. Sometimes that's sometimes that's all it takes. Just a little bit of frustration to to get the creative juices going. Yeah. Like uh it was it was definitely like a weird way to arrive at a frustration that I feel like a lot of us had... the lack of interoperability amongst like these platform-locked devices. It's I I think it's a consumer injustice. Uh like I I own a PC and I own a Mac they should be able to seamlessly communicate amongst each other if they're both following the same transport specs, right? Right. We utilize libp2p for this. Um our stack is all like um it's mostly Protocol Labs based SDKs, so we have libp2p running for the Motor node. This allows us to make it run on the fridge per se. And we utilize Cosmos SDK to scaffold up the blockchain, so we are going to have CosmWasm enabled smart contracts, uh and an IBC connection uh later this year in the December testnet. Awesome man. Yeah, looking forward to it. Uh there's a question in the chat. Uh NateDev asks uh basically um is there any did you mention anything around account recovery and uh yeah, maybe you can speak on that a bit.

So like the way that accounts are being created right now is that there's multiple shards. Uh how MPC works is that they take these different configurations of how the key is structured, they split it up and um the shards that are unused for your current device are being stored in this IPFS vault in a and then in a separate vault is where the uh final recovery piece is. So that password that I entered in the CLI earlier is what's being used to recover that final recovery piece because obviously you don't have a terminal biometric auth, right? Um. And you have multiple fail-safes to be able to always uh recover your account. Uh another another what is it recovery mechanism that we're looking into is since we have this decentralized network you're probably going to be uh communicating with the same set of peers in a given uh given circumstance. So having some sort of social graph to be able to verify the user is something that we're looking into down the line. Sweet. Good stuff. Uh does anyone in the crowd have any questions for Prad?

Awesome. So is the majority of the code uh here that powers Sonr open source? And uh if so uh is there anything in particular um you're looking to get a hand in from um the crowd here because we are Developer DAO, developing is what we do best so is there any opportunities for folks here um to help out anywhere in the repo or uh yeah. Yeah. Is it okay if I call someone from the crowd to answer this question because of our our head of engineering is actually right here right now?

Yeah, yeah, totally. Nick you want to answer that one?

Yeah, hi. First of all those of you who know me, I'm Nick. Uh help with the mentorship team and a couple other initiatives here. Uh yeah, we would love help with building out more Motor targets. Uh we try to build them out in an idiomatic way for each platform. Uh so there's some platforms we're not super familiar with like it's going to be hard for me to build a C# Motor target, right? Whereas all it really is is a binding layer but I don't know how to do it in a C# specific way. Uh that's one really easy place to get uh to get involved. Uh it's basically just suggesting and building out any Motor target, they're just a simple binding layer for an API uh when you go down to their core. Uh another great place to get involved is contributing to our core Sonr repo. We have a bunch of issues open uh that is Sonr-io/sonr. We have a bunch of issues open and just pick one up.

Sweet. You heard it. And then finally, uh we're always hiring, uh you know, reach out to me if you are very familiar with DIDs, Web3, the Cosmos ecosystem. We can have a chat.

Excellent. Well said. Yeah. So anybody in the crowd who's interested, uh Nick and Prad are your guys. Uh and final question for me, um can you speak a little bit around your uh product roadmap? So we you mentioned that uh you have devnet rollout coming up um pretty soon at the beginning of the month it sounds like, or at least in September. Um could you speak a bit more about what kind you have in mind um after that if you can.

Yeah, yeah. Yeah. Um so our goals right now with devnet is pushing the first three ADRs. Uh the first one is about DID accounts, um how register works, account recovery, basically everything around how do you identify a user. Our second ADR is about how do we identify data. And uh we use IPLD for schema specs and that's basically just like defining uh a class or an object in typical programming. And uh that would be stored on chain like you set a label for what the field property is and then you define the primitive type that it's involved with. And uh the Motor client on the other end would be able to reproduce that object and store it in the user's account like uh data for that particular application. Uh after that process is done, uh the application if it's permitted with its it will be verified through its DID doc and you'll be able to resolve the data that way. And that's just for the first three ADRs. Like you'll have the ability to define accounts, define applications, define data, and define storage bucket mechanisms. Uh for our testnet we plan to incorporate our token economics. We are really focused on making this a utility-driven token. Um um any venture capital that we raised was through the United States, we didn't do an offshore company. We really believe that if we're going to rebuild the internet and make it user centric, we have to play the game according to the SEC's rules.

Hmm. Yes.

Yeah, so we we really are not fans of anything shady. Uh but aside from that like our goals would be like Speedway with the web portal, um getting that out. And aside from this we actually have a consumer-facing application demonstrating what you can actually build with Sonr itself. Um we call this Beam. Um if you go to our website you'll see a screenshot of it on the front page at the very bottom. But this is a Matrix protocol powered uh chat application that basically allows you to relay all your existing chats like Instagram, iMessage, Twitter, um all through uh your Sonr DID. So if you were to message prad.snr on Beam through Instagram or whatever, it would be able to resolve to prad.snr on the Beam application. Uh and if you guys are familiar with Signal or Telegram saying end-to-end encryption, this would be device-to-device level encryption.

Oh, sick. That's awesome man. And is that available um for people to download today?

Uh we have it on internal TestFlight right now and we were going to open it up for a public TestFlight in December as we build out dev tools first. It's better to approach developers before consumers. Gotcha. Yeah, yeah. Makes sense to me. Um we have a couple more minutes left here gang. Uh is there any questions from the crowd? Going once... yeah, go ahead. Yeah, I am trying to find our ADR about DIDs. Uh this should provide a lot more context on the registration aspect. Just threw that in the chat. Beauty. And uh I guess if there's no further questions from the crowd um what's the best way for folks to uh follow follow the progress uh for Sonr? Uh is there Twitter, uh Discord? Yeah, um we have a Discord and we have a Twitter. Uh you can find our I'll throw in our Discord invite link in the chat and our Twitter is just twitter.com/sonr_io. Beauty. Great stuff. So if there's no further questions from the crowd, then uh I want to thank you Prad and Nick, thank you for thank you so much for coming on giving us an awesome overview of Sonr. Um really looking forward to all the innovation that happens here. Um and yeah, we'll be following closely. Awesome, thank you. My pleasure. And with that, uh I will stop the recording.