All right, it took me a while to figure this out, but I finally put my finger on it. What bothers me about the Blue Sky app? It's really trivial, yet it's an anxiety-producing bother. It's not something I expect to be widespread, but it's the resemblance of feeds to tabs in a browser.

My mind does not handle tabs like a normal person. My OCD kicks in. Tabs aren't something you're allowed to let live for days, weeks, months, or an eternity in your browser. For me, tabs are a thing that's current and must be reckoned with immediately and closed as soon as possible. I don't have hundreds of tabs open. I have two tabs, three tabs, or no tabs. I have nothing on my desktop, and it's not normal, but it's the way I use tabs.

This is what bothers me very, very subtly about the Blue Sky feed design. There are tabs—tabs that are always open. And I can't escape from it. There's no end to it. It's a little disconcerting. It's something I've been trying to figure out about the app design, and it just dawned on me. It's the tabs.

Welcome back! Here's my latest update on what I'm working on right now.

I'm currently focusing on transitioning from the audio player format, which can be a bit challenging to read, to a text format that integrates seamlessly with an audio player. This shift aims to enhance readability and user interaction.

Initially, the idea was that people would embed audio players and not necessarily read the posts. However, I'm starting to embrace the concept that what users really want is a hybrid format. This format would offer both media elements simultaneously, allowing users to choose whether to read, skim, or listen. For instance, you might start listening and find it uninteresting, then decide to skim the rest or fast forward to a more engaging section.

This transition might require abandoning the old templates. Currently, there are four to six templates designed for audio-only blogs. I've added the ability to view transcripts, repurposing the transcript area to display markdown blog posts. However, this setup isn't the most reader-friendly as it's optimized for listening. A rework is necessary to better align with the blog post format.

As part of this transition, I plan to move to human-readable URLs soon. I'm also developing a feature to dynamically rewrite meta tags. Instead of relying solely on the title, image, and description, this feature will generate more robust social media post formats and automatically embed card tags. This improvement is progressing well and will enhance social sharing and search engine optimization.

Another focus is updating the share tags for video posts to ensure a more seamless experience. My ultimate goal is to iterate on these changes until you can effortlessly record a post, share it on social media, and view it as either a blog post or audio content. Achieving this will allow me to concentrate on the SEO component of the project.

Thank you for tuning in to this update. Stay tuned for more developments!

Hey there, welcome back. I'm James, and this is my indie maker update for Saturday.

What you're hearing is a new audio file format. Optionally, you can add a logo identity to the beginning of your personal podcast updates. This addition makes it sound a little bit more professional, a little bit more like a real podcast. However, right now, it's limited to one very generic, very inoffensive logo identity.

I handpicked and edited the logo identity to be short and very easy to add to any spoken audio track without requiring much tweaking to the way you record your audio. It works best if you start your audio in a certain way, like "Hey, welcome back" or "Hey, I'm James," instead of the more typical, boring way I usually start my audio recordings.

Hopefully, if this test goes well, this will be the track that is published and introduces the new feature. Thanks for listening.

Second Indie Maker Update of the Day

Aren't you lucky? Today, I spent about four hours fine-tuning my FFMPEG pipeline. Here's a rundown of what I worked on:

I experimented with a recurrent neural network to denoise the track. Additionally, I aimed to improve the audio quality by disabling certain audio helpers in the getUserMedia request. These helpers, such as echo suppression, noise suppression, and level normalization, are often applied by iOS or Android browsers. While they help in some cases, they can degrade the audio to something akin to telephone quality. By turning these off, I managed to elevate the quality to something closer to native recorder medium settings.

I made several tweaks to the pipeline that converts audio to MP3:

Overall, I believe I've significantly improved the audio quality compared to a few hours ago. I'm quite pleased with the results and look forward to testing how it performs on other devices tomorrow.

Hello, everyone. Today's discussion centers on the US steel and aluminum tariffs. I must say, this seems like a real rookie mistake. Imposing tariffs on inputs rather than outputs is a flawed strategy. US consumers don't directly purchase steel or aluminum, nor the byproducts of imported steel and aluminum. Instead, they buy goods whose value has been increased multiple times by various companies after the initial input was taxed.

We've been down this road before. In 2018, the US imposed similar tariffs on the same countries. We have case studies available that detail the effects of those tariffs. What happened was that US producers overbuilt capacity, leading to a significant bubble. Demand only rose modestly, covering just a fraction of the additional capacity. Prices soared, outpacing the additional production created within the United States. The intended effect of shifting consumption by US manufacturers from imported, mostly Canadian steel to US steel did not materialize. Manufacturers simply moved down the list to the next cheapest alternative, finding esoteric supply chains to substitute Canadian steel.

This cycle created a boom and bust scenario, harming US steel producers and manufacturers, with the benefits never materializing.

Now, we're considering doing this again. Look at the shale industry. After experiencing a boom and bust cycle, prices rose, and they decided against building additional capacity. They learned from past mistakes and chose not to repeat them. Similarly, US steel and aluminum producers are unlikely to respond to tariffs by expanding capacity. They won't rush to build new refining facilities or start extracting iron ore in Alabama and Mississippi again.

