@ YakiHonne

YakiHonne.com is a Nostr-based decentralized content media protocol, which supports free curation, creation, publishing, and reporting by various media.

Yofu: Hello everyone! Welcome to the YakiHonne Workshop. Hack-Nostr-On is hosted by YakiHonne and sponsored by DoraHacks, with the aim of encouraging more ideas, applications, and problem-solving based on Nostr. YakiHonne.com is a nostr-based media protocol that supports the creation, publishing, and reporting of various topics by medias. We are honored to have developer Roadrunner (aka 42) to give a presentation. Please welcome Roadrunner!

Roadrunner： Thank you. I appreciate the opportunity. I'm from El Salvador. I'm an amateur programmer who's just learning about Nostr and trying to build their first project. It's a very cool opportunity because I feel Nostr is a very open network for beginner programmers. It's very simple technology, but it can scale very well. Part of the idea is that the code should be kept simple. It is one of the main ideas of the protocol,so it was very simple for someone like me to just start building on it, which is what I find really cool.

And I basically started building a little project that is attempting, called Roadrunner,that is attempting to create a decentralized marketplace of ride sharing, kind of like an Uber application where riders and drivers and passengers can find each other to finish rides. So, it's just trying to do the same service, but using decentralized technologies like Nostr and Lightning Payments so that you don't have to worry about, well, anyone else,it'll be completely custodian and will be peer-to-peer completely.

Today I wanted to bring this presentation to you guys to kind of talk about the basics of the technologies we're building.Through Roadrunner and through Nostr and through Lightning. Kind of a bit of the basics about Nostr.How Nostr becomes peer-to-peer,the type of content that can be stored on Nostr, who and how you can access that content,And all the types of services that you can provide using that content.

So, let's start talking about Nostr as a peer-to-peer network.Everyone's heard this term before a lot,Peer-to-peer. I think it gets thrown around a lot,so I wanted to kind of dig into it and ask the question, is Nostr really peer-to-peer?And what does that mean?

peer-to-peer technologies mean that they allow users to connect directly to each other, Without any intermediaries. So, peer-to-peer means thatI can talk directly with another peer, that I can interact directly with another peer. For example, Signal, Which is a messaging app. And in there, there is no in-between. You are sending encrypted messages from your peer to another peer, Its Technology that works directly from one person to the other, that allows that communication.

So, when we ask that question to Nostr, We run into this, into this kind of diagram,Where users are posting things onto a relay and then listening back to those posts,So, you could be posting, for example, a post to your Damus app or to your social media app or whatever, whichever app you're using,And you're also seeing other people's posts from that relay back,But if you notice, at no point is there a connection between you and other peers.

So, at face value, Nostr is not a peer-to-peer network,Because Users are never interacting with each other directly. Users always interact with the relays,All the users have arrows between the clouds, the relays and the users, but users never have arrows between each other. You are never sending a message directly to another user,And if you also notice, the relays don't talk to each other,Users can post to a lot of different relays and can listen to a lot of different relays,but they are never, but the relays don't talk to each other,Just as the users don't talk to each other.

Nostr, at a simple level, is an open network where everyone can post things to different relays,And everyone can read from those different relays. So, if I post anything to this relay, to one of these relays, anyone else in the network can access that information by telling the relay, hey, what did this person post, So, at face value,it is not a peer-to-peer network. It is an open network,So, how do we turn Nostr into a peer-to-peer network?How does this architecture allow us to turn Nostr into a peer-to-peer network? Well, this is where encryption comes in, and I've put the SHA-256 logo here onto a sun because it's kind of like the light of encryption is what allows this peer-to-peer technology to happen. So, how does this happen?

The peer-to-peer functionality comes with encrypting your messages. That means that you can post an encrypted message to a relay,and yes, it is still public, but that means that only the people who you encrypted it towards can see those messages,And that's where the peer-to-peer functionality comes in because, yes, it is an open secret,You are posting that message to a relay, which is completely public, and anyone in the network can see it, but it becomes peer-to-peer because anyone can see it, but they cannot decrypt the message,So, even the relay can't see the message. Other users, which the message is not for, cannot see the message,Only the peers who you encrypted it towards can actually see that message and interact with it. Other users who don't have those encryption keys will not be able to see your messages.They can see them, but they cannot decrypt them, so they are useless. They're just a bunch of encryption text, which they can do nothing with.

So, that's kind of why Nostr becomes a peer-to-peer network. It is not by itself a peer-to-peer network, but when you start encrypting content on it, you can use it as if it were a peer-to-peer network,You're still dealing with the intermediaries of the relays, but then the relays can't really do anything about it,Because they're just passing on encrypted information along, and they really, there isn't a very easy way of telling apart the difference between encrypted information and non-encrypted information. So, that's where relays kind of have no weapons against this.They're just, their job is only to pass the information along, and if the information is encrypted, you can get this peer-to-peer functionality.

