Yamada Blog

A Guide to Obtain TOTP secret key from the Duo Mobile App.

Wed, 20 Aug 2025 00:00:00 GMT

Prerequisites

To access the required application files, you need an android device with root access.

It can either be:

A rooted Android device.
An Android Virtual Machine with root access (probably more commom).

You also need to have the Duo Mobile app installed and your account fully activated on that device.

Step 1: Locate the Account File

Using a file manager that with root access, navigate to /data/data/com.duosecurity.duomobile/files/duokit/account.json.

This account.json file contains the configuration data for your Duo accounts.

Step 2: Extract the Secret Key

Looking at the file, you might see something like this:

[
  {
    "version": 1.0,
    "accountType": "DuoAccount",
    ...
    "otpGenerate": {
      "otpSecret": "AB4CDEFGH3IJKLMNTEGU5245GT123456\u003d\u003d\u003d"
    },
    ...
  },
  ...
]

Identify the specific account object you want to export from the list.

Within that account's block, look for the key "otpGenerate".

The value for "otpGenerate" is another object nested inside. Within this nested object, you will find the key named "otpSecret".

Replace the \u003d with =. In this example, your key is AB4CDEFGH3IJKLMNTEGU5245GT123456===.

Step 3: Import the Key into a New Authenticator

Open your preferred authenticator app (such as Google Authenticator, Authy, etc.). Choose the option to add a new account by manually entering a setup key. Paste the corrected secret key. Once saved, the new app should generate the same 6-digit codes as Duo.

The AI Limbo is Tiring

Thu, 12 Mar 2026 00:00:00 GMT

It has never felt so uncertain to be looking for a job in tech.

If you had asked me a few years ago what the future held, I would have had plenty of ideas—but this current landscape wasn't one of them. We are in the middle of a bizarre transition period where neither companies nor candidates seem to know exactly what the new rules are.

The biggest point of confusion right now? Artificial Intelligence.

Recently, I spoke with some folks from Microsoft. Their advice was clear: they want to see candidates leveraging AI, and they want to see a strong online presence (which, full disclosure, is the actual reason I finally started this blog). It sounds like a solid, forward-thinking strategy. But then you look across the aisle at other companies, and the story entirely flips. For some hiring managers, the moment they suspect you used AI in your application or workflow, you are rejected on the spot.

And the sad thing is, both of those extremes are actually the "good" kind of companies to deal with—because at least they are clear about their expectations. For a vast majority of the market, it is incredibly unclear what their goals are or what they actually want from you. You have AI companies that seemingly require candidates not to use any AI to prove their raw skills, and on the flip side, you have traditional, legacy companies trying to be hip by forcing it into their hiring process. It is just a mess.

Even the "experts" are at a loss. I recently went to a handful of career advising services provided by my university, and I walked away with wildly conflicting information. Everyone has a different opinion on how—or if—we should be using AI to get hired.

Honestly, I don't really care which way the industry goes; I can adapt to either. But being stuck in this middle ground is exhausting. It is undeniably clear that something massive is shifting in the tech world, but we are stuck in that messy in-between phase where there is absolutely no public consensus.

Am I just frustrated by how this impacts my own life and career trajectory? Yes, probably. Am I still excited about the underlying technology? Yes, as always.

But on the other hand, it is incredibly draining. It is nearly impossible to deal with industry-wide changes of this magnitude when you can't even get a straight answer on what companies and HR departments actually want from you. The rules of the game are changing daily, and right now, nobody seems to have the official playbook.

What I learned from 'Vibe Coding'

Fri, 13 Mar 2026 00:00:00 GMT

Vibe coding is one of those topics that people have incredibly strong opinions about. On one side, you have people who are deeply passionate about agentic systems, which is understandable: the exponential growth of these systems in the past few years—or even just months—has been nothing short of incredible. On the other hand, there are people who are passionately against them, which is equally understandable. The generated code is often still not reliable enough for a medium-sized project, and it has historically been virtually impossible to ask AI to interact with any codebase of a reasonable size.

I used to be closer to the latter camp. I was skeptical that a system that couldn't even do basic autocomplete could actually do my job. But these systems are getting better—significantly better. Now, I am convinced that the future of coding will look very different.

