Isaac: Hello everyone, hello to the Yaki Hon Box Show, episode two. So we have our guest today, Kevin from the Flamewerk, which is our candidate. He participated in the latest hackathon we organized. So we’ve seen the work he’s doing and the tools he’s using and the idea he had for this hackathon. So first of all, let me introduce YakiHonne, which is a nostr-based decentralized content media. which supports free creation and creation and publishing and reporting by various media. So I would like to welcome Kevin. How are you, Kevin?

Kevin: I’m good, I’m good. Happy to be on the show and give some more explanation about the project.

Isaac: Yeah, again, so you are welcome again. Because we’ve done some workshops before. You can guys check the workshops on the hackathon page. There is an angle for the latest record as we did before. So you can go and start exploring the Flamewerk, Kevin.

Kevin: Yeah, sure. So Flamework in general, to put it in a one-liner, is a NUXT3 starter template. So it means it comes with a bunch of modules, Node modules shipped with it that help you build progressive web apps. But it does that in a specific, clear, defined way. So language agnosticism is a big part of it. So I find it very important to be able to serve content in the language that the user is most capable of understanding. And then secondarily, it’s also that it should try to bridge a bit of a gap between what is a low-code environment and what most developers actually mostly do when they start a new project. So it’s a bit about trying to have a template ready that you can easily bootstrap from using pre-built components. And those pre-built components are then up for being highly refined, being language agnostic out of the box. So by just writing a little bit of markdown text and using a little bit of extensions within the markdown syntax, we can basically build entire Noster clients or entire applications. It could be an e-commerce site. All of those things are now easily accessible with some pre-built components and some pre-built integrations. So that’s the short version of it. But in general, it is just trying to put some rocket fuel within the web development or progressive web app development, just so you have something to start from and then progress or iterate based on previous designs. Because in general, if you look at most web apps, they mostly have a login section. In this case, with Noster, it’s a key pair that you can use. So in most cases, we’re actually building all of the same components over and over and over again. So that means that if we hone in a little bit on one specific spot, that we can really polish these components up to a very high standard, so that if people are new to the community, they can just select some of the functionality that they would like to implement. And then since it’s all basically in a component design, they can look within the component, the code itself, and then iterate on it or change some stuff or use a bit of a copy-paste paradigm for you to explore and then just use some pre-built functionality out of the box so that you can just easily start building what is specific about your project. Because most of us all need some type of registration process, if it is web 2.0 or web 3. But all those things basically take some time and effort and take away energy that you can put into really designing your meat of the application, let’s put it like that. So yeah, that’s the short explanation of Flamework.

Isaac: So if we want to summarize the whole talk, you are given everyone who wants to build up on Flamework, you have prepared everything that helps them to build some stores, some websites and some things up on Flamework. It’s like you’re giving them the plate and then they can choose whatever they want and build.

Kevin: Exactly. Which is a cool idea. The paradigm just extends into two templates. One of them is the production template which showcases almost 90% of all the functionality that you can expect or build or is pre-built within this template. And then you have a startup template which is basically the exact same production template but that just removes all of the stock images, all of the demo pages and stuff like that. So you have a clean starter to always build from but then you can easily just grab a markdown page that has that functionality built in with it and just put it in the pages directory and boom, you have the exact same functionality in your application. So it helps you really pick and choose which blocks you basically need to start with. And then since it supports just standard markdown format, you can just make some annotations or notes within the page and that can then also be translated or shown to the user as content. So sometimes, for example, when you say, oh I wish we should implement something like this. Well, you can easily then create a markdown page, write down what the idea is that you want to do there, look at maybe some pre-built functionality that you can already use to establish a path to solving that issue or solving that functionality that you want to expose. And then you basically already have a bit of a playground, a starting ground where you can explore that functionality or like build that functionality a little bit. Not siloed off but still within your application. And since it’s all statically served, this also means that once you just shove this to Cloudflare or Vexel or Google Cloud or whatever cloud, you can run this all on free tiering basically because at the end of it all, you just get handed a folder with static files. So the cost of running a client like this, if you run locally, it’s zero. And if you run it in the cloud, it’s also zero. So the other part of the flamewerk paradigm is also that as long as we can keep the cost at an absolute zero to host this as well and share your client or your build with other people, we have something that is accessible to everybody. And that’s usually something that’s a bit more difficult to find, I’d say. It’s only in the open source community, of course, that you can find things that meet that barrier. So I think that’s an important addition to the Flamework principle as well to keep that barrier to entry also at zero. So also trying to keep everything in the open source so that we can also collaborate a little bit better, of course.

