I'm new to the world of open source development, at least as an author. This is mostly because it has always felt like whatever tool I need, someone has already made it. It makes it seem like any tool I can think of is an internet search away, be it for my professional needs or my personal hobbies.
This notion was challenged last year when I was looking for a good tool to backup my favorite YouTube videos and playlists locally, on a better level than simply downloading video files. In a way, I was right. There are definitely options for what I wanted, but in different extremes.
One side was the self-hosted tools that could completely set up a containerized VM in your own machine or self-hosted setup, where you can save anything you want. Now, I'm someone who cares deeply about preservation of art and expression, but I don't have the resources to set up a whole self-hosted stack, and doing the whole rigamarole of setting it up on my personal computer feels like hammering a nail with a mallet.
The other side of the spectrum was fully local options that sometimes had more or fewer features: downloading subtitles, different language audio tracks, queuing downloads, embedding metadata, and more. But all were still falling short of what I was really looking for. What I really needed was solving an issue I've had with YouTube for years.
Jump to:
- One (More) Reason I Hate YouTube
- So what exactly did I build?
- The app and its features
- Building the app architecture
- Why is this app different
- Licensing and GPL
- A disclosure
- Links
One (More) Reason I Hate YouTube
Here I am, on one of those days I'm feeling nostalgic and want to kill some time, and I find myself checking YouTube playlists. There I see my favorites, a list of videos I've been expanding since my youth, and I encounter the worst thing YouTube does to its userbase: an "8 hidden videos" legend at the bottom of the list.
I haven't played all of my favorites list in years, and if you put a gun to my head there's no way I could remember what I'm missing. But I know one thing: if I put it there, it's because it meant something special to me at some point, and now I have no idea what it was.
I honestly think this specific practice, of professionally gaslighting their own userbase, is one of the worst things a platform can do to its users. You should have the right to delete, privatize, or hide videos from your platform, but it's my opinion that you shouldn't just lock away the information of what was in it. I'm pretty sure most of them were bits from comedians I liked, or maybe an animation from someone I've since forgotten about. I will never know now, because YouTube sucks at transparency on this (and in lots of other levels too).
This is the impetus that had me looking around for a tool that would let me actually save this kind of data, with varying levels of flexibility.
So what exactly did I build?
Now that you know my very specific, glorified pet peeve, the rest of the story is simple. In 2025, when I searched for this tool, I didn't find it, and having some time on my hands, I figured this was a good time to get some coding hours working on a project that does exactly this.
I read up on yt-dlp's documentation and shopped around for alternative UI libraries. With yt-dlp being written in Python, I tried some desktop technologies for Python, but I wasn't very happy with them, and I didn't think they'd have the flexibility I needed if I ever wanted to expand the design.
Eventually I landed on Electron as my platform, since it offers good cross-platform support, has a fairly big community and it has very good UI to OS communication with IPC. I picked React as my UI library, since I'd already been working with it for the last five years, and TypeScript mostly because I wanted to try it out, to be honest.
With my pieces in place, I began actually building the app that I eventually called Sloth Archiver, to evoke the core principle of the design of keeping things simple and easy to use for the lazy archivist like myself whenever possible.
The app and its features
I iterated as I went along but there were some seminal features that I knew for sure I wanted this app to have: saving the actual video metadata, saving whole playlists, downloading in any quality and with the option of downloading as mp3, and one that seemed to trip up a lot of the tools I used to use for video download: being able to actually handle long, and I mean REALLY long videos. For some reason a lot of downloader apps really trip up with this specific step. I'm not sure if they use some faulty wrapper on top of yt-dlp or just never test for weirdos like me who want to download 10 hour videos every once in a while but this made it one of the goals to make sure my app could handle.
Building on top of this download framework the next layer came natural. I need to put the metadata somewhere so I'll build a local library view where all the metadata can be shown. This library will naturally grow so it's gonna need some search and filtering features. This library should naturally also have a built in player, for both the youtube video and the local video if you have it.
Building further on top of this, if the video download already support converting videos with ffmpeg why not offer this as a feature of the library itself? Each video can be converted, extracted to mp3. Hell we can even have a clipping feature allowing you to clip your favorite parts of that 10 hour video you downloaded the other day! Of course this clipping feature will need a clip collection in the UI, this is supposed to be an archive after all.
And why not use the flexibility of React to actually build a custom video player component in which we can have some of the features like the clipping tool? Yes, now it's all coming together.
This is good and all but how does this archive save the data? I'm a very simple guy with straightforward ideas. When I think of an archive in my machine I want to know I have full control of it. Which is why I wanted to make all of this work completely on filesystem and preferably as decoupled as possible from the program. In theory if you move your entire library to a different machine you will still have it all organized how you left it opening the app in this new system. If you get tired of this app and just want to keep everything in files because my UI pissed you off or something then uninstall it and enjoy your organized library files without issue. The point is total freedom and not dealing with dockerfiles, VMs or manually organizing a dozen files you downloaded and forgetting where you put them
Building the app architecture
(Note: if you're not into the technical details, feel free to skip ahead →)
On the technical level, the functionality is not complicated: The React UI is mounted on Electron, a multiplatform desktop application framework. Which allows my UI to have communication channels with the OS through Electron's IPC module to do things like requesting filesystem changes, OS information, and critically, executing child processes. This is where yt-dlp and ffmpeg come into play.
YT-DLP is a very popular download engine for youtube and thousands of other platforms, it's very powerful and constantly maintained, if you download videos from youtube anywhere there's a good chance it was powered by it. In the app this is the child process that handles the actual downloads and some subprocesses like converting to MP3 on the fly after a download.
FFMPEG is also a very powerful tool used everywhere but this one is for multimedia processing. It allows manipulating video, audio and even images through command line in many, many ways that would take too long to explain but in the app this powers all of the video manipulation tools in it.
These child processes do the heavy media file lifting while the rest of the IPC functions do all the filesystem archiving so connecting these elements we have a UI on top of a video downloader and more importantly working at CLI level means we can handle pretty much anything the CLI can handle as long as we implement it correctly.
Auto updating yt-dlp
The next thing everyone that used yt-dlp or any of the tools that implement it will know is that we need to constantly update it since google is in a constant war for hoarding information and not letting anyone get to it which means any video downloader worth anything needs a yt-dlp updater. For this I iterated several solutions, my first dev build was just running the system's own python module to do some initial tests but later on a packaged build would contain built binaries of the CLI which would evolve into fetching the pre-built binaries from the yt-dlp repo. Which I'm sure everyone who works in these type of apps knew from the start but give me a break I don't like reading, ok.
Of course downloading binaries has the small caveat that a SHA hash validation is in order which is already provided with the release so it's a matter of setting up that validation. Eventually all of this download and validation was set up into the app and now updating yt-dlp is one click away whenever the user needs it.
Youtube strikes back (Constantly)
Another thing that maybe people really familiar with yt-dlp see as obvious but I honestly had no idea about, mostly because of a period of development hiatus around this update, is the fact that yt-dlp now required a node/js runtime to run some of the modern youtube validation challenges. When finally resuming work on the project this was one of the first issues to solve.
My initial thought was packaging a JS runtime like Deno or Bun with the app, but investigating further led me to find it's possible to use Electron's own mounted runtime as node and this allows yt-dlp to have its node runtime without making the packaged app heavier. This is something that at time of writing I'm still experimenting and running tests on to find out if a completely new sandboxed runtime is worth packaging for the use case or not.
This architecture model has remained unchanged until time of writing with the mindset of keeping the app simple, flexible and decoupled from the system without sacrificing good engineering practices. This architecture however can evolve as the technology requires or improvements are found as the project grows
Why is this app different than the rest
In many ways it's not very different than the rest, but it has the features I really wanted for a tool like this and no one seems to have made. If I was doing a commercial pitch I would call the selling point the Library and all its small features and potential to expand. I'll be the first to admit some tools out there are much more mature in some aspects, but none of them are even aimed at offering this combination of features, and I got tired of waiting for someone to make it happen; it's easier to build up the maturity of the download tool and grow my own app so I went for it.
So who do I think this app is for?
- For people who like having their videos saved but don't want to go hunting through folders to find. You can add videos to the library then search, label, order and explore through your library and even play the video in an embedded local player
- For people who like or need downloading, clipping, converting, organizing videos of all sorts to make compilations, archival copies, reuploads, remixes or any type of transformative work with a high quality copy of the original source material. You can download at any available resolution then clip, convert, extract mp3 of the source video without losing any quality.
- For people who save videos because they hate when they get censored or edited down to comply to whatever draconian life ruining terms of service update Youtube will cook up next. You can download versions of videos in different timestamps and keep both with this app
- For people who want to keep their favorite youtube playlists saved and not worry about losing the data to the dreaded "X videos hidden" label at the bottom. You add your playlist and keep it synced with the app and update it whenever you want, if any videos are hidden your local copy won't be affected.
If you fall within any of these kinds of users maybe you will like this app. If not then maybe keep an eye on it and I'll win you over on the next update.
About licensing and why I chose GPL
To me this was the boring part but obviously if I didn't license under MIT and call it a day then I must have some reason for it, right? While looking at the current market of solutions and apps related to youtube and video download in general it seems like there's plenty of projects trying to paywall this kind of functionality. I personally don't like this, since the heavy lifting is done by yt-dlp and its community. Following this train of logic I decided to license this under GPL just to make sure if this ever were to grow or catch the attention of many people the free and open source spirit of the project isn't lost in the future. In my mind these kind of projects should reflect what the intention of archiving and downloading media from the web is, a vehicle to preservation of art, expression and ideas.
Something to disclose before the end
I feel the need to disclose this since it's a hot topic in internet spaces. I implemented a lot of the code using Claude as a code agent to speed up the implementation of features. I'm a professional developer with years of experience designing and implementing solutions for enterprise software. By my own principle I don't let agents run wild and add features without specifying exactly what I need and testing and fine tuning every detail myself, but I realize people have a wide range of views about LLM usage in the dev space. So I leave this section here for full transparency
Wrapping up
With nothing more to add I can only thank you for even taking the time to read my article and I hope I can build this project up more and more in the near future. If you'd like to know more I leave the appropriate links down below. Thank you and have a nice day.
Check it out
- 🌐 Info page: slothsoftworks.github.io/SlothArchiver.info
- 🔗 Repo: github.com/SlothSoftworks/Sloth-Archiver If you try it out, run into issues, or have feature ideas, opening an issue on the repo is the best way to reach me. Feedback from actual use is what's going to shape where this goes next.
Thanks for reading. Here's a Sloth
Credit for images used:
https://www.pexels.com/photo/close-up-of-hard-disk-drives-on-white-surface-32920312/
https://www.pexels.com/photo/gentle-sloth-in-lush-green-tropical-forest-32896689/
Top comments (0)