So, I am here to share some of my experiences with "vibe coding" and how it has completely changed the way I approach programming.

You Can Just Do Things Now

In the past, even though I had worked on a couple of relatively large projects, I always had a bit of fear when starting a new one. Fundamentally, I didn't want to maintain a large codebase for virtually no audience.

That mindset wasn't ideal, because there were many programs I wished existed but ultimately didn't. One such project was an Android client for Memos.

How I Vibe Coded MemosM

While MemosM isn't exactly the first project that I vibe coded, it is my first public project that only exists because of agentic systems.

To give some background, Memos is a FOSS note-taking application with a UI similar to Twitter, which I find very helpful for encouraging me to write things down. I've personally been using it for a couple of years, but my experience hasn't been entirely positive. I had two main issues with Memos:

Unstable API: It changes all the time for no apparent reason. It also nuked my database once, so I would say their engineering practices are subpar.
Lack of an Official Client: There are third-party options, like MoeMemos, but because they are unofficial, they also break all the time.

Over time, MoeMemos kept getting worse. It used to be reasonably fast, but around last year, it became unusably slow just to open. I finally had enough and decided to take things into my own hands. That’s how the MemosM project started.

The MemosM project was supposed to be a bare-minimum implementation of the Memos API: I wanted to see some notes, and I wanted to be able to push new notes. That’s it. I didn't care about reactions, local caching, editing, markdown, or any of the other features.

It sounded like an incredibly easy project—actually, way too easy, because it is basically just a TODO list app. I wasn't expecting to learn anything new, and the scope was intentionally small. I thought I could vibe code it in a day or so, and I did. I had a functional app with note-taking abilities within the first few hours of opening Android Studio.

But then I thought it would be nice to have a login screen...

And then I thought it would be nice to support the comment section...

And then I thought it would be nice to have a profile page...

And then I thought it would be nice to have multi-account support...

Before I knew it, my app had strictly more features than MoeMemos. My initial plan was just to have a fast, lite client for small stuff and handle the actual writing on the web. The crazy thing is: I didn't write a single line of code.

I just described what I wanted, provided some context to the LLM, and it just did it. I reached that feature-rich point within the first week of the project. I now maintain an Android project that is significantly more complicated than the app I set out to replace.

When you look at apps like MoeMemos, you realize it must have cost the developer a massive amount of time to build. But today, you can actually just vibe code a significantly more complicated app from scratch.

I also learned so much about Android development along the way. I didn't even know Android had functional components (like Jetpack Compose) before this. I had never touched Kotlin. I knew some basic Android concepts like Room and Gradle, and that was it.

People like Jonathan Blow and Casey Muratori might argue that modern toolchains introduce unnecessary complexities. But as a user, I always enjoy the feel of a "native app," even if there's no deep technical reason why the official toolchain is strictly better.

Vibe Coding the Lytro Driver

I bought a Lytro camera a few years ago, but I was unable to get the photos out of it because they are stored in a very weird format, and my Linux PC didn't have a working client for it. Wine didn't work either.

Someone had written a Linux client a while back, but I couldn't get it to run. The codebase was simply too old, and the bit rot was too severe.

So, I asked ChatGPT Codex to migrate that old code to Python, and it works. Like, it just works.

I am sure this isn't incredibly hard to code. It isn't doing anything groundbreaking, and after all, it was just translating an existing implementation. But it is still crazy how seamlessly it succeeded.

There are so many old projects out there written for poorly supported platforms that require highly specific dependencies. Mountains of technical debt used to make me highly cynical about the future of programming—code that no one could afford to pay down. But now, with AI, you can pretty much vibe port anything to a modern, supported language.

Closing Thoughts

The programming landscape is going to be very different, and I think everyone who is paying attention knows that.

More and more software companies will be forced to transition to providing "services" as opposed to "software." This was already a trend, but AI is going to accelerate it significantly. I have a strong feeling that the future of programming will be like clothes—software will become incredibly cheap to produce, and people will just tailor new, disposable, bespoke software for their own personal needs.

Today, if you want a hyper-specific photo filter, you might need to know Photoshop. Tomorrow, you can just ask an AI. In the past, there were many domains I didn't want to touch (like native Android development) because I couldn't justify the time investment. Suddenly, those domains are entirely accessible.