Isaac: Yeah, this is amazing. So for example, let me format the question. So what kind of people do you expect so they can use Flamework easily? So what kind of level they should have, especially in the development? So for example, I want to build up on Flamework, so what should I have in basics so I can work easily with Flamework?

Kevin: Well, in general now it’s set up as a GitHub template. So if you go to the GitHub slash Flamework, you’ll see the production and startup one. And if there’s normally a button there that says use this as a template, and then it just basically clones the repository in your own GitHub account. From that point on, it’s bringing the code down to your machine, to have the GitHub desktop client or bring the repository down to your local machine. And then running Yarn or Yarn install and then Yarn dev. Or you can also use it with NPM. It’s also the same stuff. You can also just use NPM install and NPM run dev. I think that’s one. So from that point on, you basically have it in your local environment. That’s the only prerequisite. And the interesting part or why I’m investing a little bit of time at least into this is the NUX team is also building NUX Studio, which is a bit of a wizzywig, you know, like an editor like Dreamweaver, where it’s more like of a drag and drop functionality kind of thing. So normally once they go out of beta and I’ll be able to test it a bit, I’ll also be able to bring the Flamewerk repository over there. And then we’re basically into the low code, almost no code zone, where it’s a full wysiwyg drag and drop editor. So you don’t even have to interact that much with the repository. So that’s functionality that I’m hoping that the NUX team will at least release in the next coming weeks into a more open or like more months into more open state. But that will definitely bridge the gap towards the low code environment at least. For now, it’s still a little bit development heavy, where you still have to have a GitHub account and still know your way around an editor a little bit to get it set up in your local environment. But once we bridge the gap of having an editor like that out there, then it definitely feels like you’ll just be able to build a Nostra client just by dragging and dropping blocks from one place to another. So I’m very much looking forward to that piece. It’s something that I thought about building myself as well, like a drag and drop functionality whizzy wig editor on top of a template like this. But after having talked with the NUX development team, they’ve invested a lot of time and effort into building this platform out. So I’m happy I didn’t shoot myself in the foot by taking something aside, but like that.

Isaac: Yeah, true, true.

Kevin: Looking forward to it, but it definitely helped me clearly define where, well, my basic integration stops, where I’m like, okay, I’ll keep it as a repository for now. And then once the NUX labs finally figure out how to put it into an open state in NUX Studio, then yeah.

Isaac: So we will always encourage people to collaborate with Flamewerk. So they first need to try it and then request for any development, any new features needed. So I would like to encourage everyone watching the stream or any developer to engage and try, at least try Flamelog. You can find them on GitHub. We’re going to share the links later. So I just want to ask you, first of all, for the exact motivations that led you to build Flamewerk. Yeah, so like this also definitely helps to shape where this templating system came down from.

Kevin: Because it mostly started with NUX 2, like the previous version, where I attempted to do a similar idea of creating templates. In this case, it was then four specific templates, one for a website, one for an application, one for an e-commerce store, and one for something documentation-ish. And then while using those templates in production environments, I started noticing that they started blending. That, for example, or like it would be nice to start blending. Let’s say just in your documentation, you could basically put an e-commerce little section to do a call of action of saying like, hey, sign up for a subscription or something like that, or whatever it is that you’re trying to peddle. So these templates started morphing more and more into one and each other. And then last year in August, the NUX team started releasing the first release candidates for NUXT3. But those were beta candidates. So I jumped onto the wagon and literally said like, okay, I’m just gonna like morph all of these four templates into one so that you basically have one startup repository where it’s like if you want to put down a web store or a website, you basically have the functionality ready. If it is something where your customers are only in, let’s just say in a country where they only speak one language, well, that’s fine. If you need more language agnostic ness or you want to share your idea with more people in their local language, it’s built in. So no more hacky doing like, yeah, rebuilds of it later on. Same for like dark light mode. It’s also something where I feel like everybody just skips it at the beginning because it’s not really a mandatory feature. But if it’s already built in, like you don’t even have to think about it 99% of the time. It’s just there. So stuff like that is pretty important. And then those four templates basically to help you define what it is that you want to build in the framework template or in the folder, there’s basically a file called project.js, which is just a JSON object, which contains a lot of Boolean variables, but also just some strings and some variables that you can set. And the idea is there that you define what the project looks like. So it’s a bit like Docker or NixOS where you have a config file where you just define what the project scope would be. For example, for Noster, it’s basically you set your layout to the client and from that point on, you basically have a client layout that you can build in. But in general, it’s the idea of just finding a space where you can put all your config in. And then the last little chunk of it is just that since it’s just one JSON object, it also means that with AI assistant, it’s also very easy to get some assistance there. So I can just give it an example of a JSON format of a web store and I can just be like, okay, change this into a fish store or something like that. And then it will just change the SEO text and then the naming and all of that stuff. So having all those things in one file also definitely helps you easily spin off side projects or easily spin off copies of things. Yeah, it definitely helps because you are cutting time and effort for everyone. Like if they want to build something so fast, so they can count on you, count on framework because they’re just going to download the files and then re-modify a bit and then there you go. You have your own platform. So it’s like a cool motivation you had down there.