So, let's talk a little about what type of content you can put on Nostr. At face value, Nostr is a little boring. If you just look at it from, just take one look at it, it is a little boring, because what we have here on the right is all the things that you can store on Nostr. This is the only thing that you can store on Nostr.You can create these objects,Which have an ID, a pub key, a created at, a kind, some tags, a signature, and some content. So, let's run through these.

Very importantly here, the pub key,Is the identity of who posted this object,This is an object that is getting posted to the relay, and it always needs to have a pub key,That is your, and we'll talk a little more about pub keys in a second, but that's basically just saying who posted this event,We have a created at, which is when this event was posted,We have a kind, which is what type of event this is, We have tags, which is like reference to other events or other pub keys in the relay, and then we have this ID, which is like a unique ID, just to make it easy to reference this event, and the signature, which is a cryptographic function that allows you to make sure that the pub key that is publicly set up in the object is who signed this, is actually who signed this object,So, that's a little cryptographic magic just to make sure that the object was created by who it says it was created by,Kind of a little verification, and then at the end of all that.

you can store some content,And what can you store into the content? You can store strings, and for those who've not, who aren't familiar with programming, strings is just a fancy word for text,So, strings are just a bunch of text. So, that's why I put this matrix image here, because there's just a lot of like, where you can put in words and numbers and text, but you can't do anything more than that. You can't post a picture, you can't post a video, you can't post a song,You can post text, and that's all that you can store on Nostr. It cannot store, for right now, anything else,And if you think about that, that's kind of boring,Because the internet isn't just text,The internet is videos and images and songs and audio,And so, if you can only store text, this isn't very useful.

So, how do we adapt to it? Because we already, we do want to use Nostr, because it allows peer-to-peer, how we've talked about,Like peer-to-peer encryption and communication,So, how do we adapt these boring strings to actual internet content that is fun? Well, in some cases, it's very easy, Social media, and you've already, you might have already interacted with some of these clients, like Damus and Amethyst,Which are just basically social media platforms, and these work, if you think about it, mostly off of strings,You see people's names, which are text, and you see people's posts, which are also text, and you might have counters of likes, which are also a bit of text with some static images,You don't really need to store the image of a like on Nostr,You can just keep a counter of it and say how many likes that something had. So, that is like for social media, most of the applications are very easy to handle with only text.

Then another use case are URLs and external hosts. So, for example, you can just reference your YouTube video,You post a video to YouTube, and you just share the link through Nostr,And there's a bunch of ways that you can do this, but it basically boils down to that,And it doesn't have to be YouTube, you can store this in your personal server, and there's already, for example, servers that are specializing in URLs that are very Nostr friendly, for example, so that like very small URLs that you can easily like copy and paste from a text format,One of these examples is Nostr Media Uploader, which I've seen that I've got a lot of traction lately, and this just basically allows you to upload any photo, any video, any type of audio that you want, get a URL from it, post it on your Nostr text,And then anyone who looks at that event can just go look at that image and that video from the Nostr Media Uploader, At that point, the content is not stored on Nostr, it's stored somewhere else, It's on another server, but you're just linking through it on Nostr. So that's a very easy solution,Because, however, it doesn't solve the problem of where do you store these things.Then at this point, you're still becoming dependent on storing things on YouTube, on storing pictures wherever you store them,On storing things on Nostr Media Uploader, sure, links are very useful and easy, but they're not the full solution.

Another thing you can do is serviceable data, which is kind of what we're doing with Roadrunner. And to give a small example of this, Serviceable data just means strings or text. That is actually more than just the text it's on, it's data you can use somehow. And Roadrunner uses, for example, coordinates, So we are sending coordinates through where the passenger is, or where the passenger needs to go, And making calculations through this, how the distance you need to, the driver, and giving this information to the drivers, So this is serviceable data, Yes, it is text, it's only text that's there, but it's text that a service can use, get more information, provide a service from it, and then return more information to a customer, So that's kind of what I mean by serviceable data. And coordinates are just one aspect of this, Invoicing, You can have many types of invoices, you can have orders for things, So serviceable data is basically anything that you can get more data out of, There's even, I've seen even ideas of like,for example, distributed computing,Where you put code that you want to run onto Nostr, and then other computers take that code, run it for you, and give a response back.So that's kind of like what I mean by serviceable data, You're not really interested in the text itself, you're interested in doing something with that text and providing that service to a user. And then there's a really big space of opportunity with native data storage, of actually storing data on Nostr.

