Daniel Roe:
This is something that I would want to use not as a showcase, as sort of how can use for a framework, but this is something actually that might be part of my daily life if I'm using Mastodon.

Noel:
Hello, welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket combines session replay, error tracking and product analytics to help software teams find and solve issues and improve conversion and adoption. You can get a free trial at logrocket.com. My name is Noel and today we are welcoming back Daniel Roe. How's it going Daniel?

Daniel Roe:
Hey, it's a pleasure to be here.

Noel:
Awesome, awesome. Yeah, we had Daniel on a few months ago at this point, but anyway, Daniel as a member of the Nuxt Core team, he's been working on Elk, which is what we're going to focus on talking about today. Before we do too much, can you give us a brief synopsis overview of who you are and what you're working on?

Daniel Roe:
So my name is Daniel. I live in the UK so I live in the northeast in the countryside, like a wood on the other side of the house. So it feels a little bit idyllic it's a lovely place to be. And then yes, I'm an open source maintainer. I'm sponsored, which is incredible. So I basically get to contribute to open source full-time and that's pretty cool.

Noel:
Yeah, that's the dream, right? What have you been focused on specifically since we had you on last?

Daniel Roe:
Well, one of the things obviously that is on my mind is Elk. Elk is a client for a social network called Mastodon. Mastodon is a little bit like Twitter in some ways, so it lets you post small updates with images, a text and you can follow other people and you can see their updates as well. You get notifications, there are direct messages. So there are a lot of things that might be familiar to you if you're coming from Twitter, as I certainly was Mastodon's a bit different at the same time. So it's decentralized. So it's like email in a sense. It's not that there's one single server like Twitter, everybody's tweets are on Twitter, but with Mastodon people can have different servers. It doesn't change how you follow people.
Just like email, you can email anybody no matter what server they're on and you can in Mastodon follow people no matter what server they're on, but the server you're on does give you some great quality of life things like and moderation support and a community of people as well. But yeah, so Mastodon is a decentralized Twitter and obviously a lot of people over the last year have been making their way to Mastodon. I think in many cases people are doing it, they've either ditched Twitter entirely because either as a statement about what Elon Musk is doing now or they've decided that it would be probably for the best to have a backup plan and to connect with people they care about somewhere that is not going to be switched off accidentally one night because the server didn't look that important.
So I think there's been a huge, huge influx and interest in Mastodon over the last year, I think probably particularly since September, October last year. But I mean it's a steady stream of exiles from the Twitterverse making their way across to Mastodon and Elk is a client for that. So the defaults Mastodon experience Mastodon is a Rails app. It ships with a web UI, which is maybe a little bit unfamiliar or foreign to people and for a while Mastodon project has wanted to invest time in improving that. But yes, Elk is a different UI, it's a different client for it.

Noel:
I think it is kind of worth mentioning a lot of these more federated platforms like this new era. I don't want to use terms like web 3 because everyone's got all these knee-jerk cryptocurrency reactions and stuff like that to these new, kind of, federated things that are not necessarily tied to the web. But I feel like they often go hand in hand with big open source projects. Cause the same mantra is driving a lot of the people that are motivated into these spaces. So it's cool to see these big, I don't know, these projects come out where it's like we're firing across the whole board here like we have backends that open federated, anyone can participate in the network and the cool UIs that are all fully open sourced versus the opposite end of the world where Twitter controls everything and shuts down third party clients as rapidly as they can.

Daniel Roe:
Is very much the case that you do see this sort of overlap with similarity with open source and the sort of open web. It's not in the control of a single company and it's hackable. So a lot of people like the idea of being able to tinker. Well, something like Mastodon is great for tinkering. You can actually see the source code, see what's working, you can try and fix it, you can make a PR and then it's fixed for everybody else as well. So that appeals to the bit inside of me that loves the open source core. The idea that this is, anybody can look and make it better.

