Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. Today I'm joined by Backseats and Frolic, two independent full stack Solidity devs, for a conversation about their latest projects. First, we discuss Backseats as yet unnamed NFT primary marketplace browser extension. His work in progress idea is to deploy an NFT discovery browser extension that populates new browser tabs with one of one NFTs for sale from the artist. Artists will list works on chain via contract interaction and artworks will be removed from circulation when sold. Second, we discuss Frolic's ETHFS, a tool facilitating on chain data storage and composability. ETHFS is a front end and smart contract back end for writing arbitrary data to the blockchain efficiently. Its permissionless and open source design aims to make it easy for anyone to write data to Ethereum that can be retrieved and composed to create on chain XML such as HTML and SVG. It was a lot of fun brainstorming on the design decisions and applications for these two interesting projects. I hope you enjoy the show. How's it going?

Frolic: Good. Can you hear me?

Nicholas: Yeah, sounds good. Sounds good.

Frolic: Great.

Nicholas: Hey Backseats, how's it going?

Backseats: Hey guys, how you doing?

Nicholas: Good. Just getting good. We should introduce ourselves. Backseats, tell the people a little bit about yourself. What do you work on most of the time? And we'll get into what you're working on right now in a minute.

Backseats: Hey everybody, I'm Backseats. Let's see. Most of the time I'm a Solidity developer, product guy, generally trying to think about crypto from a, how do we make this easier and more intuitive for people to use and not assume that they know a bunch of heavy, complex topics. I'm part of Devotion, which is an art studio project. Right now we're making like episodic NFT drops. We did one recently playing off the Van Gogh defacement at the National Gallery where you can mint a tomato can and then you can splat your favorite NFT. So that was pretty fun. And I've got a new project that we'll talk about soon.

Nicholas: What was the name of the one you just mentioned?

Backseats: Splat.

Nicholas: Splat. Okay. Where can people find that?

Backseats: if they want to look at it? Just go to OpenSea, search splat by Devotion and you'll see a bunch of tomato cans that were designed by Danny Cole from Creature World. Oh cool. And if you scroll down, you can see splatted pieces and if you go to the contract, you can splat your favorite NFT.

Nicholas: Awesome. And Frolic is also here. Frolic, what are people most likely to know you from actually?

Frolic: I guess that's a good question. I don't know. I just like to build stuff and put stuff out there. So people may have heard of Web3 Scaffold or ENS Ideas, a little domain search tool and API to resolve ENS names.

Nicholas: That's ensideas.com?

Frolic: Correct. Yeah.

Nicholas: Ethereum ecosystem experiments?

Frolic: Yeah, exactly. Been in the space kind of full on for about a year and I've just been playing with a bunch of different stuff and there's tons of room for folks with skills like I have. Full stack and front end and usability type of stuff where kind of like Baxeat was saying, there's a lot of rough edges and things that are quite hard to understand. So lots of room for building fun stuff that makes it all easier.

Nicholas: And maybe you could say a couple words on what is Web3 Scaffold? What's the idea?

Frolic: Web3 Scaffold kind of came out of my building a bunch of different kinds of products in the space and seeing myself use the same patterns over and over. So there's a lot of boilerplate needed to get up and running to interact with contracts and I guess just a friend in general and potentially like back end components and stuff. So Web3 Scaffold just kind of came out of like, I built three or four or five different like min sites and other things that shared all the same underlying stuff. So it was just a template, kind of code template and set of libraries to kind of get started building something. And so I now use it for pretty much every product I start on. And I'm trying to keep up to date with all the latest and greatest as far as tooling goes. So as of now, it's Next.js powered with Tailwind and Foundry for Solidity.

Nicholas: Nice.

Backseats: I used it today.

Nicholas: Oh, nice.

Frolic: What'd you think?

Backseats: It was awesome. My Foundry and Rust setup is very broken. So I spent a bunch of time fixing that. But it worked.

Frolic: It's great.

Nicholas: I haven't tried it yet. I got to give it a shot because it's sort of annoying redoing the same. Is there like a kind of vanilla use of Web3 Scaffold? people could check out to see like what's sort of the basic thing is it gives you in terms of UI?

Frolic: I mean, if you just clone the Web3 Scaffold repo, yeah, the base UI is essentially like an NFT contract. that's very bare bones and then a subgraph that indexes it and a front end that has a mint button. And that's basically it. So you can kind of start there. It's like a very general purpose thing.

Nicholas: That's cool. I'm going to have to start using that. That sounds great. So we're here to discuss. each of you has a new project you're working on and obviously happy to derail and talk about other things. But I figured we could start with Backseat's project, which is a browser extension. Is that correct?

Backseats: Yeah. So I have been kicking this around for a while. So what I did was I built well, half built. FTX derailed me and my attention a little bit. But it's a new tab browser extension. And associated with that is a smart contract. That's a very small marketplace where any artist can list their NFT for sale. It will show up in the browser tab and you can either just like open a new tab and see a nice piece of art or if you like it, if it hits you, you can buy it. And that's pretty much it.

Nicholas: So when you hit like command T or whatever, yeah, command T or new window, you'll get a browser tab sort of like the I don't know, the old Firefox things or whatever with. I guess Brave does it to like giving you some artwork, but it'll be an NFT. And how? I'm curious what the mechanism you're imagining is for people getting listed there. They just send you. they PayPal you they send you on FTX a little something or how does it work?

Backseats: So I built it so it was as trustless as possible. So we don't custody anything. So there's a very simple UI. If you're an artist where you can go assuming the art is in your wallet, you can approve our contract and then select the pieces that you want for sale. It will store them in the contract in a little struct. And then we pull all that data combined with some APIs to show that in the new browser, the new browser tab. And then when you buy it, how do I structure that? I have an optional royalty that you can put in there. And just based on the transaction, it'll do the split and it'll send it to to both of us.

Nicholas: So it's like an append only. or can I remove myself once I once the thing is sold or something or I stay in the database?

Backseats: Yeah. So if your piece sells, we just flip a Boolean and then don't show it.

Nicholas: Okay, so it's on like a is okay, I can picture it for like one of once. Do you have a sense of how that would work for a collection?

Backseats: Not really. I mean, like my intention was was really for once. And I tweeted a couple weeks ago, like if you are an artist with unsold work, like show me what you got. And I'm just gonna like DM all of those people and be like, Hey, give us a try.

Nicholas: And anticipate charging.

Backseats: I mean, they set the price.

Nicholas: Oh, okay. To pay to be added. It's just like a gas operation to be added to the thing. Yeah, completely. I wonder how that's gonna go. I don't know if you're gonna get spam to oblivion. Maybe you're gonna end up needing to charge for it.

Backseats: That's a good point. Yeah, I didn't think about the spam. I wanted to be super artist.

Nicholas: Artists love spam.

Backseats: Yeah, maybe there should be a small listing fee. That's a good point.

Frolic: Does this feature like one artwork at a time basically like your new tab pages like the art piece? Yeah. Got it.

Backseats: Yeah, so just like right in the center, there's a buy button, bunch of information about like what chain it's on, which will just be ETH, MedNet for now. And then yeah, price and some like info that they can supply.

Nicholas: It's very interesting. I think this NFT discovery thing is someone was saying recently, and I totally agree. It's totally unexplored. It's all left to Twitter campaigns or whatever. I don't know. And if you could actually find a way for people to like a new avenue for people to discover things, I think that could be very interesting. I wonder if people would be. I'm trying to think of a very commercial version of this that might give some incentive to installing it. Like you get some discount that's generated or only available via the extension or something. So there's some reason to keep the extension to. But I like the one of one very artistic, friendly version, too.