Because at the end of the day, if you think about it, computer information is just text.if you go far deep enough down the hardware ladder, You can get down to zeros and ones, and very, very, very simple code to provide almost any type of content,So you could, in theory, encode, for example, a whole video, split it into its zeros and ones, or bytes, or hex bytes, or however you want to encode it, take those texts, paste them onto a Nostr event, put them up on a relay, and then whoever wants to download them, We just have to get all these events back with the data, and they would need a client that would put, parse through this data and encode it back into whatever type it is, be it a video, be it photo, be it whatever else.

I haven't seen many examples of this being done yet. I've seen some people like talking about it, but I couldn't point you to a clear example. I think it's a huge area of opportunity. You do have to be a bit technical to get into that, Because it means encoding things into text, and then re-encoding from the text, and putting it back together. So it's kind of a big technical mess, but it's there. The opportunity is there if anyone wants to take it.

Roadrunner： Probably everyone's heard the saying,not your keys, not your crypto. In Nostr, there are also people saying,not your keys, not your content, but I don't completely agree with that. And I want to get into a little bit of why. There is a bit of truth to this, because you do need your private keys to post your messages and only your private keys will reference your public key, So if you hold your private key, only you can post those messages under the public key. No one else will be able to post messages under your name for that, if you want to think about it like that. But it's not completely true. Not your relay, not your content. Now this is true. So who holds the power of the data in Nostr are the relays, because users are always posting to relays and relays decide what to do with that content. Once the user has posted something to a relay, they no longer hold control of that data. The relay holds control of that data. And I want to make this very clear with a few examples, but in very simple terms, if it's not your relay, not your content. And I will be repeating this statement a few times over the next few slides, so I hope you bear with me.

Let's talk about a bit of key pairs and identities, just to make everything very clear. To post anything on Nostr, you need a key pair. You need a private key, and that gives you a public key. Much like in all crypto systems and Bitcoin systems, you need a private key that allows you to handle your transactions, or in Nostr's case, your posts. The private key is what's used to sign and create the signatures that we saw on the data structure. And it'll also generate a public key for you. And that public key is unique to the private key. The private key can only generate one public key, and only that private key will generate that specific public key. No other private key can create the identical public key, So if you're assigning posts with your private key, you can make sure that that is your identity. And if you see a post signed by a public key, you can know with reasonable certainty that whoever holds that private key signed it.

So your key pair is your identity.Now, having said that, you can use your identity on Nostr to access any client. And that is something that's very different with the normal internet paradigm that exists right now. Right now, if I try to go to Facebook, I have to create a user on Facebook and a password on Facebook. And then if I go to Twitter, I need to create another user and another password. And then if I go to Gmail, I need to create another user and another password, And it starts becoming a little crazy. In Nostr, you don't have to do that, because your private key can be used to sign posts on Damus. And your same private key can be used to sign posts on Amethyst. And that same private key can be used to request rides on Roadrunner, There is no separation. All you need is a private key to sign and verify messages, So your one identity can be used across platforms. And that has very useful utilities.

For example, you don't have to have a hundred different users, You can have shared reputations through the platform. You can also do things like this, You can have a very professional key pair where you are offering rides to people on Roadrunner, And you have your social media profile professional on Amethyst, And you're a very professional person on that key pair. But then you have another key pair where you go on Damus and post memes all day, Because that's how you unstress out. But perhaps you don't want to be doing it on the same account. So you have two completely different key pairs, That don't have anything to do with each other. And you have two different, completely separate identities, And there's actually no way of tracking one, linking one way, unless you do it somehow. Like you actually say, like, Hey, these are my two public keys, but you can keep these two identities completely separate if that is what you choose.

But let's get into the, not your relay, not your content, Like, why do we say this? Because I have my identity,I can post however many identities I want. But if the Damus relay, and I don't, I'm not saying that they do this. I'm just using it as an example, Don't get angry at me, Damus. I'm just using you as an example. Damus, if you don't, if you post something that they don't like to their relay, they can just send it to the trash. They have no obligation to keep your post. because again, not your relay, not your content, A user published something bad about Nostr on Damus. Damus said, Hey, I don't like that. That content doesn't go on my relay. It goes to the trash. And you as a user have no way of stopping this because the relay owns the data. You are free to post however many relays you want. And eventually one of them might say, yeah, I like your data. I'll keep it and share it with other people, But if the Damus relay didn't like what you posted, they are completely free to send that information to the trash. So I want to make that very clear. I will also want to make this very clear, this other point very clear. Let's say you posted something dumb that you shouldn't have posted on Damus, an Embarrassing picture of yourself or whatever. And then you tell Damus,Hey, please, I don't want that there. Damus can very easily just tell you, no, that is now there forever, They have no obligation to delete your data either,because they own the data, not your relay, not your content,You are free to post to all the relays you want and request information from all the relays you want, but the relay owns the data.