US steel and aluminum producers have found a different market than imported Canadian steel. They have a comparative advantage in quality and time to market. An entire industry exists to provide overpriced cut steel pipe quickly. They charge high prices but deliver swiftly, serving niche markets that require specific products urgently. These producers won't abandon their market to shift to low-end, low-margin steel production. Instead, they'll charge more for the same services, maintaining their market niche.

If policymakers would read the case studies, they'd see the flaws in their approach. This isn't a team setting goals and finding experts to implement policies effectively. They're experimenting with a multi-trillion-dollar economy and industries, relying on gut feelings and untested solutions. This approach is unlikely to enhance US competitiveness or yield material benefits.

There's an argument for increasing US domestic steel production for national security reasons. However, this argument is flimsy. To achieve this, investment vehicles and programs are needed to de-risk production expansion. It's similar to what was done with the CHIPS Act, which de-risked chip production in the US, incentivizing companies to take risks before demand was fully reliable. The US government showed a long-term commitment to purchasing US-made goods, even at higher prices.

For national security, it's beneficial to have Canada, our largest trading partner and ally, export all their steel, aluminum, and oil to the US. The US industrial policy over the last five decades has tailored supply chains to serve the US market. Forcing Canada to find alternatives would be counterproductive. We want to maintain strong trade ties, ensuring that Canadian industries continue to supply the US, enhancing both economic and national security.

Hello, welcome to my thoughts on tariffs and inflation. Here's a bit of background: I sell a digital product online and have a significant number of Canadian and European customers, along with others around the world. My business extends well beyond the United States.

When the idea of tariffs was introduced, I immediately started researching. I realized I needed to read the USMCA and examine Canada's list of retaliatory tariffs on U.S. goods. I had to consider the implications if the U.S. imposed tariffs on Canada, Mexico, or the EU, and if retaliatory tariffs would affect my product.

The good news is that the USMCA prohibits tariffs on digital goods. Digital goods are inherently difficult to tariff because they don't cross borders in the traditional sense or go through customs. It's challenging to imagine a scenario where digital goods are specifically targeted without a prolonged trade war or a significant effort from one side. Currently, neither the U.S. nor Canada has the mechanisms to impose tariffs on digital goods effectively.

The real concern isn't the potential 25% tariff itself—I'd be willing to offer a 25% discount to my customers to offset it. The core issue is the impact on customer confidence in the EU and Canada when considering purchases from U.S. companies. If the U.S. starts imposing tariffs broadly, it could erode trust and confidence in U.S. businesses.

To address this, I need to develop a marketing campaign that communicates our stance against tariffs. We could emphasize that we absorb the tariff costs and offer discounts to our customers who are affected by them.

Even if digital goods aren't directly targeted by tariffs, U.S. suppliers in Canada and the EU might face negative repercussions. Companies may instruct their procurement teams to be cautious about buying from U.S. companies if alternatives exist, due to the uncertainty tariffs introduce.

Many claim that tariffs are inflationary. However, the term "inflation" is often misused. Inflation should refer to what we now call "monetary inflation," a purely monetary construct. It's important to distinguish this from price changes, as inflation is the result of market dynamics.

In conclusion, while digital goods might be safe from direct tariffs, the broader implications on customer confidence and international trade relationships are significant concerns that need addressing.

Hello! Today, I want to discuss something intriguing that caught my attention a couple of months ago and has been on my mind ever since. It appears that Google has found a way to scrape data from an iTunes music library on the same device through one of their apps. However, I'm uncertain which app is responsible, and it doesn't seem to involve any information sharing or consensual data sharing with Google.

I have a specific set of music, primarily tracks I copied into my iTunes music library years ago, which are now part of my Apple Music library. These tracks have never left the app, and I don't search for these artists or songs on YouTube. Interestingly, this niche music from my library began appearing in YouTube notifications and recommendations around November or December, seemingly out of nowhere.

YouTube started suggesting, "Hey, you don't listen to music on YouTube. Why don't you try YouTube Music? We already have all of your music from your library. You could switch right now and start listening." This was surprising because my music was siloed in iTunes and Apple Music. I'm unaware of how Google could access it without some OAuth mechanism.

In iOS app development, there's a mechanism to add a "Sign in with Apple Music" button, allowing third-party apps to access data. However, it seems Google has found a way to scrape song names and artist names from the entire iTunes music library, possibly through one of their installed apps on my device. This data appears to be used to promote YouTube Music, a competitor app.

It's puzzling because one would assume Apple would go to great lengths to prevent a competitor app from scraping this data. Presumably, the only use for this data is to advertise within Google apps, encouraging users to migrate from Apple Music to YouTube Music. It's surprising that Google has managed to achieve this, despite Apple's likely efforts to prevent it.

Before jumping to conclusions, I've thought about this extensively. This isn't like those instances where people Google something and then see related ads elsewhere, not understanding how tracking works. I'm aware that phones aren't spying on us in that manner. While this situation might sound similar, I've considered it for months and can't think of any way Google could access this information except through an app installed on the same device.

Perhaps it's easier on macOS, and maybe Google used the Chrome binary to read my iTunes music library, which would be even more surprising. Whatever method they employed to obtain this data is likely interesting, and I imagine there are some Apple developers sending angry emails to Google about not adhering to developer terms.

In conclusion, I find this situation fascinating and worth pondering. How Google managed to access this data remains a mystery, but it certainly raises questions about data privacy and app permissions.