Isaac: So one more thing, because you’ve mentioned a lot, Nuxt3, because a lot of, maybe a lot of our viewers and our followers don’t know this work. Can you explain it a bit like in fast terms and what it does and what problem that solves?

Kevin: So in the JavaScript framework wars, let’s put it like that. You have Angular and you have React and Vue and Svelte and many other things as well. But in this case, I’ve noticed that most startups, if they build something out, it’s mostly a React based application. And then if you kind of already want to streamline how developers should work together, React is very open. It’s just a standard workflow. You can design your workflow however you want. So out of that community is basically Next.js that gets birthed, which is a bit more of a standardized development, which is like your pages.

isaac: It’s like a client-side rendering. Yeah, it’s like a client-side rendering.

Kevin: Exactly. So for Nuxt, it’s the same thing, but that comes from the Vue community. So if you basically would build a website, for example, using Vue or an application or something like that, you’ll notice that, oh, I need an SEO model. Oh, I need this. Oh, I need this. Oh, I would like it to be statically rendered. And all of a sudden, you’re basically pulling in a bunch of packages. And the Nuxt team is basically a group of people or like an organization that said, most of these, we’re going to start building it into Vue itself because most of the developers are going to ask for them mostly out of the box anyway. So it starts standardizing the development environment again. So for Nuxt.js, if you’re building something front-end related or a client in this case, you can use standard Vue components within Nuxt. So it’s just a superset, basically, I would say, of Vue. But it comes with so much magic out of the box. It’s a great development experience, I would say, especially now that the Nuxt team also is starting to get into decent releasing cycles. It was a year of a bit more silence, but now it’s definitely picking up steam again. So it’s great to see that there’s a lot of people who feel that there should be a need for something that isn’t tied to Facebook’s React to have something that is really birthed out of the open source community to that extent. I think that is still something that’s very important to the people who use Vue in general. And I definitely think that the people who then use Vue mostly end up using Nuxt at the end because it’s just…

Isaac: So it’s a driven path. Yeah. So for example, if we’re just gonna say that the tools you’ve used shortly, you can just name them the tools you’ve used on work.

Kevin: Yeah, the short end of the stack basically uses Nuxt and then Tailwind to do all of theCSS and all the design stuff on top of it. And then it all depends. That’s basically the only part of the stack that really counts. All of the other stuff is integrations. So for example, for Noster, it uses Noster tools for now, but it’s gonna switch to the Noster development kit or add it to the list at least. But there’s just… Yeah, Snipcart is being used, for example, for doing financial transactions since it’s mostly a very Jamstack-friendly oriented payment provider or processor. Apart from that, yeah, that’s mostly it. All of the other modules come out of the Nuxt community itself. So definitely wouldn’t want to discredit those things because without them, it would be a lot more making myself. But the Nuxt team also has modules for i18n. So that’s a language model or a language processor. And then the Nuxt content one, that’s also a very big one because that one allows you to bring that functionality of using markdown to build pages with or extending that functionality at least. That’s definitely one of the modules that I’m mostly hyped about and mostly happy to be using. Just to give a bit more idea of how that is implemented as a functionality or the markdown aspect of it. So you have your front matter, which is the top of your markdown page, which holds your title, your layout, and your description. And from that point on, you just usually use your standard markdown syntax too, like if you put a pound sign, space, you have an H1 title. But to bring then, for example, functionality into that page, you can do a colon and then block with all of these words capitalized. So block is just to call a piece of the functionality that’s been pre-built. Then nostr, create key, and then you have a bit of functionality that just pops up that allows you to have a small key generator that’s using then nostr tools, for example. So this is how easy it is to bring some of these pre-built blocks into your markdown pages. If you then experiment a little bit with the key generator, for example, and you’re like, this is nice, but I would still like it to look like this. Then you copy paste that block from the Flameworks folder into your components folder. And then the only thing that needs to change when you do a colon is you change the word block to component. And then basically you have a copy of that component ready there to be customized or ready to have extended functionality that you’re creating with it. Then if, let’s just say, we find a bug or we find a responsive bug, for example, within that component, at Flamework, we basically change the block, but your own component will then basically stay the same. So you can cut off some of the functionality or just copy paste some of the functionality into your own components folder and then be 100% sure that it stays static so that nothing changes at the background. But if we find some better components or some better architecture, then we can introduce new blocks to the system, basically. Or like in this case, they are frontend or design blocks. So you can grow your business or your idea from these new ideas or these new implementations as well. So you’re not really locked into two places. And that’s just a small development paradigm about it. If you use that to build your application, then you’re on a continuous path of having a good support of the newer content that we’re making, but also allows you to just play and experiment with your own components without them being somewhere in the blocks folder where they’re hidden or we might overwrite them in the future. So that’s the only part of the paradigm that you need to understand to have some type of continuous integration path if we release new things.