Noel:
It's almost kind of a requirement for these federated services of this nature. They need to be tinkerable and extendable and people need able to go in and get their hands wet I think, or their feet wet rather, to see how things work. And I, there's a whole philosophical tangent, we could go down here about why these things are, but there's also kind of a pragmatic nicety to these services too and that we're recording it's the sixth today and Twitter had their hour long outage this morning where there was, I think the latest was that it was like the URL shortener tokens were out. The internal service that was doing the URL shortening was failing for their own resolvers when you just hit twitter.com.

Daniel Roe:
That was a particularly embarrassing one actually. All the images posted at a certain point in time stopped working and then yes, clicking links in tweets led you to a JSON response that just said something like the API plan has not been authorized. A particularly embarrassing, embarrassing, but I guess all of these little signs of things not quite working. It's not that any one bug is with Twitter, it's not that any one bug is a sign of anything. We've all faced bugs. But I think it feels like this is an inevitable consequence of some of the decisions that have been made. A sort of disregard maybe for the work the engineering team have done over the years, that kind of thing, I think. So something like this happens and there are chorus of people saying on the one hand, well Elon's unplugged server and people on the other hand saying, well if you don't move fast and break things, you won't make anything better.
And I think surely there is some kind of room in the middle to say the way things have gone at Twitter has been callous, very cruel at times to people and probably also extremely foolish in terms of business decisions starting with a purchase software. But I'm not particularly aiming at making any kind of big points like that about Twitter. I think the reason why you might enjoy Mastodon is at the same reason you might enjoy Twitter. It's mostly about the people and the people you get a chance to talk to and engage with.
For me, a big part of that is discovering new things I wouldn't know otherwise. So hearing what people are working on, seeing what they're doing and a lot of people are on Mastodon now and so if you want to talk to them and hear from them, learn from them, then Mastodon is a good place to be. I'll be Mastodon, I'll also be on Twitter and I think probably a lot of people will be the same because now Mastodon has enough of a gravity of its own that it's someplace you need to be if you want to be listening to those people too.

Noel:
Yeah, I feel like there was an inflection point of some kind where it was like you started seeing people link to their Mastodons in a way that I had seen it before, but it was kind of like tech people or people who were adjacent to the space already they'd have them but it was kind of like they were trying to get a thing going versus just in the wild it's like oh their Mastodon is their first social link was just a cool moment I think that we kind of collectively had there. So tell me more about Elk. What kind of motivated you guys to build a client? What did that entail and how's the journey been?

Daniel Roe:
So the motivation, it was interesting. So Anthony, who's also on the Nux Core team DM'd the group message saying Hey, I think it'd be a good idea to build a client for the Mastodon in Knux and got some good thumbs up thing, everything was going Mastodon. So there was this sort of big push, oh no, what's happening with Twitter? Look at Mastodon again, like many people, I already had an account but it wasn't where I was active. So a couple of days later Anthony sent me an invite to the repository, which was [inaudible 00:08:48] slash Nuxtadon. So naturally that was great. Great name obviously. So I joined and there were a couple of things there. And then over the next few days particularly I think Mattias Kapaletta from the Veco team was particularly active and I was seeing all kinds of stuff happening and Anthony was throwing things up there and actually I think Kevin probably, anyway, the four of us started doing much more in terms of building things out and I think I was probably doing the least of all of the four.
But we basically started building up this client and at some point we even thought, hey, we shouldn't call it Nuxtadon. It's not a showcase for Nuxt. Which I think is how we originally thought about it. Anthony was thinking hey, every framework could have their own and just show how it works. But at some point we thought, no, this is an app in its own right. This is something that I would want to use not as a showcase it sort of hack and use for a framework, but this is something actually that might be part of my daily life if I'm using Mastodon. And so we picked the name of an animal that was around at the same time as Mastodon, Elk, although Elk survived. Elks still live in the world today, Mastodons does not.

Noel:
It's good. It rolls off the tongue. It's nice. Easy to remember. It's great.