Backseats: Yeah, like I just wanted to I mainly just wanted to like see nice art when I opened up a new tab. Right now I have it set to the just like a blank page because I'm a big fan of the concept of programmable attention. And as someone who's very easily distracted, having like news or I don't know, really any site is kind of detrimental to my flow. But I feel like being able to open up a new tab and see like a nice picture of a wave or like some cool like pixel art or something like that, like the general value add to everybody's day.

Nicholas: I wonder if it's interesting to let the people who are posting them tag them in some way or something so that maybe as a viewer, like if it were popular, maybe I don't want everything. I want some subset or some way to do a kind of algorithmic or even like user controlled programmable filter for what shows up.

Backseats: Yeah, like just show me pixel art or just show me like anime style art or that's a good idea.

Frolic: Photography. Yeah. Backseats, do you use Brave?

Backseats: I don't.

Frolic: I don't know other browsers, but Braves, I think maybe default is the new tab is like a full screen photo that cycles through different photographers and stuff. I'm not sure how they plug into that. But one nice thing is that overlaid on top of the photo is like your recent or your most active websites that you visit. Not that I use that a ton, but like it's kind of nice to have like a HUD over the photo. But another just sort of idea or potential route to plug into.

Backseats: I like it. Appreciate it.

Nicholas: Yeah, super cool. I totally agree with you at the programmable attention stuff. I once had an idea. I never actually fully went the distance on it. But like if advertising is using our attention to program our actions, then ultimately that's the best interface for a to do list. Your to do list, your top priorities should be advertised to you everywhere that you can be advertised to online. But I think the targeting for some like Facebook and things won't let you go down to one person anymore. But there was a time where I think you could like import a targeted ad list into Facebook and only like have the same address a bunch of times or put in a bunch of addresses that would for some other reason be disqualified. So you're only paying to show to yourself or someone else. So I love this idea. I have the white. You know, I just turn off everything in the new tab thing because I find it distracting. But if it were like a cool NFT, I could see turning that on. You're using it already right now.

Backseats: Yeah.

Nicholas: So when's it coming out? When do we get to install it?

Backseats: Hopefully next week, maybe the week after. Yeah, I'm just using like random NFTs that are on girly right now. I want to sort of like soft launch it and then seed it with a bunch of art. I can give you guys the in when it's out.

Nicholas: Secret alpha. I wonder about the incentives around the spam thing. It's going to be interesting. Like you could just charge or you could maybe do something even better, but make some cost for people, I guess.

Backseats: I forget who I think. when you were talking to who was the guy who did the AGLD contract?

Nicholas: Was it Will? Yeah, Will. Yeah. Will Papper.

Backseats: I think Will mentioned like basically DAO programmable defaults. So I've really taken that to heart in my design. So just like having a bunch of things that like you set to zero with the setter. So maybe I'll set the price to zero and then I can always ratchet that up if we have a spam problem.

Nicholas: Yeah. If you want to be maxi decentralized, I'm kind of actually haven't looked. Maybe we could talk about this later, but I haven't looked at the new OpenSea royalties thing, but I'm not sure if they're doing. what strikes me as the best idea for this stuff, which is like a uBlock origin works where you can subscribe to different lists rather than having it hard coded into the client. So you can then I don't know. I'm curious if OpenSea royalties is working this way, but ideally you would be able to switch your affiliation while building in something like a block list into an NFT contract, allow you to deviate from the registry of the people who developed it either entirely or just selectively. Like maybe I want your list, but I don't want, I don't know, anime art or something. I want to avoid some category. It's interesting if you could put it on, if you can even switch which contract it's associated with, then other people could develop their own lists. But maybe that's too decentralized.

Backseats: Oh, interesting. So like multiple contracts and then as you're adding your piece to the system, you select like a tag or multiple tags and then it actually adds you to one of our contracts.

Nicholas: Oh, that's cool too. Specific for different things. I was even thinking like maybe someone wants to distribute, I don't know, porn this way or something that you don't are not really interested in having on your contracts. They can ship their own. Like it's more like a standard for these registries rather than. Interesting.

Frolic: Curation.

Backseats: Great. Now I'm going back to the drawing board. No, I love it.

Frolic: This is awesome. Yeah, I think having like a more of a curated list of artists or allowed folks make sense for the default and then you can opt into the full stream if you want or individual kind of streams of art.

Backseats: Totally. Maybe my design is a little too open right now.

Nicholas: I think it's interesting, though. I mean, I would even subscribe to the one on Gourley just to play around with it. The one thing that you're going to have to convince me of is that your extension is not going to inject transactions into my.

Backseats: So that's going to be open source because extensions are scary and they can do all kinds of stuff. And I'm a big believer in like whenever you're like anywhere near the realm of being able to like listen to behavior or key sniff or something like that, just I just want to open source that so everyone feels safe and secure.

Nicholas: Totally. One thing I do that I learned from Jimmy, a one Jimmy, is to have separate browsers for wallet and regular browsing. But this actually introduces like a UX problem because sites like Blur require that you be connected with a wallet to actually see the site. So I don't know if that's relevant. And obviously you want the mint button to just work, but it would be cool if it worked without needing MetaMask in the browser, especially MetaMask unlocked in the browser.

Backseats: I mean, the design is definitely intended to. if you just want to like browse NFTs and you don't know anything about crypto, you should be able to install the extension and just go only when you want to buy. Do you need to connect a wallet and do all that?

Nicholas: Sweet. So let's jump to ETHFS. We can come back and talk more about this project. And also, if anybody wants to come up and throw out ideas or what, please do or please request. So Frolic, your project is ETHFS. Vaxis, did you get a chance to take a look at it yet?

Backseats: I did. I was looking at it when I was in development a little bit. And as a fan of extremely on-chain stuff, I don't know. I just I'm excited for these kind of resources to pop up.

Nicholas: Totally. It's awesome. Frolics. If for people curious, ETHFS.xyz, you can check it out. It's very cool to look at. Congratulations on dropping the project.

Frolic: Thanks.

Nicholas: It's been since February. You've been working on it, right?

Frolic: Not necessarily ETHFS itself. That was a component of a larger project. And I just like the DOM tweet made me realize like, oh, I'm taking a long time on this larger project. I can kind of pull out this component of it and make a standalone thing. And that would be useful broadly.

Nicholas: For the people who weren't there, that's the the Rose, like on-chain 3D Rose tweet. Yeah, exactly. So in that case, he put did he put 3JS on-chain? Was that the story?

Frolic: Yeah. And he used some fun compression techniques to minimize the amount of gas required to get drawn chain.

Nicholas: Very cool for people who aren't familiar. 3JS is like a 3D library for 3D on the web. And then he was generating a 3D image or 3D NFT metadata on-chain. So that's what inspired you. So maybe what is ETHFS? Maybe go from the UX perspective. Like I land on the page. What am I looking at?

Frolic: Yeah. So you're looking at basically everything that has at least run through the contracts that I've built and deployed. as far as like what files exist on the blockchain. There are ways to kind of backfill if there are bits of data or files or whatever that already exist. But they have to be uploaded in a kind of specific way for them to be compatible. And I'm working on trying to figure out ways to have more compatibility with more different kinds of storage types. But as far as gas efficiency, it's one of the more optimized ways. You're looking at a list of files on mainnet and a pretty easy UI to upload new files.

Nicholas: So basically it looks like Macintosh or whatever. It looks like a couple of windows and there's just a browser of a bunch of files. It looks like a window on your computer with a list of files in a folder. And if you click on them, you can view the file and see some information about it. So under the hood, what this is, is a system for storing files in an efficient way on chain. And then you've also built this cute front end, which displays the files that are conforming to the standard that you wrote in the contract, right?