So how do we bring balance to the situation? Because if you just told me like, Hey, relays own all the data, that doesn't sound cool. That sounds like a corporate mess, And we don't want that. So again, the light of encryption, SHA-256, which is one of the greatest technologies known to man right now, is what brings balance to this.because you can post encrypted content to the Damus relay, and then they don't know what they're sharing. So they can't really decide if they like it or not because they can't even tell what it is. And so if they don't know what you're posting, how can they decide if it's good or bad?

So if they don't know what they're posting, they're just going to say, well, this guy's posting a bunch of encrypted stuff. Let's just send it over to whoever wants to encrypt it, And it's even very hard for Damus to get in trouble for that, let's say, because how can they know that they're redoing something bad, That they're sharing something bad because they can't even decrypt the message. Only the holders of the decrypted keys can see those messages. So if you encrypt your messages, Damus doesn't know what it's sharing. And that's kind of where the balance comes in in Nostr. Sure, the relays own the data, but if that data is encrypted, that data is useless to the relays. So encrypted data is only useful to peers, Encrypted data keeps the balance of the data ownership. Sure, the relays own the data, but it's not useful to them if they cannot decrypt it. I hope that's very clear. This is where the balance of user relay comes in Nostr.

There is a big monetization aspect of this, And again, I'm not saying Damus does this, just using it as an example, But Damus can keep you out of their relay. They have no obligation to let you in. You can try and post to them, but they don't have the obligation to say,yeah, I'll take your post. It's an open network, but up to however the relays decide.And you are free to post to any other relay you want. But if you want to post to the Damus relay,you might have to accept some rules, And for example, one example that's going around right now are paid relays, So send me some Bitcoin and you can post, And that's a very simple example. I think there's a lot of opportunity here. For example, getting in by reputations on other services, there could be private relays for private groups, Where not just anyone can get in, where you actually have to be a part of an organization or a DAO or whatever. And that relay is private for these users, And no one else gets in,no matter how much money they have, That's another kind of use, But this is a very simple way of monetizing relays that's already happening, So if you go to NostrWatch,for example, which is just a list of all the Nostr relays that's out there, you'll notice that there's a bunch of free relays where anyone can post and read from. And there's a bunch of paid relays where there's some that will just ask you for an entrance fee, And you just pay once and you can post and read however many times you want. Some actually charge you per post, And there's like micro payments going on. So two sats, three sats every time you want to post. There's also a lot of anti-spam campaigns that are happening through monetization, So it costs one seat to post. So yeah, to a real user, Like who might post 500 times in a month, 500 sats doesn't sound like crazy cost to use a service, But to a spam user who is trying to post 100,000 messages per month,Now that becomes cost prohibitive.So there's a bunch of very interesting use cases here with the monetization, But the basic idea comes down to, if you have what I want, you can come in and post to my relay. If you don't,you get shut out, And that's just a very, very simple example.

Roadrunner： So let's talk about services on Nostr. How do we've been talking a lot about the user side, How a user can post and interact with relays. But let's look a little about the relay side, And what is actually a client like Nostr, like Damus, for example, doing for users. And this is where peer-to-peer, it gets a little more complicated. It's not exactly peer-to-peer, it's peer-to-relay-to-peer, And that's the type of service that Damus and other social media clients are providing. What does that mean? That means that a bunch of users are sending their information to Damus. They're sending their posts, they're sending their likes, they're sending their private messages. Damus is aggregating those, Into a feed, into checking how many likes a specific post has gotten and giving that information back to the users, So this is where peer-to-relay-to-peer comes in, You're sending information to the client and you're getting back information from that client aggregated from all the users that have been sending information, And this only works if you have a network of users, if you only have one user on Damus, well, there's not really anything to show him, You need to show him information from other users, So that's why it's not just peer-to-relay, There needs to be other peers in this for it to work, There needs to be a community of people posting so that you can see a feed, a community feed of posts, So that's why there's the relay in between. And it's the relay in between that is important because that's who aggregates all these posts, Damus is not only something that, and Damus isn't only checking one relay, Damus is actually checking a bunch of different relays. So they're aggregating information from a bunch of different relays and showing you all into one comfortable feed, So you don't have to worry about looking for all these relays. Damus actually does it for you. So there's a bunch, a network of relays that Damus accesses, And provides you all that information aggregated into a very comfortable feed and very like, you just like things and you just comment on things, And it's very easy and approachable, So this is peer-to-relay to peer services.