Daniel Roe:
So yeah, and basically we kept it private and we basically said, if you want to help let us know and we'll send you an invite. And people, goodness people let us know. As in we got hundreds and hundreds of people and Mathias was giving access one by one. I mean I guess we all were. But giving access to people one by one saying here's the private Discord link, here's the get GitHub.org and Git, GitHub were fantastic. They'd let us do that as a private, cause we weren't paged, but they unlocked some features. They were amazing. And so we brought people in and people were contributing and it's amazing it worked as well as it did. We had, before we even went public, we had over 130 contributors and that's not people with access, that's people who touched the code base. That's incredible.
And basically I think it sort of captured all of our imaginations. Here is the social media client that we want to have and just out of the gate it was already beautiful, it was clean, elegant, it was understandable. If you weren't used to Mastodon, that was okay because it made sense using UI primitives that people might understand, not unique to Twitter, but across a lot of the web icons and UI elements that just seemed to work. And with a plus that actually anything about it could be improved and was, you could talk about it, we could have a little discussion, you could submit a PR and it would be done. And actually I should say Mathias, who is employed by StackBlitz to work on open source, but he also pulled a few strings for us and we got access to something called CodeFlow from StackBlitz, which basically meant we could give one click access to people making PRs.
So people could come to the repo, click a link and would fire up the repository in their browser, create a PR for them, open the app, and then they could make changes and they would be sort of immediately updated in the browser for them in the app. Then they could just commit them and make the PR all without having to clone anything locally. So that was a very, very nice feature and people started getting involved, people who had no experience with Nuxt, no experience with Vite, some people didn't have any experience with Vue and they were getting in and making changes and improving it, which was really, that's open source collaboration at its best I think.

Noel:
Just a quick pause here to remind you that PodRocket is brought to by LogRocket. LogRocket can help you understand exactly how users are experiencing your digital product with session replay, error tracking, product analytics, frustration indicators, performance monitoring, UX analytics, and more. Machine learning algorithms service the most impactful issues affecting your users so you can spend your time building a better product rather than hunting through tools. Solve user reported issues, find issues faster and improve conversion and adoption with LogRocket. I feel like kind of that breaking down those barriers to entry on open source projects. So it's one of those things where as the core team people that have been in the ecosystem and maintaining projects for a while, I think it's easy to forget just how intimidating and arduous even sometimes it is to get into a new tool set, one's not familiar with at all. Just little things that can trip you up. So I feel like these tools and products that are helping break those barriers to entry down are super cool to hear about.

Daniel Roe:
And a lot of the contributors that we were having at this point were people in the ecosystem as well. So people completely knew, but also people who were building libraries in the Vue, Vite, Nuxt ecosystems. So for example, the author of a plugin called Vite Plugin Inspect got involved and added a PR and suddenly you could, in your browser, click on any part of the app and it would open a component in your IDE that was responsible for that part of the app, which is again amazing if you're a new contributor. Actually you don't have to understand how the code base is even structured in order to figure out how to make a change that's going to affect something locally and others too. So the offer of Vite Plugin PWA got involved, built a PWA plugin for Nuxt, module for Nuxt. Our core contributor to Tauri, which basically creates native apps that wrap web applications but with more native features and it's totally tiny and built in Rust, which obviously is enough goodness to get you excited I hope.
But he got involved as well and suddenly we had a native port of Elk going on. The author of the Nuxt internationalization module got involved and we started seeing bug fixes and performance fixes coming on from there as well. And so many more [inaudible] from the Vue core team, again with a couple of libraries of its own. Like really, it was so exciting to see these things happening and both like the advance in ELK but also the advance in the ecosystem. So things that were being fixed or implemented or features added because there was this feeling of we're all moving forward and we need these features, it's for a real app and we're building them. That I think is how development goes really well in open source often. And when you have the sort of sense of these things are being used, this is for a purpose.

Noel:
It helps when you have users clamoring for things, it's a well of motivation and energy sometimes it feels like right? Like people are asking for this demanding, it's like okay, it's easier for me to put an extra hour at the end of the day to get something knocked out if I know there's like 200 people that are watching some comment request for change issue report, whatever it is that are eager to see something implemented or resolved or whatever it may be. I guess why is Nuxt a good fit for a Mastodon client? Why as a framework does one need more than just Vue?