Isaac: So you should keep updating every time. It’s keeping the flow up to date.

Kevin: Exactly. If you use the GitHub thing where you select use as a template, you’ll be able to just sync with the fork that you used the template from. So as long as your own components stay within the components folder, there’s no merge conflicts and you basically just have a little bit of a free path into using new functionality and new extensions, which is an interesting way to try to grow fast. Because I feel like the Noster community is something where you can make some blocks today and in two weeks they’ll be like, oh, that’s very outdated. So you have to keep up track super

Isaac: fast. Because the Nostr community is growing so fast and they’re making breakthroughs every day. So you should keep up the flow and go fast.

Kevin: It’s difficult to keep up. For example, just before the podcast, I saw that Pablo released something where it’s a one-time use token so that you don’t even need to use keys. You’re still using keys, but it’s a less friction path of a login system or stuff like that. Like the login implementation that I had two weeks ago, I was like, okay, I think this is way better. So at some point I also have to implement these defaults and stuff. So keeping track once in a while.

Isaac: Yeah. And this is why we encourage collaboration. So it makes the effort in one place and many people working in one thing. So it’s going to grow fast. So this is why we, as yakihonne, encourage people to collaborate with Framework if you’re interested in this awesome project. And if you see it beneficial for your work. So I just want to ask you if you have any ideas for future projects or just out of curiosity.

Kevin: Yeah. Well, there’s a small implementation list that still needs to be added. And definitely after the hackathon, I went pretty fast in some places. So some of the folders definitely need some cleanup before it’s pretty presentable. But most of it is just some more integration, like Albi and NUXT3 support for loading keys. I’m also looking into a little bit of a custodial idea where as much as I hate it, I would also like to support the idea of people being able to sign up with email address and password to some extent to have a bit of less friction of people who are so used to it or who are, I don’t know, I won’t say shouldn’t be trusted to hold their own key, but it’s just like, it’s just less friction path for them. And then, yeah, I’m still working on one or two more clients that I’m also interested in following up, but it’s a bit of a slower start. And then the last thing that I’m definitely working on is I’m working to do some sort of meetup in Amsterdam, but I haven’t set a date yet or any big plans because so far it just seems like the white paper or the idea behind it is that I would like to do the entire conference thing running off of Noster. So that will be a little bit more challenging, but there’s already some solutions being in the works. So I’m also trying to see and not piggyback, but see a little bit of what they’re implementing.

Isaac: Keep us updated on the meetup. We might join you, especially in one of the few first experiences for Yakehon because we did some meetups in Hong Kong and we did some meetups in Miami, the one you presented your project in. So we will be really happy and appreciate the invitation if that happens and you organize a meetup.

Kevin: Definitely, definitely. It’s just the restriction now is a little bit in, well, there’s Noster Asia in November and organizing a meetup takes a decent amount of time and if we want to run it off of Noster, it will also require some dev time at least. And then the idea is mostly that it’s nice to do it still this year, but I do think it’s easier to do next year when it’s a little bit more like summery weather because Amsterdam is a lot nicer, I would say, during summertime or springtime. So it’s also trying to plan that a little bit together with the city. So it might be a little bit of a long-term play still, but it’s definitely something that’s in the works. It seems like a good place to try to bring everybody together because it’s pretty central and flights are pretty easy to get through Amsterdam in general. So it seems like it could be a good place to do a meetup, to bring people from Europe a little bit together and see what this community looks like on this side of the aisle. Yeah, I meet a lot of cool people around, but we’re all a bit spread out as well because Europe is a bit fractured, but I think it would be nice to at least do some type of meetup every year somewhere in Europe.