I think more and more people will become interested in programming. I hope that is a good thing. AI is only getting better from here.

Embrace 'Context Switching' for the Brain

Sat, 14 Mar 2026 00:00:00 GMT

When I was a kid, there was a trendy idea claiming that it might be beneficial for kids to try to do more multitasking, because it might be good for... reasons. While the trend quickly died down, I certainly drank a lot of the Kool-Aid back in the day and regarded my inability to concentrate as a good trait.

Now that I am much older, the narrative has shifted. Now it is all about how the latest neuroscience tells us that staying concentrated for a long time is better, and how a short attention span is a problem.

I just came across a post that mirrors this narrative today, and I think there is actually something to chew on here. I am no neuroscientist, and I will probably get all the facts horribly wrong, but I think whenever a societal trend flips, it is almost always about overcorrection. Other similar topics that come to mind would be social justice and religion, but those two topics are way too controversial. So, I guess I will just comment on the not-yet-overly-politicized topic of multitasking for humans.

As I've grown older, I do find myself having a better ability to concentrate. I remember when I was in grade school, I could not sit in a 40-minute lecture without constantly asking my friends how much time was left. My friends got quite annoyed sometimes because of that. This behavior continued all the way to my high school years, but by high school, I could actually sit through an entire 40-minute class. Concentration does seem to be a skill—a skill that you gain as your brain develops, or at least one that seems to be learnable in my case. I certainly find it quite beneficial to be able to sit down and do something for hours.

But this is actually not the claim often made by people who are pro-concentration and anti-multitasking. No, their claim typically has more to do with how the human brain functions. The central claim is that human brains are actually extremely slow at 'context switching,' and distractions of any kind are strictly harmful to productivity. Some people even go to the extreme of claiming things like music might be harmful because lyrics distract you from your current work. It distracts you from the "flow state" of mind, which, allegedly, is the best state for your mind to be in.

I think there are some studies on that; I am not sure. Again, I am not a neuroscientist. But claims of that kind feel quite suspicious to me because they contradict many other things you would expect a human to do—and arguably, beneficial things for a human to do. For example, typically, after intense sports, you need a recovery period. There's also the age-old recommendation by literally all eye doctors that you should try to look away from the screen every 10 minutes or so. Clearly, many things that humans do require breaks from time to time, and sometimes quite often.

Many tasks that people typically regard as a single monotask also often consist of multiple different parts or cycles. For example, when coding, what typically happens is people need to think about what to code (like what features to add, what changes to make to the whole system), then how to code (the specific implementation), and finally debugging and testing. While most people regard "fixing tickets" as a singular task, the task itself almost always consists of many parts. If the claim is that multitasking of any kind is harmful, we must ask what multitasking even is in the first place: are we not supposed to be parsing the request and thinking about the implementation at the same time? Should we not think or look at unrelated stuff while the program is compiling? Are we not supposed to read documentation while we are trying to write code? Even with pure vibe coding, you still have the same issue. This is not only an unrealistic expectation but also something that is clearly dogmatic to the point of being useless advice.

I'd also like to challenge the idea that monotasking is not only unrealistic and unhelpful, but that it might lead to worse outcomes. As someone who writes from time to time, I don't typically write the whole thing in one sitting (unless it is for useless blogs like this). What I typically do is write the first draft, and while I am doing it, I will browse X or YouTube. What often happens is I end up finding something more fun to add to my work, because algorithms are good these days. I am almost by definition doing tons of multitasking, but I personally believe that as a direct result of that, my writing is significantly more interesting. As an illustrator, I also draw from time to time, and the process of browsing and finding references not only helps with the final outcome but also changes what I decide to draw in the first place. According to the Internet™, this is le bad because you are not supposed to be browsing brainrot while working, but in both cases, I find myself producing results that are significantly better.

Thinking from an evolutionary standpoint, it only makes sense for humans to be able to multitask. First of all, as far as we know, human brain cells are heavily decentralized; each neuron only does a small thing. Some of our biological functions even operate on their own, such as the heartbeat. While sometimes under the control of your conscious brain, many of your important biological functions work on their own without you having to think about it. I don't believe the thinking part of our brain is just so different from the rest of our nervous system that it has some perfectly centralized architecture. Most things in evolution are co-opted, and our ability to think is likely a result of that. As such, our centralized thinking function is probably an illusion of decentralized compute anyway.

