Gateway-Free by Design: Building a Browser for Permissionless Networks

Transcript

[music] >> I have minutes have passed faster than I was expecting that. And you know what? We have a very interesting speaker coming next. He's not just an expert in decentralization. He's not just a true believer in crops values of Ethereum. But he also came for the first time to Devcon because of that. And that means a thing or two about how Devcon really is related to Ethereum and how Devcon attracts people here.

So, we're going to be Our next speaker is going to be talking about a weak point in decentralization. What if you have a decentralized system that at a certain point converges to something centralized? Like your browser, for example. So, let's figure out is there a way to have a fully decentralized browser with things like swarm, IPFS, ENS, and much more built in? Our next session is gateway-free by design, building a browser for permissionless network.

Please welcome on stage Meinhard Band. >> [music] >> Hello everyone. So, good to be here. And as it was mentioned, this is my first Devcon. I've been in the crypto scene for like 15 years. But first time really in the epicenter of Ethereum, and it's pretty cool to be here. And yeah, just to kind of start things off, who here uses a browser?

Probably everyone, right? So, who is using kind of a mainstream browser, Chromium or like maybe even Firefox, Chrome? Okay. Anyone using Brave? Okay, quite a lot of you. Anyone using Freedom already? Hey, cool. Hey, fanboys. Nice. Good stuff. So, yeah, browsers are a central element of your experience, also of your security aspects that you have in the Yeah, Web3 space. So, they have enormous power and responsibility as well. So, that's why we started off building a browser that takes all this in mind and really optimizes for the decentralized experience.

And so, that's what it looks like. So, that's Freedom. Um It looks like a normal browser. That's the idea. It looks like Chrome, not by coincidence. And all of these logos here, that's not just people we know or like that we have met or read about, it's actually what we ship. So, we ship all of these protocols and nodes, and we're live on three platforms with the mobile platforms coming. So, as you can see, there's a lot to unpack here. So, let's go. Um so, for decent decentralized apps, um the servers are mostly gone.

You know, it's it's hosted on decentralized technologies, but the gatekeepers state, and sometimes we're even reintroduced. So, we have HTTP gateways, so you have this super fancy peer-to-peer app, but it's still coming through a centralized gateway that runs on HTTP. And DNS as well, many of the dApps run on old traditional DNS, and we've seen hacks. It's it's vulnerable, it can be censored. It's just not the the way to go these days. Uh we have the extension stores that ship your Rabby, your MetaMask, and so on. They can also just remove things or kind of allow you or disallow you certain things that you can do with your extension. And then also the the wallet extensions themselves, they are often centralized, and you need

to trust them, right? So, they are keeping you from certain features or certain protocols that you can use. So um Um we have like a few questions for developers that every developer should ask themselves. So, when they are designing an app, so and and specifically loading a page. So, who resolves the name? So, who is actually getting you that result and can you trust them? And also, who serves the bytes? Who serves the actual files? And who verifies that? So, serving is one thing, verifying, okay, is this actually what I wanted to have and is this or was this been tampered has it been tampered with on the way or by the actual source itself? And also,

who ships the code that allows allows me to view these things, to interact with these apps? And also, who sees the request? Who sees my metadata? Who can kind of spy on me checking which apps I use and who is not who doesn't? And so, we have two answers for this for two different scenarios. One is using a gateway, a centralized gateway. And um most of the question most of the answers are gateway, gateway, nobody, and then extension store. So, you have to trust Google or you know, any other centralized authority to give you that code and to allow you and they can definitely get keep. And who sees the request? Gateway, of course, as well.

For Freedom, things are a little bit different. Um we resolve the name in the browser. We ship our own nodes or we ship nodes with the browser that's download the files. Verification is done and it's done on the browser in yeah, cryptographic ways. And the sort of code that allows you to interact builds is built in and ships with the browser is open source, you can review it and it's sort of protected by that and we have full access. Nothing is between the browser and or the website and and the wallet really uh if you want to interact with a financial use case.