On Roadrunner,we're doing things a little bit different,So Roadrunner is actually, we do have that peer-to-peer part, So we have a bunch of passengers and a bunch of drivers that are sending us their information, but actually most of the service that we provide is done by autonomous key pairs. And I like, I'd like to say that I'm kind of on the front end of creating this kind of technology because I haven't seen many people talking about this kind of stuff, but basically what this means is just giving a bot or an autonomous service, You can think of it like a little robot, its own key pair, so it can do things for a user. In the Roadrunner case, I have a couple of different services, for example, creating ride details, Like the ride distance and aggregating the coordinates and creating a feed. All of that is created by an autonomous worker that then posts events back so that drivers can see. So in that case, for example, there isn't the information that a passenger sends, isn't the information that the driver receives, Because the information gets taken in by a robot, an autonomous service, And it posts back information and the driver actually sees the information from the autonomous service. The driver isn't worried about the passenger, they're worried about listening to the autonomous service, for example, another case, when you are actually offering a price on Roadrunner, you have to use a lightning invoice and we create an HTLC contract for you, which is just kind of like a time-locked contract to make it simpler for the payment transaction to go through and to allow passengers to cancel it. Well, that process is also done by another service with another key pair that all it's doing is taking in invoices from drivers, creating a contract from it and posting back the contract. And then passengers aren't actually listening directly for the driver's invoice.

They are listening to the contract that was posted by this autonomous key pair, So, the driver doesn't have to worry about listening to every single passenger out there. They just have to listen to the one autonomous key pair, And that one key pair will always be publishing these offers. It makes the tracking of services much simpler. I also have another autonomous key pair keeping track of reputations. So, every time a ride is settled, there's a little robot that goes and posts a reputation event, And these three services each have their own key. So, at the time of looking for these events, it's very easy because if I want to look for reputation events, well, I don't have to listen to the other two robots. I can just listen to the robot's reputation. And if I want to listen to the offers that I'm receiving, I just have to listen to the offer robot, And this is a very easy way to start compartmentalizing, compartmentalize, start making smaller services, And keeping things in compartments.

Let's talk about scaling, which is another word that you've probably heard a lot. Very important. What happens when you have a bunch of users all trying to do things at the same time? And you might have limited resources, I'm not Amazon. I don't have a bunch of huge servers that I'm running to keep things, to keep my services running at full, at hundreds and hundreds of giga RAMs of speed, Like, I'm not Uber. I don't have huge services across the world, I might not have the capacity to do this. So, my services get angry. They can't handle all this data, So, how do we scale this? One answer would be, well, become Uber. Just start hiring servers and just make huge computers and just make more robots, Just more, more, more, and just do it all yourself. I don't like that. And that's not how I've built the system. Roadrunner is being built, again, because it's on Nostr, because it's decentralized. It's attempting to build a decentralized network of rights. This is how Roadrunner and this is how other Nostr systems will scale.

Not by expansion, but by replication. I don't want there to be one huge Roadrunner service. I want there to be hundreds and hundreds and hundreds of different Roadrunner services, each running to their own specific needs, So, one of these Roadrunner services might be working in China and they might have very specific user verification things because they want to be compliant with laws there. And another one might be in Africa and they're using payments on something that's not lightning. They're using payments on another thing. There's so many examples, And you can tailor each one of these Roadrunner services to fit your needs, And this approach to scaling by replication is so much better than my expansion. Because if one of these, for example, just one example is if one of these goes down, you also have another bunch of options. Right now, if Uber goes down, all of Uber's customers are left without an option. You have to sign up for another service. But hey, if one of these Roadrunner services goes down, you can actually just go find another Roadrunner instance and use your same private key and find your same reputation events, Because it is a distributed system of relays, Your information can live on a bunch of different relays. And these workers, each one of these groups of workers don't have to be listening.To only one set of relays. They can be listening to two relays or three relays or four relays, You can have private relays. You can have your own private little Roadrunner that only runs kind of like a limo service, And it's only really fancy cars and it only works for really fancy people, And this is how I picture scaling on Nostr.

Not by creating one Roadrunner, but by creating hundreds of them, each tailored to their own specific needs. They will all have the same basic functionality. And in theory, you can use your same identity across all of them because all you need is to sign and verify your own messages.