Frolic: Right. And a big focus of the project was, and a lot of the infrastructure around it is built to be the most efficient possible reading the files back out. So when you're using them in your contracts, it's going to minimize gas and minimize bytes. Both of those are important for or freeing you up to do as much as possible within the scope of your project.

Nicholas: The point being that if they were inefficiently, regardless of how expensive it is to sell them, if it's inefficient to view them, then you can't compose other things.

Frolic: Correct. Ultimately, that ties back to the project that I'm working on, which kind of spoiler is more or less a on chain geocities where you can build web pages and kind of combine gifts and fonts and other fun things onto a web page and build out your like fully on chain web page. And that will be able to be served as an SVG on like OpenSea and in your wallet. It's going to be pretty cool.

Nicholas: That's dope. So when you say geocities interactive is a part of that.

Frolic: They will be interactive, but not within the context of a marketplace or a wallet.

Nicholas: OK, what's the name of that project while we're here? Floppy Town. Floppy Town. And what's the Twitter?

Frolic: I think it's Floppy underscore Town. Let me look.

Nicholas: But I'll put it in. Yeah.

Frolic: Floppy underscore Town and Floppy.Town. If you want to look at the site, although there's nothing up there right now.

Nicholas: Dope. So maybe I'm curious about how you built this and what kind of choices you made to make it more efficient, both for the storage and for the retrieval. Can you walk through the contract like from a conceptual high level?

Frolic: Yeah, the main powerhouse of all this is using a technique called FSS Store 2. And essentially what that is, is a way to write bytecode to the chain as if it were a contract. But you can just stash whatever arbitrary bytecode into a contract that you want. So a store to is a way to efficiently write and read data. So I think anything over 32 bytes is more efficient to read and write with a store to.

Nicholas: So basically this technique, from what I understand of it, the idea is that the most efficient way to store data on chain is not to store strings, obviously, but instead to store bytes and actually to store them as if they were a contract with the appropriate header so that transactions, nodes, the chain treats it like it's a contract. But it's not a contract that anyone could actually interact with. It's just got the sort of formal aspect at the beginning of the code to the data to look like a contract. And then a store to is a library that helps you to save files that are even larger than the maximum size of a single contract by paginating over multiple of these sort of junk. looking from the outside contracts that constitute all the data you want to retrieve. That's a good summary.

Frolic: Well, I start to. I think only handles the like single contract.

Nicholas: Oh, OK. I thought. Yeah.

Frolic: And the limitation here is that a contract can only be 24 kilobytes. So that's why you need to take some sort of like trunk approach when you're uploading files larger or bits of data larger than 24 kilobytes.

Nicholas: I've mostly interacted with this through my conversation with Cyborg was he wrote Cyber Brokers, where he wrote something that does this, including the pagination piece. But it's just inside the Cyber Brokers contract custom to that. And he wrote it before a store to existed. How do you achieve the pagination?

Frolic: Yeah, so the starting at the store to level, that's just a library that efficiently writes 24 kilobyte chunks, writes and reads. The next level up is a content store, a content addressable files or content store. Basically, that means that every 24 kilobyte chunk gets a checksum or a hash based on the contents of that and is written to a mapping in that contract that can unravel the pointer to that contract or the address of that contract. And that's important basically for like deduping data over time. So say you upload a library and you upload the next version of that library. Hopefully there's enough overlap in between the two that minimizes some of the kind of like duplicate upload, although it's not particularly smart yet about how it chunks. Therefore, it's probably not doing enough to make that highly reusable. But anyway, it's an idea I'm playing around with.

Nicholas: That's very cool. So if I had a library that span three contracts and only two of them changed, the one that was common could be correct. You need to re upload it.

Frolic: Yep. Or if you uploaded it with a new name, you wouldn't have to upload all the contents. You could just re upload the file wrapper, which points out to all those checksums.

Nicholas: That's very cool. And that functionality is in content store.

Frolic: Correct. Yep. And then there's a an additional layer on top of that, which is kind of the quote unquote file system, which is the file struct that wraps all of the chunks that make up a file or all the bits that are stored in the content store. And then a name and optional metadata attached to that. And it's a kind of a global namespace at the moment. But working on ways to add kind of namespacing or directories or something so you can prefix your name with a thing and have like a folder of your own files or whatever.

Nicholas: OK, sorry, I didn't entirely follow. So the file store does what exactly? You can say the same thing again. I just didn't entirely follow.

Frolic: Sorry. Yes. The file store basically includes a library that represents a file that is essentially a struct. that is a array of all the checksums that constitute the file and are are like concatenated together at read time. And then the file store is essentially a mapping of a name to that file. So it's a global namespace, a namespace. So it makes it more ergonomic to use in code. so I can say like get file named this name dot JS or whatever. And it makes it really developer friendly, I guess, or human readable.

Nicholas: So I could write my own ways of indexing the content store in the file store.

Frolic: Yeah. And kind of the idea is that I don't think a global namespace is necessarily the most sustainable or durable way to go about this. So people might want to write their own variants of a file store that index particular kinds of data or maybe just fonts or just JavaScript or something like that.

Nicholas: Do you think that it would be to enable this functionality where, let's say, I modify the library that I've uploaded and it changes all the contracts, but not entirely. Would it be deploying a new file store that would enable me to index those more effectively or it would be off chain? How about processing is done?

Frolic: I'm not sure I'm following.

Nicholas: Like, let's say, you know, whenever I upload three JS and then they change three JS and it 99 percent of the code is the same, but they're not. They've deleted a line. And so everything is one line further back. And so every contract has changed, but not really only only one line has changed across the whole thing. That work is not done in the file store. That's done in some kind of rendering operation that's retrieving the data. Or where is that done?

Frolic: It's kind of in both. It's both in how the file is chunked and uploaded. And again, that layer is not very smart. It literally just takes the maximum possible size, which is 24 kilobytes, I think maybe minus one byte, and then chunks it based on that. So if one file midway through or one line midway through the file changes, then the rest of the file is probably going to be different relative to the content store. You still have to upload quite a bit of stuff. But it can still pass through the whole system.

Nicholas: And so if I go to retrieve a file, I'm retrieving it through the file store.

Frolic: Yep. And another thing to note, too, is that both the content store and file store are immutable in that once you upload the you're kind of guaranteed the file will be there forever. With one caveat that the file store as like a namespace does have a delete operation for the owner that I expect to eventually put into some governance layer that we can use to make sure that we can defend against malicious files.

Nicholas: Interesting. And the idea being that someone would upload a file that's revenge porn or something that you don't approve of.

Frolic: Yeah, that were a JavaScript library with something injected into it that maybe is hard to detect. And you end up using what you think is 3GS, but it's 3GS plus some way to steal cookies or whatever.

Nicholas: So the content store would still allow you to upload malicious data, but the file store is the trusted access point for it that can be controlled. Yeah, correct.

Frolic: Yeah. The content store is very unopinionated. It just checks on data essentially and ensures those checksums and address pointers. The file store is kind of like. what does the indexing of all the data?

Nicholas: Very cool. Backseats, what do you think?

Backseats: I think it's a little beyond sort of where I am in my ability to write things on chain right now and do like on chain, very on chain entities. But it's super inspirational. I feel like far enough ahead that I'm just like, I want to get to that level, but I'm not quite there yet.

Frolic: I think it is maybe easier than you think. And one of my goals or one of the next steps for this is to create a bunch of example projects and documentation that kind of shows that it's quite easy. So if you have like a P5.js like generative project, it's not much more than including your P5.js code. And that could be uploading that to EFS or writing it directly into your contract and then including the library and spit out HTML. and you're done.

