I read lots of comments already give you suggestions. I don’t want to comment which solution is the best, but inconvenience is not a good reason. If death threat is real, you will and have to be patient and learn whatever to save your life. Heros already show up and give you a hand and it’s up to you to reach his hand.

It’s really wild that someone wants to vibecoding while their threat model involved state level bad actor. What you guys need is not toys moving fast, but a team of security experts to ensure your app not being used as bait to trap the whole team. Tragedy is not no tools to use today, tragedy is we ignore dictators in globe reuse same strategy on others and we ignore others’ scream,tears and think dictators will spare us and hence not develop these tools, network in day 1. I am no expert,but I would learn from someone who prepare these threats in day 1 instead of vibecoding. And I am glad someone to contribute their expertise to help the hopeless one. Good luck.

• unix already prove pipe+ ecosystem is better than all in one box solutions
• all ppl’s ownership mindset is wrong. Typetype should own backup ui, state/tags, ref link, filepath,datetime and api+hook for above only, not backup pipeline
• some of clips i want to download and replay, some download+archive, some only bookmark and decisions are based on complicated factors. Everyone’s cases are different, no one solutions fit them all
• typetype can be accessed in multiple devices and provide thumbnail which are only missing piece compared to yt-dlp. I can chk clip backup status with thumbnail via bookmark feature
• backup pipeline fetch/loop queue, download and save file and update typetype via api/hook. File path can be s3 for backup or local for cache. Typetype and pipeline should have each other’s id. Typetype should allow pipeline have its dedicated tag list for something like s3 bucket, progress like queue,suspend… All backup logic remain in pipeline, typetype is just ui + pass thru state storage
• pipeline should able to move clip to another bookmark list,so bookmark list can also become pipeline’s state bucket if need. (Or maybe dedicated tag is enough)
• typetype should try to play clip in local, s3, steaming in order
• just a senior dev’s ocd

• one of most important problem you solved is centralised bookmark, history. When i watched a clip in mobile, i want my desktop client to know and hide it from me
• considered continued trend of high ram price, nice to have light weight mem efficient desktop app without ts,electron,webview,java those mem eating monsters, if we utilize app like mpv, plus your clear be,fe architecture, it should not that hard and easy to maintain.
• nuc+debian+flex launcher+remote control are such sweet combo compared to android tv. Way better than other media center solutions especially in noise, energy,codec, capacity, flexibility, security stand point. But i haven’t found remote control+nuc friendly linux desktop YouTube clients. That’s why I said centralised bookmark is important. Remote control doesn’t have keyboard, if I can bookmark in mobile/desktop and loop through in nuc via bookmark, it will be sweet. Again, you don’t have to finish by your own.
• I have a few more on backup iff someone interested. tubearchivist,yt-dlp are sweet, but all solutions i seen are missing some piece

Normally I would skip all yet another YouTube clients which provide no additional benefits than existed solutions, especially YouTube is always being a jerk and change their api/interface frequently and new projects never caught up. It’s good that you don’t reinvented the wheel by using existed extraction lib and split fe+be in design. How stable your library against YouTube’s change and how fast will they jailbreak it usually? Most competitors don’t consider ecosystem, does yours provide hooks, api for third party? I can tell you my usecase or problems i seen iff you are interested