I also wanted to talk a little more about the service and what we're doing. How we're integrating all of these tools into the Roadrunner platform, starting with encryption, because I think it's one of the crucial parts of this. So one of the things I've done is I've tried to encrypt as much of the user content that I can. The only part that isn't encrypted right now is the initial user coordinates, because you have to, if you're looking for a ride, you kind of have to tell drivers where you are at least approximately, So that event is, it cannot be encrypted. It does have to be a public event. You are posting like saying, hey, I'm here, Can someone pick me up? So you do kind of have to tell the world that, hey, you are here, But for example, I have created a system where that event is replaceable, So at the end of the ride, you just replace it with an empty event and no one can find those details, Because the original event gets deleted and the only event left is an empty event, So even where events aren't encrypted, I've tried to keep user data storage to a minimum, In almost every other case, for example, communication between passengers and drivers and the sending of invoices, and I'm doing a lot of things like lightning invoices, for example, all of that is encrypted and encrypted between the driver and the passenger, Or in some cases between the driver and the robot, But the same thing applies. So only the driver and only the service can see your information and no one else can see your information. So in theory, this means that you can run Roadrunner robots on any relay. It could be on the Damus relay. It can be on any other relay, This could be like an extension of relays of just having little autonomous keepers providing these services and then the Roadrunner clients don't have to depend on one single relay because the information is private for users, Like we mentioned through encryption, it is truly peer-to-peer and relays just act as the transfer of information and holding certain states which are only useful to peers.Because they are encrypted. I also am very proud of the whole autonomous keeper worker. It solved a lot of issues that I was having while building the system. And I think it needs to be explored a bit further with people that are more experienced coders because I think it has huge areas of opportunities of just having these keepers out there in the world doing things for you, And there's so many services that you can start applying this concept to. Because again, right now, especially with AI and all these technology tools that we have, there are so many crazy services that you can start providing and automating and just creating those, just giving. And all you'd be doing through Nostr is providing that automation of services to be public and transmissible. And I think that's everything I had for today. Thanks for hacking, everyone. Thanks for being here and for the opportunity to give this talk out, So thanks a lot to the group, to YakiHonne. And yeah, that's all for me. I don't know if you have any questions, any comments, anything else you'd like to discuss?

Yofu： Yeah, thanks to you too. I actually have some questions. I'm wondering first, what is your inspiration for doing this Roadrunner based on Nostr, based on Relay?

Roadrunner： I can't claim that it's completely original or anything. Like I said, I'm a very beginner programmer. I've had some help from several people in the Nostr community. And the idea was kind of given to me by someone who's more deep into the Nostr stuff. It is one of the original ideas that the Nostr developers, the original developers of Nostr put out there that, hey, a ride sharing service should be created on Nostr. It was one of the predetermined use cases before Nostr was even working.

So my inspiration is building on the shoulders of giants, And the tools have been given to us to access this open network, And there's also already a bunch of use cases that I don't have to go and imagine, There's a bunch of really, really important and useful things that are needed to create that people are already asking for, So I'm just trying to do that, building something that people are already asking for.

Yofu： Wow. Actually, it is very interesting because, for example, like I mentioned in the talk that if one platform is gone, for currently that's all, there's no matter drivers, no matter users, reputation, it's all gone. I need to start over from the very start. Everyone is blank. It's not fair. So yeah, based on this, I think it's interesting. The information there does not depend on the platform. So it can be like now on multiple, there's clients that the information is sharing. It's quite cool. Yeah. And by the way, do you have any demo now or it's still under program?

Roadrunner： The page is in a demo version. I could show you very quickly if you'd like. So let me change screens for one second. So the page is live right now. Anyone can access it, roadrunner.lat, It's only working with testnet payments on Bitcoin. So you need a lightning testnet wallet if you want to demo it, but anyone can access it. Easy wallet that you can access on testnet is htlc.me if you ever want to test the service out. So I'll give you a quick rundown on the page. Basically you log in with a private key. I already have my private key here to save. So I just hit log in and it puts me in. It recognizes my public key, So this is the public key that shows to other people. I've already set up some profiles using an IPO six, I think it is, which just allows a user to set up like a profile event. So you can see like, Hey, this is my name, I have a little thing for images. I have a little information for your car. If you're a driver, A picture for your car isn't hosted on the site. This is just external URLs. Like I was talking about, but again, it's very easy to just find your picture, And from a public hosted site.

So then we have a little page where you can find rights, And this is predetermined to San Salvador. I am not accessing your device information at all. This is just a static map of the world. And you can just pick two points on the map, That's why it's predetermined to one spot, but you can just go wherever you want on the map, And pick those two points, If you're in Guatemala or if you're in Mexico, Or if you're even farther away,It doesn't matter, Maybe you're a European user who wants to use it, you just move the flags to wherever you want and you can pick those rights, So let's say we want to take a trip from Paris to whatever, Rene, You can offer a price. Right now everything is priced in SATs because I'm using lightning payments and you can send over that payment, So you get sent to the screen where you're just waiting for offers from drivers, So now I'd like to take you to the driver page.

Give me one second. I need to find another key. I think I have, I should be able to use this one.So let's use this one and we'll go to the driver page, So in the driver page, again, you'll be able to see a feed of all the rides and we can see here the ride that was posted by the other public key, So if we click this little banner, we can see that, Hey, this other public key wants to go from Paris to Rene, that's this much distance, And they're offering this much for the ride, So I want to offer them a ride. I will go to my wallet and I will ask for a little more than what they wanted, Okay.

Yofu: So there is a bargain negotiation process between drivers and users about the price.