Backseats: I love it. I think it's just one of those things. I haven't done it yet and I haven't made the time to do it yet. So it feels intimidating. But as soon as I do it, I'll be like, yeah, of course.

Frolic: Yep.

Nicholas: So if you want to consume like I'm looking here, maybe this is not a good. I'm looking at the Hasselblad PNG, which is probably not a good idea for composition. Let's say I want to use this hello world. TXT Rose composed in another contract. I know you kind of just said it, but what I really have to do.

Frolic: If you're looking at that file viewer and you scroll all the way down, there's a little bit of a code snippet there that kind of shows you the piece that's missing. here is actually getting that interface, the I file store interface. And both of those are important to know, like how to retrieve the data out of the file store and concatenate it into a string. Just kind of like the main pieces is concatenating the file from this file store, but wrapped in the, I guess, HTML container that is needed to render it out. And in this case, it's a data URI that represents the image.

Nicholas: Extremely cool. So just to summarize that for people, you just instantiate an I file store compliant object contract pointed at the address of where it's deployed and then string doc and cat. And then it gives you a little snippet and you've got whatever the thing is that was stored.

Frolic: Exactly. And I actually, now that I'm looking at this example, I can see it's missing the contract address. But if you look at another one, say the GNZ scripts, it actually has a contract address in there. So you can copy and paste.

Nicholas: If they're uploaded with the front end, it seems like it automatically adds some metadata that makes this display nice. It's like a copy pasteable thing, which is extremely cool. I really want to try this. And speaking of GNZ scripts, what is that? Is that something you uploaded for your own purposes?

Frolic: Yeah. So there is another piece built into EFS and again, taking heavy inspiration from Dom's 3D rows and how you officially got that on chain. Basically for libraries like 3JS that are incredibly heavy, it's really expensive to get those on chain. I think 3JS on its own would be like 30 transactions and a couple of ETHs probably. Basically to get that more efficient, we compress them using GZIP and then you need utilities in the browser to unzip on the way out. But unzip before you execute the JavaScript. So what ETHFS does for you, there's a little checkbox when you upload a file, particularly a text file that allows you to compress it. That will compress it with GZIP before it does its chunking and basic C4 encoding. And then that reduces the amount of transactions and gas required to get the file on chain in its compressed form and then metadata attached to it to tell the front end that like, hey, this is compressed or tell the indexer, hey, this is compressed. And then on the way back out, you just include the GNZIP scripts library at a particular place in your HTML and that will automatically kind of decompress the compressed JavaScript before it's executed.

Nicholas: Cool. So just for people who are not as comfortable with this stuff, basically it's like right click compress to the files before writing them on chain and then you've uploaded the right click on archive. You've put that on chain and it can be included into people's files so that they can be drawing on other compressed data on chain. So it costs less to upload it in the first place.

Frolic: Yep, exactly. And it's only an extra six kilobytes of data total.

Nicholas: This library library.

Frolic: Exactly.

Nicholas: The six kilobytes is relevant when you're thinking about spending too much gas on view functions.

Frolic: Both gas. I mean, gas will be kind of a reflection of how many operations you're doing, how much concatenating you're doing, how many bytes you're loading. So less bytes, the better. And then there's like a tradeoff. And I think the front end handles this already, where like if the file is under six kilobytes, it won't offer the option to compress because it doesn't make much sense. But if it's over six kilobytes, it offers you the ability to compress because you will add that six kilobytes to the read time when you're building out your HTML page.

Nicholas: But it would actually be cheaper to use it. Like, let's say I'm uploading an image that I want to put on my website, on my GeoCities, on my floppy town. Then I do want to compress it regardless of me not having the unzip. Like the view is someone else's problem. Potentially, right? Like this website that we're looking at, EFFS could have GNZIP built into it so that all these images could just be compressed on chain rather than uncompressed on chain for lack of GNZIP in the hypothetical. I can see that reasons have both, but I don't know if I'm following. Like you're not compressing files that are less than 6KB because it implies importing a 6KB library into the viewer. But if I'm viewing it on a website that's off chain, then they could either be doing that. The view cost is less important to me as someone storing an image. As someone storing an image, I just don't want to pay as little as possible for storing that image. Totally.

Frolic: Yep.

Nicholas: So maybe sometimes it is worth it if you know that the viewer will have GNZIP one way or another.

Frolic: Yep. Yep. That's true. Another thing to consider, though, is the gas on the way out. And say if we're looking at 3GS again, it's a very heavyweight library. I don't know offhand what the total kilobytes is uncompressed, but it's quite a bit different compressed and uncompressed. And that factors into the overall weight of the token you are. If you're serving a fully on chain project, the token you are is effectively going to be a URL encoded, JSON encoded blob of data that then has HTML inside of it.

Nicholas: That's all of that.

Frolic: All of that, like kind of like boilerplate, going to boil down to like quite a bit of data. And so you want to minimize it as much as possible because your ETH node will only read a certain amount. I think either in terms of gas or stringing.

Nicholas: I'm wondering if there's a second issue, because I'm aware of one that people may not be aware of, which is when you get the metadata for an NFT, you call this token URI function and it has to be called on Infura or some node somewhere. And some of the nodes will limit how much gas can be spent on that view function, even though you're not passing a transaction on chain, even though you're not paying for anything. They're covering the cost of the compute to return it to you. And they won't compute more than typically. Well, I think some nodes are 30 million gas, which is the gas limit for a block. I believe that's still the limit. And others may be archive nodes or alchemy. Some other more premium RPCs will give you more, but no one's really sure how much.

Frolic: Yeah. Yeah. It's quite hard to introspect on that. One of my other to do list items or goals is to kind of create a comprehensive test suite that I can really test the limits of what is OpenSea willing to render, both in terms of bytes and in terms of gas.

Nicholas: Cool.

Frolic: So I would like to put a report eventually. that's like, here are all the marketplaces. Here's what you need to do to maximize compatibility with them.

Nicholas: Do a tip jar. I want to toss you some ETH to do that. That sounds cool. OK, so a lot of different issues going on here. The other one is that you want to minimize how much, if you can avoid it, you want to avoid importing a library, et cetera, because you also want some of this data to be composable. and or you might want some of the data that you're storing on chain to be composable. And if it's compressed, they need to. Is the decompression with GNZIP done in the client or it's done on chain? It's not actually done. Is it actually done on chain?

Frolic: No, it's not done on chain. Still, the ultimate goal is reducing the amount of gas and bytes flowing through the chain. So we pack it with a big, heavy library on the way in. So it's minimizing bytes on the way in and we get minimal bytes on the way out and then unzip it on the client.

Nicholas: Right. So the files that are zipped and stored on chain are not composable in the sense that you can't read the values and act differently upon them in the context of another contract on chain.

Frolic: I guess that's true.

Nicholas: Maybe it's hypothetically. you could, but you'd have to find a way to inspect inside of a zipped file.

Frolic: Yeah, correct. Which you couldn't take a slice of the data that zipped in the file with it making any sense.

Nicholas: The example I think of is like loot or something like being able to generate another contract that's aware of those values. You couldn't be storing those values inside of a zipped file, practically speaking, in the gas limit. I don't think.

Frolic: Yeah, I don't know enough about compression algorithms or putting that on chain. But yeah, I assume it would be like way too gas intensive to be worth it. In that case, you would probably just store plain text.

Nicholas: Right, right. Or some kind of packed you and something. Yeah, sure. That you're aware of or that other contracts that are deployed subsequently could be aware of. That's pretty crazy. So I'm trying to think because I'm very interested in this like Ethereum web server model where we stop depending on IPFS, but instead write code that can execute on chain. The one I'm most excited about is getting wallet access inside some of these things. I think that will be truly next level. And I'm thinking, sorry, go for it. What were you going to say?