And the peers see your requests. So, no centralized authority. And our answer to solve all these things is yeah, making the browser a node. It's not just one node, actually, it's five nodes. We ship five different nodes and that makes the browser a fat client. So, fat client sounds a bit bad because we were always striving for a thin client, but this is by design because it brings the trust from the server back to the client. You can You can verify everything on client. You don't have to trust a data center or like Yeah, big corporations, governments that can block you. So, it's it's a This is by design. And um Yeah, so it ships with uh nodes as I

mentioned for Swarm, IPFS, Radical It's a decentralized GitHub. And um it keeps the keys on your device and it's forkable, it's open source, MPL license. So, it is Yeah, in a way the browser of our own dreams that we've built. And that's kind of the structure of how things relate in the nodes. So, we have um the tabs that hold the websites. They are sandboxed per site. So, that's kind of a security layer in itself. Then we have the main process that exposes no local ports, no IP ports, no TCP ports. And that holds the IPFS node, the Radical node, ENS

verification, and also the wallet code. We have that as supervised side processes. This is all on desktop. We have Swarm We have a light client for Ethereum and also Tor since recently. And these connect nicely to all of these networks. So, we have five networks. That's the current count. The idea is to make this grow with whoever wants to join or whoever we think is a good candidate for being included. And yeah, we built our own Swarm node. So, Swarm being this decentralized peer-to-peer file sharing network or file network. And um it's it's called And. And it's built in Rust and after B, just smaller. So, B is

the Swarm Foundation's maintained client. And so, we the biggest numbers are that really it's 7 megabytes instead of uh, 20 plus megabytes for just the node and it connects to 100 nodes in about 1 or 2 seconds. So, it's super fast in and reconnecting. And, it speaks the Swarm implementation the the sort of reference implementation API and it therefore becomes a light client that's not so light. It does a few things that other light clients don't do. So, it's it's already quite capable. It just doesn't store files or content of other people. That's the only thing it doesn't do.

And yeah. We uh, while we were at it, we also re-implemented IPFS for similar reasons. We wanted it smaller, more portable, faster reconnections and also have sort of an idle mode where it doesn't connect to nodes just kind of does a hot load when whenever there's an IPFS request, but otherwise stays quiet. Um, yeah, and it's about three times smaller than Kubo, the IPFS implementation that's the reference. And, for publishing to Swarm, so it's not just a reading node and a reading browser, it can also push out content to Swarm Swarm specifically.

And, for Swarm publishing, you can either pay for it or you can get sort of a free tier like if you push into the network, free is works, but it's relatively slow and if you want to push a lot of content for example for a stream or large files, you need to pay the nodes like fractions of cents for a megabyte. Very very small, but we support that and it makes the pushing of content a lot faster. And, it took us a while to to get that right. The economics and also the implementation behind it is quite tricky, but yeah, that was quite a lot of work to to get that done.

And, also Ant Stream is a sort of little child of Ant which is for live streaming for fully peer-to-peer live streaming without CDN. So, you push from for example from a mobile app into the Swarm and then another client for example Freedom takes directly the the chunks of video from the swarm. So, there's no central server yeah in involved and it works really well. It's actually pretty cool to see. Um so, yeah.

The small issue is that our nodes are not really servers. They're not always on. They don't have the memory that you need sometimes or they don't have the the storage that you would need for terabytes of of data because they live on laptops and mobile devices. So laptops fall asleep. People quit the app quit the app. Mobiles kill the processes in the background all the time. So, we need to be working with that. That was also part of the reason why we implemented our own peer-to-peer implement implementations of the protocols. Um so, yeah. Fast wake up. That's the thing. So, whenever the the app wakes up again, we need to also wake up and to connect to peers again very very quickly and we need to listen for that. So, that was quite a lot of