Daniel Roe:
So I should say probably you can create a Mastodon client in pretty much anything that you want to do to build it then. But I mean I do think next obviously has some good things under the hood going for it. So part of it is the speed of development. So there are a lot of conventions that are in place that just dictate how the sort of best easy course is to build. So you've got things like auto import or compostables that you can use throughout your app, components structure, you create your components in a components folder and again those get auto imported wherever you use them. And the sort of name of the component is based on the name, the path of the directory and then the file name. So again, you have very sort of normal patterns for figuring out okay where is this component coming from.
And that also means that when you're actually looking at the business logic of your code, it's not 20 import statements, it's actually just the logic in the component. Everything else is clickable and fully typed so you don't lose anything, but it's much clearer and cleaner as to what you're working with. For this. We also needed a server component because we're an OF app and we need to get an OF secret and authenticate, like generate callback URLs and although we don't store any of that data ourselves, it's all in the user's browser. We still need to be an OF client or every single user authenticating with a server would create a separate OF app and that would be a nightmare for the server admins. Yeah, so obviously Nuxt has Nitro built in and we were able to handle all of that there and which also meant we're able to handle, again built into Nitro is the ability for us to use a provider agnostic storage solution, KV storage.
So we can store all of those keys and values for OF Secrets and other metadata in a way which actually works wherever you deploy it. So we deployed to Netlify and we currently use CloudFlare KV storage to handle that data, but somebody else can come along and deploy Elk somewhere else entirely. They could double it to Vessel, they could use something else, they could divert to node server dock file and use the file system. And none of that requires code changes to Elk because it's all provider agnostic with Nuxt.
I guess that's another point as well. So we use serverless functions and again, we don't have to configure or set that up and it just works differently with Vessel or Netlify or card flow or Daco, whatever you do. Creating integrations like the PWA module. We built I think 10 different modules we use more than that. And so adding features is really nice workflow. You build the module, you abstract it, you publish it as an MPM package and you can build local modules in your project as you go, which we've done. So it's basically is meant we can look right really, really quickly as we go.

Noel:
I'm curious on that, the serverless, I guess really whatever the backend, the server component may be. You said you guys are using Cloudflare's key value for all the cool niceties that it brings you, but if one is deploying it somewhere else or wants to deploy it on some platform that hasn't been considered yet, how do those abstractions look? If I wanted to go clone the repo and deploy on some kind of weird bespoke serverless in some serverless hosting environment, how do I do that?

Daniel Roe:
Well all of these features are Nitro powered, that serverless, anything server related will be Nitro powered. And Nitro is fully extensible. So it comes with presets, presets like Vessel and CloudFlare pages or whatever. But all those presets are just collections of options. So you can create your own collection of options, you can even package it up as your own preset and use it. So often a preset will come with an entry, which is a runtime code which uses the underlying primitives nitro gives it to create an interface for the provider. So on CloudFlare for example, it's a very, very different shape from a node base, but both the CloudFlare entry point and the node entry point use the same underlying nurture primitives to handle the request and return on response. And note that's all powered by the H3 framework which we built for Nitro for Nuxt.
And so it wouldn't be that difficult. So just the other day on a stream, probably in less than an hour built a new preset, Nitro preset for Legon, which is a new runtime open source runtime built on Rust, which is really cool. We deployed it and immediately started getting less than 40 millisecond round trips for server rounded Nuxt app, which is very, very, very nice. And they actually just announced a new website recently so it would be very easy I think if you wanted to deploy somewhere else for you to do that. And the same is true with a different storage provider if you wanted to do that too. Again, storage ships with presets, you can write your own. We did that for elk even. We built a couple of presets to handle situations that weren't covered by hand storage natively and then made POS back to add them back into hand storage.

Noel:
Are there many other big Elk deploy? I don't know, deployments feels like a weird word, but I feel like that's fine. Like Elk deployments that you know of or is it mainly the one you guys are maintaining?

Daniel Roe:
No, there's some pretty big ones actually and it was amazing to see some of the ones. So there are eight that we have listed in our readme of big deploys and seven of those are actually particular Mastodon instances, which I think the very first one was Universodon, where I could be wrong about that. But yes, so that's available to their users. Some of them actually it's sort of prioritizes their users so when you sign in you only sign into that server, others of them are more like Elk and you can sign into any server no matter where it's being hosted. But yeah, we have a pretty vibrant ecosystem and people also hosting their own too. So I couldn't say how many users of Elk there are. All we know about are the ones on Elk, Elk.zone, which is the sort of instance we administer.