Frolic: I was just gonna say. one of the things that I want to play with very soon is essentially the minimum possible, I guess, code needed in a client, like the lightest possible client to kind of boot data from on chain. And so once you can retrieve data from the chain, you can then pull down scripts and other things to build out whatever you eyes or applications.

Nicholas: Can we convince Johnson and the ENS people to or is it even them? Yeah, I guess. then like text, we need a text record. It's not even them. Yeah, their thing is already mutable to the point where we can make it happen. It's really metamask and brave that we need to convince to resolve ETH colon slash slash or ENS or whatever you want to call it. And it goes to token URI and fetches the image field of the token URI or some other field, I guess.

Frolic: Yeah, it's interesting. I don't know the whole history behind this, but there is a way to have your ENS domain domain resolved to a website. But the way that you do that is by pointing it to an IPFS hash or a couple of other things. And I think the record type that stores that used to be just a plain kind of like string field and is now a much more tightly controlled field. or is it a schema rather?

Nicholas: There's an EIP for how you can address contracts in that. I was partly involved in that asking about can we have I don't want my avatar field to be a static content ID or IPNS. That's stupid. It should be a token URI from an NFT. And so they ended up doing it. I forget there's the EIP that you have to conform to to set those image fields. But it doesn't do like I wonder because you can return base 64 straight. If you could get base 64 into the browser address bar, then you can just render pages like that. I did a stub of a project trying to do this. I wonder if there's reasons why that would be a terrible idea for people to do.

Frolic: But yeah, I don't know the security implications, but I do want like a text field that I can put a data URI into because that would like unlock me just injecting all the HTML and JavaScript needed as a quote unquote bootloader to then like pull in all the libraries that I need from the chain.

Nicholas: Yeah, exactly. Exactly. This is the thing, because you could imagine I had previously thought about this. It seemed when I last thought about it deeply that the best way to do it right now would be to have one IPFS CID route that gives you just initialize it, just a web context, a page context in order to start doing all this stuff. But it really sucks that you even need that. There should be a direct to an ENS text record, base 64 on chain rendered in browser with no IPFS required at all.

Frolic: Yeah, maybe we start it with the IPFS stuff just to prove the sort of power of it. And then that would maybe sway the folks that are developing the CITs.

Nicholas: Extension as a Trojan horse and back seats, your extension can render, I don't know, like contract address slash token ID or something and display base 64 right in the browser.

Frolic: There you go.

Backseats: I love it.

Frolic: One one three is giving thumbs up.

Nicholas: That's very, very cool. So when people are writing floppy town pages, they'll be composing with a zipped or not zipped data, you imagine.

Frolic: Either I think one thing to note about like images and things is they already generally have a compression method built into the image itself. And PNG is actually interesting in that it has built into it. And one of the things that someone in the math castle's discord was playing with was a way to compress these JavaScript libraries inside of a PNG and read them back out without the need of a G unzip library. But that aside, the floppy town web pages will basically be. you'll write them as if you're writing HTML. And when you're specifying a remote image, there'll be some sort of syntax for this. You'll write an image tag that calls out to a particular image that lives in ETHFS. And that will. the front end will know how to split out all that HTML into a way that the contract can then compose all of the files and pull in the data from ETHFS and then spit out a HTML page fully on chain. that will be hopefully open C compatible.

Nicholas: Yeah. OK, so I'm working on something in this neighborhood. Also, I'm working for a juice box. on every juice box project is an NFT and none of them have metadata right now. So I'm writing a token URI resolver to create SVGs based on on chain data about the project itself. We should talk also about what's possible to display in OpenSea. But you said, I think at the start that it's going to be HTML inside SVG.

Frolic: Yes. Yeah. Another thing like a while back, Dom was poking at is that a couple of other people discovered. there's a particular tag in SVG that will let you render just plain HTML and the browser renders it quite nicely. So I can basically wrap an HTML page inside of an SVG and then open these. basically tricked into rendering that in like the the listing views and the collection views.

Nicholas: And the listing views in the collection views in the details view also. Are they just all of them?

Frolic: Yeah, all of the views. So in token URI metadata, you have an image URL field and an animation URL field. The image URL field is kind of what's used as a thumbnail or preview that's seen on the collection pages when you see lots of entities. But for a single NFT, if you're looking at the detail page or the listing page, you see the HTML if specified the animation URL field. And that lets you render if you want optionally render like 3D or whatever else and very interactive. by wrapping everything inside of SVG, all this HTML inside of an SVG, you can kind of get open C and maybe even wallets to render the actual HTML page inside the context of websites or tools.

Nicholas: Got it. So for the image key, you would wrap it in SVG.

Frolic: I guess the data that you're getting back out of the chain looks like an SVG, so they'll render it as if it were an image.

Nicholas: Right, but the browser in the token URI, when it returns, it's OK, it's basically four and then they decode it and then it's.

Frolic: Oh, I see. I see. Yes.

Nicholas: Animation URL you'll put straight HTML. Yes. Correct. SVG wrapped HTML.

Frolic: Correct. Although I'm not quite sure if that's exactly the route I'll go, because if you have the page being rendered effectively twice in the token URI that you might quickly hit limits. So I might just use the image tag or the image field. And then with the expectation that you have to like go out to a different page or the there'll be a URL that you can go to to visit the like fully on chain interactive web page.

Nicholas: That makes sense. That makes sense. I wonder if there's a way to probably not trick them into looking at the other field or something.

Backseats: Does it support CSS as well? Or are we I just want to make like a professor's web page from 1997.

Frolic: Oh, yeah. So my test bed web page was basically copy paste the Space Jam 1999 web page. Awesome. Yeah. And it totally works.

Nicholas: Yeah. Even I've been really impressed. I just like I think I started from a Figma file and then actually started with Inkscape, which is my favorite. And it just generated garbage SVG. So then I went to Figma and then ultimately basically hand wrote. But you can get so many cool things inside of an SVG, like the G filter ones. There's some stuff like I've got the Juicebox. NFT ones are going to be. they're supposed to look like those orange themed CLI interface, whatever, like no GUI computers like the orangey incandescent, whatever, CNT, whatever vibe. So they have this like outer glow effect and it's cool. You can do it on chain. It's like very little, little code to get that effect.

Frolic: Yeah, it's interesting. SVG has been around a really long time. And I think a lot of these powers have been around a really long time. And it's only with on chain products that they're really starting to shine because it's a very efficient way to store visual data that makes really complicated and rich visuals with just like very little code.

Nicholas: So let's say I wanted to pull an image into one of my SVGs. I would grab the file store address in my contract and then I just make some request and then concatenate in what that request returns to the contract I've instantiated.

Frolic: Yeah, basically, as long as it's wrapped in the appropriate tag, ETHFS storage is just the raw data. It doesn't store or rather doesn't give you back the metadata. So you need to know how to wrap whatever file it is. So if it's a image, then you want to wrap it in an image tag with like the appropriate data URI prefix. And it's only the base 64 encoded data that it will put back out.

Nicholas: Very cool. Very cool. So I can like. I have this, the aesthetic for my NFT is like all monospaced. Actually, it's an on chain font I'm going to be using from Peripheralist and it's Capsules project. So it's like a monospaced thing. So it helps me to do the alignment for the unknowable at compile time data. And but I could put like a sticker of Banny, the logo or whatever on top of it. And I could maybe store it with ETHFS would maybe be the most efficient way. And also very cool that I don't have to write it myself.

Frolic: Totally. Yep. You can definitely do that. I would recommend playing around, depending on the size of it, playing around with both PNGs and SVGs as far as the format you end up uploading.