work to do as well. And um is as you switch on the browser, Swarm and IPFS are on by default and the other three nodes are opt-in. You can decide yourself if you want to use them or not and also disable them in the settings completely. Um so, the download on desktop is quite chunky. So, with 200 megabytes not the smallest app, but noteworthy is that only 30 megabytes of this is the five nodes. So, they are like 6 megabytes you know per node per protocol, which is pretty cool. So, like Rust helped us to be very very efficient there in in every every regard. So, that's pretty cool. 70 megabytes is the app code. We can totally slim that down and then the

biggest chunk is Electron Chromium, which we're based on at this point with 100 megabytes roughly. Um yeah. So, that's we optimized a little bit, but we can still optimize especially on the app code and Electron Chromium part. Um The protocols show up in the address bar. Uh so, BZZ for Swarm, IPFS for IPFS obviously, Radical, and Web3. so we also support uh content being generated by smart contracts directly in Ethereum web 3.

And uh the um yep. The hash and uh the name are the origin uh in the JavaScript app that you're building. So, like your local storage that you we use uh is all kind of named by the ENS name, for example, or um by just the content hash if you don't have a name. So, you can build complex apps and they will remember uh when you come back to the page uh yeah, use the local storage and other security mechanisms uh built into the JavaScript APIs. And uh this is what this looks like in practice. So, you see swarm.eth, you just type that.

It extends the protocol. It first looks up what is the protocol, and uh that's what it finds here. It sees when it looks for the ENS resolution, it's swarm, and then it's uh gets the hash, and uh then goes out to the peer-to-peer client and says, "Okay, give me uh the content that you find for this hash." And um the name resolution is uh in this case verified by Colibri, which is a yep, a proof verification, not a completely decent less solution, but uh at least we we verify that the name is correct. And um yep, that's uh kind of already what it looks like browser. You see uh there's a small note menu there, the wallet menu

there. It looks very unthreatening. That's the idea. And uh if someone is naughty enough to uh type eth.lemo into our browser, uh um we tell the people, "Hey, you don't need this actually. This is freedom. Uh you can do this without the gateway." So, um open always with gateway or kind of uh just you don't want this maybe for some reason for debugging or whatever. So, it kind of um helps the user to use the decentralized um yeah, alternative. And shout out to Peter here to suggest this feature and also partly implement it. Very cool.

So um names I just mentioned are a huge trust boundary. So, that's why we put a lot of attention into getting this right. So, we have uh the light client that verifies first tries to verify the name or resolve the name. If that fails for some reason, it switches over to Kolibri and proofs. And if that also fails for some reason, Kolibri being down or whatever um then it uses a quorum of RPC hosts, not just one single RPC endpoint but a quorum at least. It compares the results if they uh don't match, if they don't agree, uh verification fails. And uh yeah, the the user's being shown a screen, a warning screen that there's maybe

something fishy happening. Um That's uh the same thing in just a chart. Light client first, Kolibri proof, RPC quorum. And the results are verified. That's the the happy path. Um Unverified, it asks, "Hey, I couldn't really verify this. There's some disagreement here. What do you want to do?" And if they start up conflicting, uh then it blocks the opening of the page. And uh yeah, Devcon also has an website which is open here.

And uh yeah, uh same as before, name is verified by Kolibri. And yeah, more and more people on more and more websites uh uh or more and more um ETH domains have websites connected to them. So, usually they they're just a fancy way to show off on X that you have like your your your ETH name. But here they can be really useful as a website as well. Um As a security model, we treat every tab as hostile. And uh the pages don't have direct access to the uh let's say peer-to-peer APIs. They go through JavaScript APIs, for example, window.swarm.

And uh in that case, the BZZ on Swarm is read-only by default. But then the page can ask, um "Hey, can I write to this network or to this protocol and um this means there's no real um supply chain for the extensions possible. That's that's sort of a side effect uh because it's not an extension, it lives in the browser and it's very tightly integrated and the security model we can just design ourselves, which is pretty cool. That's what this looks like. Uh swarm.eth wants to talk to a window.swarm for example and it asks these things uh and kind of like a typical almost OAuth it asks for different permissions and has a fine-grained permission system for that.