Noel:
Yeah, I think maybe it's worth kind of elaborating a little bit here for people that aren't familiar with Mastodon. So like we were saying before, Mastodon's federated. So most Mastodon users aren't running their own Mastodon instance. They are members of them, just like most people aren't running their own email server. They've like signed up for some other email provider that's managing it for the Mastodons kind of the same thing. But with Elk you can point the Elk client at, I guess again depending on the version, but the hosted official version we were just talking about, you could point that at any or most providers I would imagine would be playing nicely.

Daniel Roe:
Exactly. And a lot nicer experience than setting up a custom email provider. To be honest, custom email provider, you have to figure out how it connects, what's the protocol, what's the port. And with Mastodon it is just you type in your server and it redirects you there and you click authorize and then it redirects you back and you logged in. So it's a very seamless OF flow. But yeah, you just type in your instance, your server and we've tried to make some quality of life improvements there as well because it can feel that even that is a little bit weird. So if you start typing something, a known server will autofill it for you.

Noel:
Oh cool. So what do you think's motivating these other big deployments, especially those that are tied to a specific Mastodon instance, they just kind of want that to be the defacto UX for their users and they feel like that's the best way to get it to them or what do you think is the motivation for these people?

Daniel Roe:
I think it's be because they like it. So this is a very...

Noel:
It's a good answer. Yeah.

Daniel Roe:
I think basically the admins of these instances are, this isn't a moneymaking enterprise for most people. They're doing this because they value Mastodon, they value the community and they do their best for their users. And again, it can be expensive to run a server with the federated approach to Mastodon each server has its own copy of everything that it knows about. So if you post an image to Mastodon, then that image will get stored in every single server that federates with you, which knows anything about your post. Same is true with metadata. So if you crawl a web link to something, there'll be little preview image and again every single server that knows about that post is screen to download that preview image.
And then there's all the jobs to make sure that those images are up to date. And there's a lot that sort of ends up having to do, and there's a lot that a sort admin ends up having to do. The worst bits of course are to do with people are probably moderating content that shouldn't be out there, but yeah, these server admins, they do it because they love the people, they love the community and I think that's why also they make Elk available because it's something maybe they've enjoyed or appreciated or they think that it would benefit or be nice for people who are using their servers. And honestly that's been lovely to see as well. See people pick it up and use it because they like it.

Noel:
Is there any, maybe, liberties with the Mastodon data model or the abstractions, I guess the API of Mastodon that Elk takes specifically or is it all pretty standard for this is how a Mastodon client typically functions?

Daniel Roe:
So yes, there is this API that exists out there and we've been using a great API layer again created in JavaScript. It's called Masto.js, which is great. So basically that abstracts the interface with Mastodon. So any Mastodon server should work fine. There are different versions out there in the wild, so you might have an older one or a newer one and that will affect maybe exactly what features might be fully supported. But that's probably true anyway whether they're not using Elk and it's even true that there are other Mastodon like or Mastodon like servers or Mastodon forks out there.
So the things like Miskey and CalcKey and lots of other things that sort of expose a Mastodon API, and so we can often work with those two and people who want to use those will create issues and try and make it work, which is great. So Elk works for a lot more than just Mastodon. That's all happening at the API level. So often people might know that Mastodon is based on ActivityPub, which is a protocol for publishing and subscribing to content from individuals or from different sources basically. And Elk doesn't really operate at that level, it just consumes the APIs that the server exposes. The server being the thing that under the hood will use ActivityPub to federate content.

Noel:
Cool. So when you guys are, or when you were setting out or even now, what are the other players in this space that you kind of look to and are collaborating with and gleaning from?