Nicholas: Yeah, I suspect PNGs is less, right?

Frolic: Depends on the complexity of the SVG.

Nicholas: But yeah, it's like an illustration if it was just like a circle or something.

Frolic: Yeah. Yeah. I think illustration or something would make sense as a PNG, even a JPEG maybe.

Backseats: One thing that sort of strikes me is like where our projects could sort of come together. And I floated this idea to a couple of people before is like a lot of us and a lot of these conversations around like on chain art tend to veer into like, well, if OpenSea would just support this or sort of like, what are the limitations of like the main centralized marketplaces? And I feel like there's an opportunity here to like build a very like niche community, maybe even marketplace site for like not caring what. maybe it works on OpenSea. Maybe it doesn't. It probably should. But there's this other site that just supports all of this in its entirety.

Frolic: Much better. Yeah. Maybe that marketplace can live on chain as well.

Backseats: That's potentially.

Nicholas: Please.

Backseats: I mean, I could fit this into my extension as well, where it's just like it's just more friendly towards on chain art and it's not requiring this wrapped in this wrapped in that.

Frolic: Yeah, absolutely.

Backseats: I'm just thinking of the delta between the Stripe docs and what you've got on EFS right now. And like, how do we close that gap between between those two? We're like creating something that can live as long as a theory and is running is like a beautiful concept. And I love that. And but like the going from that idea to an actualized project feels miles and miles and miles right now. And how do we you know, what's the? what's the like the Heroku for this? What's the? how do we make that gap much, much smaller?

Frolic: Sure.

Nicholas: Yeah, it's interesting. If you wanted to make it like, I guess what's the appropriate level of abstraction? Create an FT button seems maybe too abstract. But I mean, you could be uploading permits to on chain and people could even be like lazy minting things that don't need to be minted and sitting somewhere. You could just upload the permit and a friend can download it and the buyer can pass it on chain. I guess you could let the NFT creator up store the file, but not mint the NFT until someone comes along and hits the mint button in the extension.

Backseats: Yeah, for sure. I'm more just thinking about the standards perspective. Like there's all of these people who are pushing the what you can do with on chain, whether it's audio or visual. But it's all sort of within the context of like, oh, well, what can open. so you really do for us? And I'm like, I don't care. I mean, we should care a little bit, but it's sort of like running a third party candidate, have this site gain enough or this community gain enough momentum that the centralized powers that we have to take note and just give them a read me. It's like when you're ready to support this, just do this thing. And it's ready to go for you.

Frolic: Yeah, I totally agree with that. One thing on my mind there is that I think the token metadata standard was developed with the idea that all of this data would live off chain and we're doing a bunch of somersaults to get anything fully on chain, a bunch of string manipulation stuff on chain, which solidity is not very good at. So if there were some better standards around a representation of metadata that's solidity native, that would help a lot in both gas and complexity of some of these projects and just getting going. And we can easily offer that in our contracts as an alternative means to get token metadata out of the contract, where we support both the open C standard and the sort of like fully on chain standard. And then maybe open C will eventually add support once we have got a few products showing that it can be done. And it's easy.

Backseats: I've had this side project in mind for a bit, but basically a VS code extension where you can just string interpolate what you want into your SVG, just like one massive string, and then either run a command or just it does it automatically on save. And it just turns that interpolated string into all of the string concats that you need so that you're not squinting, trying to see if like is that a double quote or a single quote to that? You know, I'm trying to figure out where you messed up the thing that's not rendering. that's, you know, 45 lines long.

Frolic: Yeah, I think I see that most often. A question asked in various like on chain discords is like I couldn't get this to render properly because I was doing all these different encoding things that have to add up to a final piece.

Nicholas: Yeah, it can be pretty brutal getting that correct. I know there's the winter has the hot reload SVG thing. I actually haven't used that. My friend Thomas helped me set something up where as you're working when you forge test, it generates the SVG to a file and opens it in Brave or whatever. But he's actually working on a very cool project, which I'm not sure I'm allowed to talk about yet. So I won't. But this is a problem people can use help with.

Backseats: Yeah, I think like the ergonomics of all of this, just there's so much opportunity here. And I think at this point, it's just like a passion project and a labor of love. But I think there's like there's enough people that can riff on this that like I love how chain SVG and it makes life so much easier. So like, how do you take that one step further? And I don't know, I'm just I'm trying to close the gap between like that and like Swift Playgrounds, which I know it's like a big, pretty big gap.

Nicholas: Totally. What I'm excited for is OpenSea. When you say that, like, create a new standard and maybe OpenSea would eventually adopt it. Do you imagine that being a new function or returning the same data in two different formats off token URI?

Backseats: Probably the latter. Yeah.

Nicholas: Yeah. OK, but it's not a problem like the limit of the gas limit, etc.

Frolic: Well, I guess unless the arguments were different from token URI, you probably couldn't return two different types of data. So that might be tricky. But I guess token URI maybe doesn't make as much sense if it's literally just token metadata you're serving. Right. So maybe it's a token metadata function.

Nicholas: And then like fully on chain front ends can just pay attention to that and ignore token URI. It's kind of like a geez, remember that era of everyone adding a letter to ERC721?

Backseats: You mean last year?

Nicholas: I don't remember it that well. It's been so long. It was a fortune ago. That's super dope. I really want to use this actually right away to try and put some images in my SVG. And actually, I need to try Hotchain SVG. Is that what it's called? Yeah.

Backseats: Yeah, it's super easy to set up. You basically fork it, yarn install, run your server.

Nicholas: I feel like a lot of my Forge projects are hanging together by a string in terms of libraries I'm importing and stuff. Maybe I should try Web3 Scaffold. That's the real answer. Bring in Hotchain SVG into Web3 Scaffold.

Frolic: I think one of my biggest pain points with Forge at the moment is dependencies. Get submodules and stuff.

Nicholas: Yeah, it's rough.

Frolic: Yeah.

Nicholas: Or like if you have a dependency and it has dependencies, but they don't use the same remappings you do. I've solved it and I don't remember how I solved it.

Frolic: Yep.

Backseats: That's the worst.

Frolic: Yep.

Nicholas: There's something you have to do like update submodules, update. I forget. Yeah, not the most fun. But it is a lot more fun than hard hat.

Frolic: Yeah, I love Foundry compared to hard hat.

Nicholas: All right, because the SVG thing I'm working on, everything has to be via IR. And it's so slow. It's not fast anymore. It's as slow as hard hat was.

Frolic: I haven't played it with that at all.

Nicholas: Oh, it's like if you does like a intermediate representation between your dot sol and the compiled bytecode and it takes a while to do that. Actually, you know what? Sorry, I'm not sure that that's accurate. It does take longer, but I think actually the problem is something to do with hard hat forking. But what's cool about via IR is that it lets you get more than 16 values or whatever the limit is, you know. You don't have to like wrap things in curly braces and stuff to try and get by the... What is the error that you stack too deep?

Frolic: I see.

Nicholas: So if you do dash dash via dash IR, I think that's it. You get... It goes through this intermediate representation before compiling or as it compiles and you can... It intelligently fixes things so that you don't have to deal with the stack errors.

Frolic: Got it.

Nicholas: I feel like all tutorials should have people main net forking all the time. I don't really see why you would not be main net forking all the time. Unless it's some very bespoke situation you're trying to set up. But even then you could be doing that with addresses that are pranked. And the main net forking sometimes is very, very slow. I need it for my project because I'm drawing on live chain data for populating the balance of the project and stuff like this in my SVG. And it's so many times people go to like redeploy the whole protocol they're trying to compose with in their local test net, which is just such a pain in the ass. There's no reason to do that. Especially for something like Juicebox where I'd have to like deploy the whole protocol and then deploy a project and then make donations to the project. It's just so much easier to main net fork and it's free. But it's slow. It's slow. It takes like 30 seconds to run a test on my contract.