Um publishing in one flow that's also something we spent a lot of time on. Uh the swarm publishing used to take a few manual steps and you had to know a lot of uh sort of vocabulary to understand that. Here it's just uh open storage, choose uh the megabytes or gigabytes you want to have, do one crypto payment and it does the rest for you. It's like 1 minute to confirm and then it kind of uh opens and uh yeah, it just works like that out of the box, which is pretty cool. Um so publishing looks like this. We uh just show you a screen. You can publish a single file, a folder and uh just some text if you want and you will be returned just a content hash uh that you can then connect uh via ENS

to your domain and then people can easily reach it. So what we still trust, we still trust the RPC nodes to a certain extent. We don't trust them fully, that's why we compare. Um and the proof service um IPFS has this uh special routing of content where the content router sees uh the the content you are requesting. So that's also kind of a leak. And uh we trust our own website, which of course we have in the clear web a website where um you can download our browser. That's kind of the last time you see the clear web ideally. GitHub uh we host some of our releases, some of our content. Apple Store also we trust and uh the keys on your device. So we trust your device

that is sort of safe to safe enough to to uh store the keys. Uh the elephant in the room, uh electron. Why are you doing this? This is crazy. It's like unsecure. It's too big. Blah, blah blah. Um it's the fastest way to get a browser going and it was coming from the prototyping phase and uh yeah, it allowed us a lot of to kind of get going really fast. Um the issue obviously fixes arrive quite late because they follow this chain. And um that's why we're currently researching either our own builds of Chromium or other engines and kind of just replace the rendering engine and uh yeah, kind of go forward with another engine. That's kind of

uh work in progress. Uh in terms of um user experience or UI, uh yeah, we design for failure. So, uh we fail hard and loud. Uh so, if Tor a Tor node is not reached, it fails. It shows a message. Uh name conflicts show a message. Always to educate the user also that's uh there's a lot of trust in between. Um yeah, so this is what that looks like, the failure. I'm also quickly going to touch on the uh yeah, that's our uh statistics so far.

Uh we didn't do any marketing and we still reached like 150 countries. Albania, the recent one to join. Shout out Albania. And um this is built mostly by agents. Tons of PRs merged and uh it's two people steering. Uh it's flowing mostly from his uh desktop. I work from my mobile mostly actually. We have an agent that loops through this and that's what my uh work screen looks like. I have like a Telegram uh group for many many projects and I kind of while I walk, I can kind of work on them and uh steer also the factory which is you know, when the agents are running, they're being displayed here. And just to kind of make it a little bit of fun

and because we can and while I was waiting for some agents to finish, I was just live coding this stuff. And uh the releases are more or less an API now. It has many many steps and agents can steer it, Uh a script can steer it or while we are at it make it some fun. We have like Freedom Craft which is a Minecraft clone. You can walk around, hit these buttons and then kind of release things. So, it's not a drag to release but it's really kind of adding some fun. What's next? Shared Rust core. We are extracting logic from the Electron application, put it into Rust Rust which makes it possible to share the code between platforms, mobile for example.

Also easier to replace Electron and we have also on the to-do list fewer intermediaries. The things that we still trust, that's our to-do list that we want to work down to trust less people. Um what you can take home from here, ask the five questions. Go back to the first few slides, you will remember those questions and um make the clients uh yeah, like the nodes kind of integrate uh like fat client logic to be trustless and also to fail visibly. And yeah, that's brings me to the last slide. freedom.baby As I said, your last time you will see a clear website.

freedom_browser, our Telegram group and also our new experimental community freedom.davinci.space. Thank you very much. >> [applause] >> Fantastic, fantastic, fantastic. I was listening to your talk and I can't stop but wonder how we ended up not having this thing from the very beginning when we started all these decentralization moves. Correct? >> So, there was a thing called Mist, you might remember it which had a similar approach. It included a full node which in the early days was, you know, a viable thing to do. These days obviously it's not anymore so you have to go and jump through all these loops. But we're in a way reviving the old mission or