Isaac: Yeah, and also from our part as the Yakihonne community, we are thinking on doing some meetups in Europe in the upcoming days. So if that happens, you will be welcome to join us also, so we haven’t set up the place and the date, but I’m thinking that it’s close enough. So if that happens, I would welcome everyone who lives in Europe or around the world that has the possibility to travel and come to the meetup. So everyone is welcome and we’re all encouraged. So the projects and the builders, the creation, the creator, everyone, we are just welcome at yakihonne. So any last words, Kevin, for the nostr community? Any advice?

Kevin: I don’t know. The only thing that I think now with doing the client development and stuff like that is you start where you mostly have to start, right? Which is loading in keys and playing around with logins and making mechanisms around those things. Yeah, at least start with the basics and then everything will come after. Yeah, but it’s also, I think, important to really try to tackle that problem very early on, like try to make it less friction for new users who show up, because I think there’s still a bit of a, not a dumpster fire on the other social media websites, but it feels like people are still once in a while having enough of it and then being like, okay, what’s the alternative? And then they start looking around and then they maybe find nostr or they maybe find Mastodon or something like that. And then if they play around with it and you can’t capture them or it’s too much friction for them to start, then it will be difficult to really bring that type of scale. But it’s also, I think, something that’s not new into the community. So it’s definitely a lot of things that are being worked on. But I’m also looking forward to seeing those things implemented in most clients as well. So that if people have their first experience using some type of nostr client to do something with, it should be something that really sticks to their experience. So that they understand that they can just move from client to client, that it’s not blocked in. All those value propositions that nostr has, it kind of has to show into the first experience that people have once they use a client. Now it’s very development oriented where most of us, I feel like, are developers or do something in that space to some extent. But we shouldn’t forget about the normies once in a while, I think. Yeah, true. That’s the mass of the people. So if we really want to bring this out at scale at some point, we definitely have to think about them as well. Because it sometimes is a bit confusing, I would still say. Or there’s a lot of things to learn and integrate and not only vocabulary and things like that. But it’s just… I don’t think I can convince my mom yet of using nostr or something like that. So it’s like, I think at some point we need to get there where we have to be able to just say like, you should make a key pair somewhere.

Isaac: Yeah, yeah. So everyone should do his part and then we will see where it’s going. That’s funny. It’s going to lead us, yeah. So, Kevin, thank you for the amazing talk. And I really appreciate your presence here and sharing some knowledge and your experience on building the framework and building any clients. Because if you can build something like a framework, you can build anything. Am I right, Kevin?

Kevin: I hope so. I hope so. At some point, it feels like if you’re a little bit comfortable using a little bit of markdown syntax, you should be able to build a lot of things yourself. And that might encourage some curiosity that might awaken some flames into the idea of coding a bit yourself or just understanding what’s running under the hood and presenting that in a bit of an environment as well, where you don’t feel like if you change something that you might break the entire application or something like that. I’m hoping to see some more people build some more awesome projects. And I’m also looking forward to seeing if we can find some more contributors to enrich these blocks or like some of the functionality of it, so that other people can also experience the same fun and functionality in their applications.

Isaac: Yeah, true. So I would like to welcome everyone to try out the yakihonne platform for the nostr-based decentralized community media protocol. And also, I would like to welcome everyone to reach out to Kevin if there are any questions about his projects or his ideas he’s shared or something about the development he used. He would be like, I assume he would be happy to help you guys, especially on building some small, yeah, especially on building some kind of things. And also as an information for everyone, so the results for the hackathon will be announced today, later in the day. So I would like to welcome everyone to check out the website for the hackathon. And when we publish it, we’re going to publish it on our social media, our Twitter, our Damus profile, and etc. So this is the end of the honne box show episode two. I would like to thank Kevin for his time, for his efforts, and for the work he’s done to the nostr community. And for his time, like showing us some cool tricks and how he built, and his experience, his motivations. I hope you guys found this information useful, and I hope you have a nice day. So thank you, Kevin, for the time and for being here. Thanks to everyone who’s watching this podcast, and I see you in another. Thank you.