Frolic: Yep. But then it's cashed after that, right?

Nicholas: Do you know how? I don't know how to make it cash. I asked in the support telegram and no one had an answer. I would think it would be. Or you could at least... I tried like there's a thing in Forge where you can specify the block you want to fork from. And I assumed that if I did that, maybe the subsequent time it would have to cash. But no, not in my experience.

Frolic: It's been a while since I used that. But I remember there being something around where like a more recent block is faster. And then it also like maybe caches between or the distance between the current block and the block you specified, the closer that is the last time it takes or something. Maybe there isn't caching. I'm not sure.

Nicholas: Interesting. I'm sure there must be or if not, there will be soon enough.

Frolic: But yeah.

Nicholas: Do you two run nodes at home or on the cloud? I do not. If you're okay sharing.

Backseats: I don't.

Nicholas: I've been looking at dApp nodes. I kind of want to build my own node just for, I don't know, have some pride or something.

Frolic: Yeah, definitely on my list.

Backseats: Yeah, it's one of those things that's always been somewhere on the list, but never high enough to pull off the top.

Nicholas: If it were still 2021, I might just buy a dApp node. But they're really expensive for what they are. You can definitely build your own much cheaper. But I had this thought like, do I actually want something running Intel management engine? I was going to buy my own NUC and put dApp node software on it. But I mean, I assume ARM has the same kind of backdoors. I haven't heard of them. So I have a little more trust in ARM. But it seems like the state of things, at least the simple spinning up your own node, things like dApp node don't yet, don't have a solid foothold in ARM. Although I think the lower level stuff is there if you're willing to go through the trouble.

Frolic: Everything you just said is wherever you put it.

Nicholas: Intel NUC is like a very small computer. And it's like $600 Intel computer. And you can buy them when you buy a dApp node. dApp node is like the easiest way to get your own node. As far as I know, this is not a paid advertisement. And they're like $2,000. And they come with like four GNO tokens. So you can stake Gnosis chain or whatever, which I'm not so interested in doing. But they have. surprisingly, I think the requirements are something like 32 gigabytes or 64 gigs of RAM and two terabytes. So I was looking a little bit into how big is Ethereum actually. And I didn't get to a totally complete answer. There's like, you need either a full node or an archive node to be able to stake. Clients won't do it. And the full nodes, I think, do a lot of checkpointing to reduce the size. But I don't know. I forget what the answer was that I found. It's many gigabytes. I think it's 12 terabytes if you have the archive node. But it's under 2 TB for, like, comfortably under that for just a regular full node.

Frolic: And you want this to do staking or for development purposes?

Nicholas: I think it would be cool to be talking to my own node for development purposes and for interacting with the mempool. Potentially, I'm curious actually what the speed of propagation is. If you use your own node. I don't know how that works. But I would actually like to stake at least with RocketEth or something. I think that would be pretty cool. I don't know if you've seen the, what's that site with all the, like, OFAC blocks?

Frolic: I haven't seen that.

Nicholas: Oh, I'm gonna have to find it for you. The, like, sensor thing? Yeah, it's like 80% of blocks are censored. It's crazy. It's even more maybe. I, it fluctuates. But I should find the detailed information. But my understanding is that Lido is going through a governance process where they're deciding if, how they're going to deal with OFAC compliance or not. And if it will be a blanket decision for all hardware operators on the node operators. I guess they don't even have to be hardware. But node operators or if there will give people the choice. Because many people, apparently the details of OFAC are that it applies to American citizens only. So if you're not an American citizen, there's no particular reason why you might want to be an OFAC compliant node. But, and I think RocketPool allows the node operator to decide versus StakeDeep seems to be going for a global decision as a DAO or something. But I'm going to find this website.

Frolic: Yeah, stakingmyeth is another maybe bucket list item at this point. It's way in the backlog.

Nicholas: Not towards the front.

Frolic: It should be, but it just keeps falling behind.

Nicholas: Mevwatch.info. That's the website. I admit to not being very knowledgeable about all this stuff, but they have simplified it such that you can see that 75% is OFAC compliant, which. Interesting to observe.

Frolic: Yeah, definitely.

Nicholas: And one other reason to do on-chain metadata for stuff. Actually, one thing we didn't talk about yet was the OpenSea royalty stuff. Have either of you paid significant attention to that? Have you read through the contract?

Backseats: I haven't, unfortunately.

Nicholas: Me neither. Okay, we got to do our due diligence as one of the 10,000 people who has a chance of understanding what the hell they're doing and figure it out. I'm very curious to know if they're doing it as a registry situation or it's hard locked to their decisions of which marketplaces are compliant. My understanding is that they're blocking, or their plan was to not honor the royalties for any contract that doesn't adopt their approach backwards as well. And I don't know if that's still the case. They would only honor royalties for projects that inherited their contract, their block list.

Frolic: Interesting. Yeah, I haven't been following along at all.

Backseats: Yeah, I don't know if there were too many royalty takes and I just sort of had to tune it out for a bit.

Nicholas: Yeah, they got us with the fatigue.

Backseats: Yeah, between the flippers who wanted zero, the marketplaces subsidized by VC funds who could support zero, the creators who wanted the... I just couldn't. I couldn't do it. I couldn't do that and the rest of my life.

Nicholas: Yeah, agreed. I dipped my toe in it early on trying to... I'm actually very curious. I need to better understand OpenSea's approach because I, a long time ago, was paying attention to this and suggested that one approach would be a block list of the type of like a Ublock Origin style subscription. Anybody can deploy their own list. Any NFT project need only inherit whatever, I don't know, a modifier, whatever. You figure out the way to essentially block any address being checked at any address, whatever, before token transfer, hook, whatever it is, to block any address. that's on the block list and then let the NFT contract holder subscribe to whichever list they want and manually override individual addresses on the block list. And then I think OpenSea has kind of done a different approach than that. They want you to inherit their block list from what I understand, but not give so much control to the... I think you should be able to dynamically, as the NFT contract holder, if you are going to be the USDC of NFTs and turn your NFTs into Blockbuster videotapes or iTunes 99 cent songs that don't actually belong to the people holding them, then you might actually want to override what choices the block list has made from time to time. But the answer I got back from some pseudo-swap stans was, because of counterfactual addresses, this actually doesn't work. And I didn't fully grasp it, but I think the idea is basically that you can use Create to know the address to which a contract will be deployed in advance and then send NFTs to that address or interact with that address prior to the actual deployment of the contract and then deploy the contract to that address subsequent when whatever action has taken place that you were seeking to happen and then have whatever functionality is associated with that contract that was predetermined take place. And that somehow, it makes block lists not viable because you could always deploy something, something, something. They also talk about wrapping the infinite regressive wrapping potential, but to me, this seems like to miss the point that you need to legitimize a wrapping contract and everyone would have to... If a wrapping contract was added to a block list, then those NFTs would no longer be able to be unwrapped. So I'm not sure where all this shakes out. I feel like CT hasn't totally dealt with these ideas.

Backseats: It seems like we're trying really, really, really hard. Well, certain people are trying really, really hard to not pay royalties, which is, in my mind, what has brought the space to where it is and the potential for artists and creators to make a living in the way that they couldn't before. I don't know.

Nicholas: But do you not think that they inevitably go... I mean, I like royalties. I wish royalties to stay, but it does seem like if block lists are the only way, then it's just DRM for NFTs. There must be... Or you think it's just like paradigm money propping up blur to have zero fees and if that were to go away, then the whole zero fee royalties would go away?