It also makes sense from an environmental perspective. In any human habitat, there will be many things that one needs to keep in mind at any given time. When someone is marching to find food, they need to try to walk while keeping an eye out for fruit, looking around to be aware of predators, and talking to other humans to build social bonds. In modern times, when someone cooks, they need to look at the color, focus on the flame, and reason about the next step to cook, at a minimum. It only makes sense for the human mind to wander around because we always live in environments with a lot of what some might call "distractions."

We also know that truly distraction-free environments are horrible for most people, as many of the sensory deprivation darkroom experiments—which wouldn't pass a modern-day IRB—can tell you.

So why is the internet so obsessed with attention spans and single-tasking lately? I have some theories. One is that the ability to do one task for a long time is typically a trait of older people; sometimes it's an acquired ability to enjoy one thing for a longer time, and sometimes it's the inability to multitask as one ages. TikTok being the new thing means that older people want to reject what they don't find particularly enjoyable. There is also the simple fact that culture almost always swings back and forth, because it is always fun to be a contrarian.

But the truth almost always lies somewhere in between. Just because strict monotasking is silly and probably counterproductive doesn't mean extreme multitasking—like listening to the Bible and Mozart at 2x speed—is helpful either. The specific proportion of each thing is probably different for each individual at different stages of their lives, and the internet or society at large never likes an answer that just says "it depends," even though that is most likely the most correct one.

So multitask or not, flow state or not—it doesn't really matter. People should probably just try to do whatever they find productive, and if you want to go the extra mile, try to time and quantify it. No one is the magic statistical average; you are the only person who has your brain.

Solving a Solved Problem

Wed, 18 Mar 2026 00:00:00 GMT

As anyone who has come anywhere close to what we call programming will tell you, there is an infamous quote:

Do not reinvent the wheel.

The reason I say it’s "infamous" is that many people since the 2020s have been actively rejecting this—particularly during the UI framework boom.

Something that I have been more interested in recently is pop philosophy. While I disagree with many of the pop philosophers of our time, I do find many of their works valuable. One example is the popularization of the inherent repetitiveness of the human condition. This, of course, is nothing new, as beautifully put in Ecclesiastes 1:9.

What we consider to be "new philosophy" is typically just an argument that people made thousands of years ago. Or, so it is commonly understood.

I personally disagree with that analysis based on a basic thought experiment against the possibility of an all-knowing being: If such a being knows all there is to know, then there is a new fact—that the being now knows all there is to know—which was not in the original set. In a more practical sense, even if someone possesses wisdom and propositions, the reality and conditions of the ever-changing outer world mean there is always more to know.

That said, I am still extremely sympathetic to the view that there is "nothing new under the sun," and in many ways, we are just repeating ourselves. It is unclear what is actually new about a "new" item at McDonald's, even though it is, technically, new.

I have been thinking about this more and more lately, as it seems a lot of the challenges in software are just solving problems that have already been solved. From ray tracing to parallelism; all the advancements in AI, only to make yet another CRUD app. There is a new version of macOS releasing every year, but the interactions have stayed largely the same since the 90s.

Yes, there are new things. But in many ways, it seems people are overwhelmingly trying to solve problems that someone else has already solved. For a relatively young field like computer science, this might seem quite surprising.

While I certainly felt bored by that for a while, I now want to offer a bit of my own analysis, aided by the knowledge these pop philosophers helped popularize. It doesn't really make sense to separate "English philosophy," "Continental philosophy," or "Russian philosophy" because the underlying human conditions are all the same. These topics have been discussed not only by people from those places but throughout different eras. Yet, it still makes perfect sense to group them that way because the specific time and place in which those people came up with an idea provides the exact material required for those ideas to exist.

Software people might have been doing basically the same thing for a very long time. However, it seems to me that—similar to philosophy—nothing is quite the same. Even more similar to philosophy: the fact that someone has done it before is not a valid reason not to do it yourself.

People like to talk about "Not Invented Here Syndrome," and it can be quite annoying at times. However, from a cynical perspective: those repeating tasks are exactly what hold companies together. Just like the stories we tell each other are what hold a culture together. It is a group activity that humans do—ironically using the things that everyone does to tell the "in-group" and "out-group" apart.