Roadrunner： The passenger can offer a price, But at the end of the day, it's the driver's call of counter offering, So the passenger wants 245, The driver is offering 400 and 420. If you notice, here I put 400,000, And it added a bit of a fee. That is the relay fee that my service is actually charging you. So I've now added a bit of a fee because I am creating a contract for you, a lightning contract for you. And that's what you were actually paying. You're not paying the driver directly. And I can show you that right now. So for example, let's say this passenger, I want to take that ride, And so you can see that it has an invoice, I'm going to go now pay this invoice as the passenger, So I go to my wallet and I say, Hey, Oh, I don't have enough money. Oh, let me make a smaller payment. Cause I don't have enough money in this wallet. Sorry about that. A bit poor.

This is all test net Bitcoin. Let me just make another offer with a smaller one. So I should now have a smaller offer. Cool. Let me pay this invoice.So now that invoice will be paid and you'll notice in a second, as soon as it gets recognized, it should change. Give me a second. Don't fail me now. Service. Is it working? There we go. Cool. So what happened is that the contract was now in an accepted status. If you notice the lightning payment hasn't gone through that's because it's a type of contract that requires a two steps, It requires a payment and then it requires a verification, So right now the payment has not been sent, Because I'm just telling the driver, Hey, I've prepaid your contract, You should come pick me up.

So this is what the passenger sees: Your driver's coming. There's still a bit of details to implement. This is just a demo, I still need to implement, for example, like the location of your, of your driver and things like that. But as a demo, this is just, you're waiting for your driver to come, Let's say he never shows up. It's been 20 minutes, 30 minutes. He doesn't show up. Whatever you're in a hurry. you need to go. You just hit X and, and the ride cancels. The payment never goes through. Right. But let's say the driver did come pick you up. So the driver here now sees your location, And they're like, Hey, go pick you up, your passenger, Like the driver goes, picks you up, You have a nice ride. They take you to where you're going. you get to where you're going. The passenger hits accept and the payment now does get finalized. It says it failed here, but this lightning wallet isn't the best. If you notice the balance, it did get sent and received. It's also kind of weird because you're paying with the same wallet. if I was doing it with another user, it would be a better demo. Right. But yeah, the payment is received on the other end and the ride is finished and you can go request another ride.

Yofu： just one small question, you said, uh, when he takes the rides and he transports him to the place he went. So after that, what if the passenger doesn't pay, how the driver receives his money?

Roadrunner： At that point you are in someone's car and you are denying them their payment. I think if you are taking the risk of like, do you know what I think? Well, a lot of drivers already take that risk.like for example, Uber and a lot of these companies already give you the choice to pay in cash and drivers have no way of knowing if you have the cash or not. but as a passenger, would you really get into someone's car and then get to the end and be like, Oh yeah, I didn't pay you. Like you're, It's a problem for the driver, but it's at that point, the driver has you right next to them.

Yofu： Right. So I know the risk is very low, but how can the platform, I mean, your platform can assure that to solve that.

Roadrunner： I understand your concern. My response to that is that the platform is a peer-to-peer platform. Disputes as a service are peer-to-peer and disputes are also peer-to-peer. At no point in the service, can this, can the platform keep your money? So, the money goes either to the passenger or to the driver. There is no other outcome.

So just as the service is peer-to-peer, the dispute process is peer-to-peer.I know this isn't the answer that most people like,we have become very accustomed to platforms being very user coddling. I would say in a way of like babying you around,if anything wrong happens, it's the platform's fault. And I understand that, but I also don't, that's not the philosophy I want. And it's not the philosophy I think that Nostr builders will be building with.I think if you are going to get into the peer-to-peer philosophy, you also have to understand that, if you're using a peer-to-peer service, you are also taking that peer-to-peer risk in a certain way. And I don't think any peer-to-peer platform has solved this.

Yofu： It is doable to do an intermediate wallet, for example,Your platform wallet, and then the client will transfer the money to the platform wallet temporarily. And then when he finished, like you can, the driver can receive his money from the, I mean, like.