like vision of Mist. Yeah. >> Okay. Now let's move to the questions from the audience and the first one will be what is the thing you will do differently in Freedom Browser should you have a chance to start from the very scratch? >> Huh. Yeah um we would It's not so many things actually. I think uh the thing that I mentioned the the Rust core uh or the the Freedom core in Rust, uh that's something we would start off with that we uh take the business logic into one uh you know API internal API API that we can just exchange the interfaces from.

And um that's one thing. Electron, I think I would go for again because uh it's an easy way to get started. It gets a bit of heat from people, rightfully so, but um it has served us well, so I would do that again. What else would I do differently? Maybe [sighs] Yep, I don't know. It's We we try to do a lot of things right, so I can't think of so many things. Maybe start with more protocols from the beginning to have a better comparison between the protocols. Mm.

Yeah, that's the kind of main main things I can remember right now. >> Okay, you're a proud man still standing with Electron. >> It's good. >> Moving up next, uh is there a reward mechanism for users like a token or similar to Brave for using Freedom? >> Um the answer is not yet. So, this comes down to our nodes being light clients and not full clients or like full nodes. Once we have a full node on the browser and we could say, "Okay, you can share some bandwidth uh for example for the Swarm network or you can share your storage." Uh you could take part in the um incentivization mechanism of Swarm and also earn some some coin some way.

Um I think on demand we would do it and uh I think it's a very powerful way to get the peer-to-peer aspect of this going. So, once we have like uh 10,000 Freedom browsers running at the same time, it becomes a peer-to-peer network itself through WebRTC. There's quite some cool things you can do with that. Uh even if it's just messaging or relaying other things or, you know, like detecting ad blocks and these kind of things and then improving itself. Uh, we have experimented also with letting your agent, we have an agent built in as well. I didn't mention that actually like a like bring your own model agent that you if you have a big GPU you want to share workloads with other people on that peer-to-peer

network they could outsource stuff to you and they could pay you for that as well. So that's something we experimented with and we we would do it on demand if we have more people asking for it. >> Yeah. Interesting. Okay, let's then go to this one. Why should people transition >> Second. >> from let's say Brave to Freedom? >> Um So the honest answer is not yet, wait a little bit more. So we added a lot of daily driver features and then I'm using it as a daily driver a lot. I would wait for at least the mobile platforms to be available as well and also having syncing between all these browsers and features are like that are missing are

like password management. So it's relatively small things, we're getting close. But that's so that the everyday use side why would they switch? I mean if you want real peer-to-peer access, that's the only choice really that you have. That was also the original the origin story. I I did some research because because I thought this would clearly be out there somewhere a browser that you know, lets you directly peer speak to peer-to-peer. It wasn't. So yeah, if you want to also follow the Ethereum mission of like solving the access layer currently there's no alternative out there. So yeah, I mean if you want to develop for that, yeah, there's no other choice I think I would say.

>> Okay. >> viable choice. >> And let's wrap it up with the last question which would be technical and again my beloved questions. Beyond storage and electron depth, how do you balance the RAM, CPU and bandwidth overhead for for running multiple peer-to-peer nodes locally without compromising everyday browser performance? >> That was a surprise learning also for us that they don't take as much. I mean, they are hardly noticeable. So, an animation in a in a Chrome tab or like a page with lots of ads takes a lot more CPU and and memory than than all of our notes do together.

They're very lean and again, there Rust helps us a lot to be kind of very memory efficient. And also on mobile, it's hardly noticeable. The on Android the phone heats up, warms up a little bit but generally it's not so much of an issue as we thought initially. So, there's not much we need to optimize. We do optimize but we're already at a very good level and the daily browsing is not affected actually at this point. >> Wonderful. So, not just decentralized but also performant. >> Yep. >> Okay. >> [music]