In many ways, even if AI does all the CRUD apps in the near future, people will probably still develop them. Just as people still use pens and pencils after the invention of the camera. These "silly" things don't need to be better to be good.

Stop Over-socializing

Sun, 05 Apr 2026 00:00:00 GMT

I have recently started thinking more about the discourse surrounding social interactions. It is quite interesting: people claim they want more social interaction, yet we are more connected than ever. Most people who discuss this topic love to "yap" about the "lack of connection," which I find silly. The fact is, people are connected. Claiming that online connections aren't "real" is objectively untrue, yet this narrative persists.

Many scientific studies have demonstrated that the level of rage people feel today—and the so-called "information bubble"—isn't quite what we think it is. In many ways, the "isolation" narrative is pure fiction, yet many still claim the opposite of the truth.

This reminds me of the food industry and its propaganda.

Social media companies, like food companies, profit from our biological drive to be social. Like anything capitalism is good at, it has created wealth and abundance. We now have an unbelievable abundance of both food and social interaction, but humans simply weren't designed for this volume.

In the ancient past, social interactions were few and far between. There were only a few people you interacted with on a daily basis. Whenever you encountered a neighboring tribe, you had to ensure you were on the best terms possible. People evolved a natural kindness toward strangers—perhaps even too much—because you could never be "too social" in the past. It was always better to have more friends than you needed than to have too few when you were in trouble. It’s exactly like food storage.

Social media companies have reduced the "cost" of socializing to an insanely low level. In the past, to socialize with friends, you needed a reason—sharing a meal or playing a game. You had to physically travel, schedule a time, and find a place to meet. During the interaction, you had to constantly read the other person's mood and try to make a good impression. In older times, you even had to change your clothes just to join a social setting. All of these factors created significant "friction" for social interaction.

America, with its egalitarian culture, already had a relatively low social cost, and now it is exporting these low-cost interactions to the rest of the world. Now, to get a social fix, you just type on your phone or scroll. You don’t need to think, and you don’t even need to pay attention to the other person. It really is "junk food." People can now talk to someone in a different country and worry about their problems, whereas in the past, the number of people you could possibly care about was probably fewer than ten.

This, of course, is not healthy, yet no one is providing a good solution. Many recognize that social media is like junk food, yet they aren't giving the same advice we give for food consumption. It isn't just about the quality of the connection; it’s about the amount. Even the best fresh, organic food is bad for you if you eat too much of it. Social interaction is the same. The answer isn't necessarily just forming more "in-real-life" bonds (though that helps, because like a diet, adding restrictions reduces consumption); it’s about reducing social interaction in general.

We aren't even at the "GLP-1" stage yet. We don't have a drug to reduce the human desire to form bonds. In fact, we are in a "negative" stage: it’s as if everyone is overweight, but the experts are telling us to eat more, just as long as we "eat healthy."

I’m not a researcher, and I’m not going to solve this entire problem here. But I want to bring attention to the right approach: we don’t want to destroy food companies because they provide food, and we don't necessarily want to destroy social media. What we ultimately need is a "metabolic" fix—something that allows people to control their desire for constant social dopamine. Anything else is likely on the wrong side of the issue.

Porting YTDLP to Bun (YTDLB)

Sun, 24 May 2026 00:00:00 GMT

Recently, Bun migrated to Rust using Claude Code, which resulted in significant performance improvements and a smaller bundle size. From a technical perspective, that is quite impressive. Reducing a bundle size at that scale is no small feat, and so far, I have encountered no regressions on the Bun side. Let's be honest, what Bun does should have been in Rust the whole time. Most of what Bun does is highly static and deterministic, and there is a very well-defined interface for its core functionality.

But of course, there is the elephant in the room: Claude Code. I personally almost never participate in internet drama, but this time, yt-dlp is dropping Bun support, explicitly citing the usage of LLMs in the code. I find that stance irrational and silly, especially given the objective improvements across the board, though that probably does not include compile speed, wink. I went to the yt-dlp GitHub issue to see if that was actually the case, and sure enough, that was pretty much the only reason.