Roadrunner： The problem you keep running into is who verifies that the ride was successful. That is the ultimate problem. Because right now what I'm doing with the contract is kind of like that, Like you can prepay the contract and then someone has to decide, I could give that choice to the driver as well.But then what happens if you prepay the driver and the driver doesn't show up and just hits accept to the contract, You start running into a lot of issues of who you are going to ask to verify the ride. There isn't a clear answer, the system I designed has been designed after speaking with drivers specifically and raising this issue, Of people who actually like to ride, use these platforms to offer rides like drivers. And what they've told me is that, yes, like users have the financial upper hand,Because they like every platform, both Uber, Indriver,any of these platforms always gives users that ability of canceling the ride. And no right platform will tell you otherwise. Like if a user has the financial domination over the driver, what platforms do to counteract this is give drivers.The rating benefit, So give drivers more information about the reputations of users. And I'm still working on those designs, but what I'm trying to do is, for example, give drivers a very accurate representation of how many times a user has accepted a ride and how many times they've canceled it, Because if a user accepts a bunch of rides and always cancels them, that's not a very good user, And you should be able to, It might be impatient, or it might be someone trying to scam or it might be whatever, whatever option, right. But it's not a good user,But for example, another user who has accepted a bunch of rides, but also settled all of them and paid the driver accordingly, that should be a good user, And that should be reflected and drivers should be able to see what type of passenger you are before deciding to go pick you up or not. So that is still something I'm building, but the tools are there. Like I have all the data, all of this is Nostr events that are getting put to the Roadrunner Relay,So I own that data, just like I was talking on the talk, and I can choose to decide what to do with that data, I can present it to the drivers and say like, hey, this customer has a 90% settlement rate,And they're good customers. This other customer has a 20% settlement rate, And you as a customer have to be mindful of that, that you will be accumulating a rating on this platform. It's not a perfect solution, but it's, I'd rather do that than try to get into a dispute. Did the driver really get there or not? Did you get to your location or not? Like that is a lot harder because then you have to start thinking of like, am I tracking users on their devices, which is something I don't want to do. I don't want to track users. If you notice here, I'm not giving.I'm not asking for your data, right. I'm just, you put the location. So there's a lot of nuances to this.

Yofu： Thanks for answering my questions. One more question is, what're your upcoming features that you're going to implement to the platform?

Roadrunner： Yeah. Features, like I said, I still have to do a lot of reputation stuff. I don't know if you noticed, but there was a little reputation. There was already a star thing on each of the profiles. That's just a very basic reputation system that I set up. So I'm still working on more nuanced reputations to give more information to both drivers and passengers. So that's features that are coming up. Also features of seeing where your driver is. I do also want to allow some better location tools, for example, like looking for a specific address and just the banner goes directly to the address, small details like that. It's like UI enhancements. I also, there are a couple of features that I do want to enable that are more Nostr enabled things. This will take a bit, like, I do want to make sure that the platform is working correctly before I start implementing more. And it has to do with accepting and finalizing rights. And one example is I can give you, let's say like you are at a party and you're a bit drunk and you ask, you ask someone to request a ride for you on your key, You request the ride, but perhaps you tell your friends at home or your family at home, like, Hey, I'm taking this ride, follow my key.And then maybe you can do like the settlement ride of the payment isn't done by your key, but for example, by another key. So then the driver knows that he can't get paid unless you get home, for example, things like that, that are, that I'm still working on or designing, but like, there's a really, a bunch of cool stuff that you can do like sharing keys between people, to do different types of, of verifications and love, like requesting rides for your kids.For example, and, and paying or paying rides for other people. For example, like, Hey, I'm stuck here. I need someone to give me a ride.Can someone pay for this lightning? So stuff like that, or more like to give more freedom to users. But yeah, that's a bit more with more time.

Yofu： Yeah. I appreciate you answering my questions and thank you a lot for the amazing presentation.

Roadrunner： Just to end on an open invitation for anyone to go into the app and play with it. You're completely welcome to play and try and ride and just all you need is a lightning wallet. Like I said, a test net lightning wallet. This is not real money. This is test net money. Like if you open this page, they'll give you like $80 to play with and go ahead and play, try to be a driver, try to be a passenger, give any feedback that you might have on the platform. I'm happy to get it right.and that comes from people just testing it out. I also want to see if none of my services break. So again, go ahead, play with them, try to break everything. And if it breaks, I'll be happy to fix it. Right. Let's just let me know, open invitation to everyone.

Yofu： For sure. Yeah. Everyone can see this road runner details on the Hack Nordstrom on page, the BUIDL. And there is a, I think that you, you already put the links there,Everyone can try from there and read more about this. And if there is one more discussion about it, you're welcome to join the Telegram group.

This is the first workshop for the Hack-Nordstr-On on this hackathon and which is hosted by YakiHonne.com and sponsored by DoraHacks. And Thanks again to the speaker, to all the audience here, to the community, to 42, to Isaac. And this is it. And our next workshop will be tomorrow, which is 19 o'clock or 7 PM GMT,So stay tuned, and subscribe to us.

---

YakiHonne.com is a Nostr-based decentralized content media protocol, which supports free curation, creation, publishing, and reporting by various media.

Follow us for more daily features:

• Telegram: https://t.me/YakiHonne_Daily_Featured
• Twitter: @YakiHonne
• Hack-Nostr-On, Win 35,000,000 SATs NOW: https://dorahacks.io/hackathon/hack-nostr-on/detail
• Nostr pubkey: npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q