Backseats: Probably. Like artists can't run their lives giving everything away. Marketplaces can't run their business giving everything away. So it feels like we're just sort of... This is like Uber and Lyft subsidizing cheap rides to gain market share. And then when they went public and like gravity hit them, they had to change their business, which then changed everything about the mechanics of when they went public.

Nicholas: You got to go public before you reveal you need a business.

Backseats: Before you run.

Nicholas: Yeah. That's interesting. I guess I'm curious about this. Even if they did apply... To me, it seems like the argument is ultimately like people who are hardline on-chain logic maximalists say, well, you can't stop me from transferring the thing. So royalties are unenforceable. So royalties are going away. You're saying you're pinning it on blur being able to not have any fees. But I guess blur's position on that once they do launch fees will be something like, yeah, but we have lock-in. We have some kind of moat that the artists don't have on their NFTs. So even if they were to charge, I don't know, 1% or 0.5% or 2.5%, isn't there some gravity? nevertheless, just because the artists aren't in a position or I'm artists, whatever, NFT creators are not in a position unless they're using block lists to control the application of royalty fees. Does it not matter? Or will we, it feels like we'll inevitably end up in a place where those move towards zero as some marketplaces don't honor them, right? Regardless of what the marketplace charges as a fee. Probably.

Backseats: I think that's what you saw with sort of like art goblers on blur, just taking an insane amount of market share for like two or three days.

Nicholas: I felt like their 6.9% royalty was a meme for blur as an audience. Like nobody wants to pay 6.9% to a collection like that was my impression. I know maybe back in 21, we were paying 10% on some things, but for a collectible, I'm saying not for a one-on-one.

Backseats: I think my sort of uninformed take on this whole thing is like, we're just, if this weren't a bear market, we just wouldn't care. And we would keep doing what we were doing, but because we're sort of eating our young right now as an industry, as we're bored and yeah, waiting for the government money faucet to turn back on or whatever, that we're just like, we're fighting the wrong battles.

Nicholas: Yeah, I can see that.

Backseats: The idea of, I don't know, I feel like most people are poor royalties unless you're like a flipper and just trying to eke out that last tiny bit of ETH.

Nicholas: It definitely has the wrong incentives. Royalties have very nice incentives for keeping people associated with the projects that they put out into the world.

Backseats: Yeah. The whole promise of like, if you could basically get to sell out as fast as possible and then your royalties, your secondary potential income is unbounded. If you can create a, like, I don't buy the argument of like, well, it's always been done. Anytime you sort of fork in the like, this is the way it's always been done. Like royalties have always been zero. If you're selling a painting or whatever, you just sort of lose me because there's always the potential to create new stuff and new ways of doing something.

Nicholas: For sure. I guess my question is a couple of things. First of all, it is interesting that royalties get applied to the seller, but the seller sets a price. Like the Blur UI really sort of surprised me in the way that it has this auto, you say, I want to make eight ETH and then it will set the appropriate price for each marketplace based on its fees. So the Blur one in that configuration gets to be the cheapest one because they're not honoring royalties and not paying fees. Configure the other prices and something about that. I was like, uh, regardless of their fee, it feels like there's something, I felt some chill of inevitability about it when I experienced that. But it's interesting that OpenSea and company apply the royalties to the seller on the total price that they've listed it for rather than like more like VAT or something rather than like taxes as I'm familiar with sales taxes. I'm familiar with it where it's applied subsequent to the price. you see in the store.

Backseats: Yeah, I think people had the right take on this, which was like the person exiting the project is like, why are they penalized? You should have a surcharge for the person who's entering the project where it's like. psychologically they're excited. They're more probably apt to pay that tax essentially as opposed to the person who's like, I want to get out, I want to sell this. I want four ETH for it, right? Like marketplace fee fine. I don't know. It just makes sense that the buyer should incur those fees.

Nicholas: It could be. Yeah. It's interesting. Although at the same time you might say punish the flipper. They're the one who wants out. Screw them. Fair.

Backseats: I mean, look, I think any way you talk about this or argue about this, like there's enough sort of angles to this that someone's going to be mad. I don't know. I saw someone else's take that like, you know, eBay is still huge and they have, you know, insane percentages on their sales. And it's all about convenience. So how do we.

Nicholas: It's all about EE. It's all about like people's anticipation of being able to make money.

Backseats: Right.

Nicholas: I mean, for the, for the marketplace popularity, the marketplaces moat there, the excitement about certain collections. Obviously we have interest in these things. that exceeds the financial, but the financial is the thing that really gets people looking in the first place. There's lots of projects that are very interesting, but don't have any eyes on them. And it's because they have no, no speculative opportunity or no, no wink towards the market at all. So there's something like, like, yeah, I agree with you. People are willing to pay whatever fee open seed demands if they can sell their NFT their best. And if that goes away, then, then they stop to care. They stop liking the fees so much.

Backseats: So maybe it's like a volume based take, right? If the project has no, or like under a certain threshold, the royalties are zero, but over the same time, not the opposite way. Do they have that backwards?

Nicholas: Well, no, I just mean that, you know, I don't know, maybe some poor super rare artist needs to buy beans, but again, everyone's going to be mad depending on how you slice the pie. So the faceless corporations will end up doing it because they can take the heat because they have low paid community management people in their discords handling it. And don't spend any time on Twitter.

Backseats: I'm not touching that one.

Nicholas: Frolic, what do you think? You like royalties?

Frolic: I'm a fan of royalties, but I have shied away from the conversation around them. People will resolve it in some way and hopefully artists continue to benefit from their work being sold.

Nicholas: Yeah, totally. I remember hearing when I first got into the space in like late 2020, early 21 around after Beeple, after the 69, whatever, MetaKovan was doing Twitter spaces like every day of the week or something. And they told the story about the artists at like, I think the first NFT NYC or recent NFT, I don't remember what date it was, but they sort of banded together and like lobbied against, I think it was super rare who was going to lower the royalties. And they got the, I think it was 15% that they got everybody to agree to just by like being a NFT artists strike, like one of one artists, I think mostly back in the, I guess, Rarible era around then, maybe even before. There have been these kinds of things, but I guess the market was so much smaller that if X copy and Josie and whoever else tells you like you better listen. Whereas now I don't know if they, they pay as much attention to what individuals say.

Backseats: I think it just needs to be the right individuals or, you know, they're banding together.

Frolic: Yeah, artists union.

Nicholas: But we just don't have any leverage because we don't have anywhere to go. Like, I mean, maybe on chain marketplace or something, but.

Backseats: You can come to my extremely on chain alternate standard, all the fees, all the time open 24 hours marketplace.

Nicholas: 100% fees.

Backseats: 100% fees. Open my Chrome extension, pay me all your money, sell your whatever.

Nicholas: I think I've seen that extension before. Yeah.

Backseats: It's just called rugs.

Nicholas: Awesome. Backseats, Frolic. This is great. So happy to have you on and to talk about your projects. These are very cool. I'm excited to see the extension and also to hear its name. I don't know if Frolic, you have a suggestion for backseats in terms of a name for this thing.

Frolic: I don't.

Backseats: The hardest problem in computer science.

Frolic: Yeah, definitely. I always get stuck on it.

Backseats: True. Usually comes to me in the shower, like on a run. And then I domain's taken and then I got to figure it out again.

Nicholas: Awesome. Well, that end and ETHFS are also super cool. Thank you, everybody, for coming to hang out. And thank you, too, for coming to chat.

Backseats: Thanks for having me.

Frolic: Yeah, thanks.

Nicholas: Yeah, this was dope. All right. See you next Friday, everybody, for the next episode.

Backseats: Bye, everybody.

Nicholas: Bye.