Normally I would not care, but I was "vibe coding" a yt-dlp web GUI to manage my watch history, and I was using Bun for its significantly smaller bundle size compared to Node and its overall better developer experience. This change forces my project to either stick with an old Bun version indefinitely or bloat the bundle size. Both options are suboptimal. So, I raised my concern, citing essentially the same reasons.

I saw the writing on the wall, so I started working on my own fork in TypeScript.

The other day, I saw my comment deleted by the yt-dlp dev, and I was blocked from the project. Honestly, I did not even know you could be blocked on GitHub, but I guess it is an honor to be blocked by one of the more important OSS projects out there.

Personally, I have always had a few issues with the direction of yt-dlp. First, it is a Python project with a hard dependency on a JS runtime because many websites use JS for bot detection. As a result, a minimal bundle of yt-dlp requires both a Python interpreter and a JS runtime, which is ridiculous. Second, yt-dlp is essentially impossible to use as a library. This is not just because of an intentionally opaque codebase, but also because of the complete lack of type hints. yt-dlp requires Python 3.10+ so there is no backward compatibility excuse for the lack of typing, and it makes the code nearly impossible to integrate.

While those were my primary technical frustrations, the developer's recent attitude toward AI-assisted coding is, in my opinion, the final straw. No matter your opinion on AI, it is factually great at two things: handling trivial problems and doing the boring grind of programming. yt-dlp is a project with very little architectural complexity, and most of its complexity comes from the fact that APIs change constantly. It is the perfect candidate for AI-assisted maintenance. Imagine having a nightly agent that tests and fixes API failures automatically. Instead, yt-dlp fails constantly because, without type hints, it is extremely difficult to refactor with confidence, even though the changing ecosystem demands constant refactoring.

The greatest sin of yt-dlp is probably its API stability, or lack thereof. You cannot trust the JSON output at all. So many people end up writing convoluted custom parsers just to handle the unreliable JSON output of yt-dlp. The only reason people do not deal with the underlying APIs directly is that there is no universal interface. yt-dlp could be that interface, like FFmpeg, which, regardless of how you feel about the developers, at least works, but it refuses to provide one.

Those are my objective beefs with yt-dlp. My subjective ones include a weird obsession with vendoring things without good abstraction. For example, there is a JS interpreter vendored inside the Python code, which does not even work properly, yet it remains there: yt-dlp/jsinterp.py.

I do not have an issue with vendoring in principle, but I take issue with engineering solutions that do not work and still ultimately require a JS runtime anyway.

Anyway, hopefully, I have demonstrated why I think the current yt-dlp codebase is in a rough spot. If you take a look yourself, you might agree.

That brings us to the TypeScript port. Almost as a joke, I decided to port the whole thing to TypeScript using AI, and it actually works surprisingly well. In less than an hour, I was able to download a YouTube video. It is not feature-complete yet, but it does what most people actually use the tool for.

Building on Bun, besides avoiding the JS runtime issue, allows me to access things like lol-html, which is extremely cool. It is also trivial to build a standalone executable, unlike the forced GPL of PyInstaller. Whether that is a pro or a con depends on your ideology, but I personally value the convenience. The Bun rewrite will take a while, as I have other stuff to do, but it is going to be a much better solution for me. It is significantly easier to manage a TypeScript project than an untyped Python one for a Bun server.

I do not have a rigid roadmap, but I am making a few decisions to ensure the project stays healthy. I am using Zod for schema validation. Unlike the Python version, which lacks type hints entirely, I am using Zod to enforce shapes. This makes error handling significantly more transparent because you can actually see what went wrong instead of fighting the codebase. I am also prioritizing heavy use of async. This is required for JS, which is one of the rare cases where JS actually forces developers to do something reasonable. It will make for a significantly more performant library. Finally, I am including strict type hints. This should be the bare minimum for any modern project.

This will likely never be a feature-for-feature fork. I have no interest in supporting JS runtimes other than Bun, and I am definitely not supporting the Python plugin feature. The whole concept of a YouTube downloader should have been a library from day one, not a massive, monolithic program with random features and undefined usage.

Feel free to vibe code and contribute to the repo here: https://github.com/yamada-sexta/yt-dlb.

I will set up nightly regression tests and some AI auto-repair when I have time, so it should hopefully just work.