Daniel Roe:
So one of the great early players, it was [inaudible] was I think fairly recently stated that they would not be maintained, which was sad to see, but [inaudible] would definitely be one. There are some others of course as well coming out at the same time because lots of people had similar ideas. So there are lots that are not open sourced. So you can download apps on your phone. So there's Mammoth and Ivory and goodness, there's just so many different apps out there. I mean we have a PWA that is installable on your phone as well. So some people will use that, some people will use one of those mobile apps, something else. But we're trying to explore questions, how do you display a thread on Mastodon. What should it look like? Because by default on Mastodon, you see there is no algorithm, there's nothing that curates your feed for you, which is a plus and a minus as well.
On Twitter, a big negative is that often you don't see posts from people you care about and instead you see some ad or some posts that you've seen, some tweet you've seen 20 times and for some reason it's showing to you again. So you have that frustration. But also there's a lot of care in terms of, okay, this new post, the tweet is out there, but let's show some context. These are some older tweets that are not recent, but they'll help you understand this new one. So there's a lot of curation going on, but the Mastodon API doesn't do that.
It just shows a chronological, here are the most recent updates from your network, but there are things we can do to make that better. So for example, if you're scrolling down, you probably don't want to see latest update in a thread, then the one before that, then the one before that, then the one before that because if reverse chronological order doesn't make sense for you to read a thread that way, but it might make sense for you to see other things that way if something's generally more recent, you do want to see that.
So we've done a number of things like rethinking threading and figuring out how to reorder threads so it makes sense in notifications rather than everything just coming through as a separate line. Can we batch and group them and actually make it easier to, if you just had 20 people follow you because you, I don't know, have joined Mastodon and maybe you do want to have a little pictures of people who have followed you rather than just see or if people, those of you who like your post, maybe it makes sense to group those rather than show them one by one. So again, trying to figure out some of those and different clients, different apps take different solutions to that. So we do all seek inspiration from each other on the best way doing that.

Noel:
Nice. Awesome. Yeah, I'm glad you got into that a little bit. That's kind of what I was trying to suss out with my, what the API layer question, what do you guys have to implement versus what is part of the spec? Just cause I haven't gone under the hood to that degree. So yeah, it's cool to hear cause it's interesting at least to hear some of those kind of more UX, not just making it look pretty, but actually how does this function, the functionality of the UI is going to dramatically impact how users interact with this system. Is there anything, I guess in particular that is exciting for you on the horizon or in the future for Elk? Are you guys just looking for more users hoping to see it grow? What's motivating you and keeping you interested at this point?

Daniel Roe:
So I think the key thing for me is just, is this going to be a good experience for me to use? So very selfish. So I mean I think that's the key thing. The aim isn't ever to have adoption for adoption's sake. So not raising funds, we've not got any VCs to satisfy. This is purely a project for the good of the people who use it. So if it makes your life better, that's great and that's what we're aiming for. And if it's doing that, then it's just doing what it needs to do. Some big milestones coming up. I think some interesting things to look forward to in the next month will be on the release of Elk as a Nuxt layer so you can actually extend it.
So rather than installing it by cloning it from source or having your own fork, you'll be able to add it as a dependency in your package and actually extend it by just replacing a single component or adding a new page or dropping in your own module or something like that. And that is a really, really nice feature by Nuxt three, which basically means you can compose an app from a number of other apps or just one or two. And so that I think will mean people can play with and extend it a lot more easily. So that will definitely be worth having a look when that comes out. And that's also, I've been implementing that locally and I think that will also push forward some of the extend support in Nuxt three as well.

Noel:
Nice. Good one for tinkerers, is there anything else you want to call out or mention, direct listeners towards?

Daniel Roe:
So one interesting thing, I can't remember if I've mentioned this before, but there's a project I've been working on for a little while called Magic Regex. So do check that out, if you haven't come across it before, it's a natural language way of writing regular expressions. But it all compiles out into normal regular expressions when you build your project, it's type safe and brings some nice quality of life improvements and in terms of detecting errors that you'll experience at runtime statically at the type level when you're using your regular expressions. And that's been a fun project to build. Yeah.

Noel:
Well again, it's been a pleasure, Daniel. Thank you so much for coming online and chatting with us.

Daniel Roe:
Yeah, it's a delight. Thanks for having me.