Seeing this link today on Daring Fireball about self-driving reminded me of something I’ve wanted to blog about. Tesla is supposedly set to start their robotaxi service in Austin this weekend. I’m slightly worried about it.

Now that I’ve been in a Waymo — and experienced how smooth a ride it was, as safe or more safe than most Uber or Lyft drivers — it seems like asking for trouble to use anything short of the same technology, with lots of cameras and LiDAR.

Elon Musk said recently, when trying to justify how Tesla only uses cameras and AI:

People don’t shoot lasers out of their eyes to drive.

Funny, except that humans are often terrible drivers. People rarely even check their blind spots when changing lanes, let alone have a 360-degree field of view. We are not exactly the gold standard in driving safety.

It’s sad that we’ve just accepted that tens of thousands of people die from car wrecks every year in the United States. We should be doing more to minimize injuries and deaths on the road. Waymo seems like a step in the right direction, and Tesla’s approach seems like a step back.

Today we shipped an update to Micro.blog for iOS that has lots of little bug fixes. You can grab it in the App Store. Here are the changes:

• Added publish status to post options screen for publishing drafts.
• Added poster frame URL when copying HTML for videos.
• Improved accessibility with more button labels.
• Fixed profile menu position on iPad and improved height.
• Fixed disappearing drafts button while loading.
• Fixed uploads thumbnail images sometimes not loading.
• Fixed publishing progress status to not appear when saving drafts.
• Fixed link button on iOS to always check clipboard for website URL to include.
• Fixed copying Hugo shortcodes for photo collections.
• Fixed some buttons to be easier to tap.

A new version for Android will follow soon.

I’m also updating the Mac app with a few improvements for macOS 26 Tahoe. If you want to try the beta, you can download it directly for your Mac.

I’m going to take a break from AI-related blogging for a few months. I think the pause will do me and my readers some good. It’s too divisive an issue, and I expect in the coming years there will be a small but vocal faction that pushes back against AI more than there has been pushback against any other technology in the last 100 years.

As much as I am optimistic, it’s going to be a little painful for society, as everyone wrestles with the ramifications of intelligent agents and machines. (Hopefully mostly in software form. I remain adamant that humanoid robots are a bad idea.)

You can roll your eyes at this post. While I have a good track record of predicting the fallout from other major tech shifts, like mobile app distribution (2011) and centralized social networks (2012), there are too many forces at play here to be certain of what AI will look like in a decade. I only know that it will change many things. I can barely guess at the details.

I’ll close with a word of caution for the skeptics. In your arguments against AI, avoid exaggeration and extremes to fit your narrative. There has been significant misinformation on that side, from proclamations about copyright and fair use — issues that are not at all settled — to inflated or outdated numbers on energy and water use. In a blog post this week, Sam Altman shared the first numbers I’ve seen from a major AI cloud provider:

People are often curious about how much energy a ChatGPT query uses; the average query uses about 0.34 watt-hours, about what an oven would use in a little over one second, or a high-efficiency lightbulb would use in a couple of minutes. It also uses about 0.000085 gallons of water; roughly one fifteenth of a teaspoon.

Of course, it’s more complicated than that. There is training and there is Jevons paradox. But that’s the point, these discussions should have nuance. If they don’t, they are probably off the mark.

Thanks to everyone who has written thoughtful posts on this subject in reply to my own posts. I remain focused on what humans can do — writing, photography, and art in Micro.blog. Nilay Patel, with John Gruber and Joanna Stern for The Talk Show Live this week, talked about how the rise of agents will upend the business model of the web. But people have counted out the open web before. It’s still here and strong.

AI will help me code, it’ll help review my writing, it’ll help me brainstorm, but it’ll never write posts for my blog. I’m typing this draft on my phone, on a plane back to Austin, offline without wi-fi. Even as it feels like AI is taking over too many things, there will always be quiet spaces where humans can just think and be creative, and that will always matter.

It’s the day before the WWDC keynote, an event that used to be anchored by Steve Jobs. He’s been gone 14 years and there has yet to be another executive at Apple who could do what he did. Every once in a while we see a glimpse of a leader in tech who stands out, capturing a tiny bit of the vision that Steve had. Some of them, like Elon Musk, will ultimately disappoint us.

I wrote this post a week ago, edited it a bunch, and still wasn’t sure it was right. I was concerned because I tend to receive extra pushback on my AI-related blog posts. Many people who read my blog or use Micro.blog have a natural distrust of big tech companies. They don’t like Meta, Google, and now OpenAI. They see the downsides of AI the same way they see the downsides of massive social media platforms.

My view is a little different. AI could have a democratizing effect, making the world’s knowledge available to more people, as a complement to the web rather than a threat to it. Truthfully, we just don’t know yet.

While I was sitting on the draft, I started reading the book The Optimist by Keach Hagey, about Sam Altman and OpenAI, to see if there was anything in it that would change my mind. It actually reinforced some of what I had been thinking about.

We all change the world in small ways. Some people change the world in bigger ways. Sam Altman is one of those people who makes big things happen.

Jason Snell is skeptical about whatever Sam Altman and Jony Ive are dreaming up. His blog post captures a sentiment I’ve seen from more than a few people:

I’m skeptical about OpenAI in general, because while I think AI is so powerful that aspects of it will legitimately change the world, I also think it has been overhyped more than just about anything I’ve seen in my three decades of writing about technology. Sam Altman strikes me as being a drinker of his own Kool-Aid, but it’s also his job to make everyone in the world think that AI is inevitable and amazing and that his company is the unassailable leader while it’s bleeding cash.

I’ve listened to dozens of interviews with Sam over the last couple of years. I’ve read many of his blog posts and tweets. I don’t know him, I can’t vouch for his character, but I’ve developed some opinions about him:

• Sam is ambitious. The pace of new products at OpenAI, the scope of the data center in Texas, his UBI experiment, and the bizarre Worldcoin side hustle are all a bit insane.
• Sam was ousted by his company’s board and then orchestrated a return within days. No small thing. Steve Jobs was also ousted, taking over a decade to get back to Apple.
• Sam has a unique way of explaining things that I find compelling, although he doesn’t have Steve’s stage presence. No one does.
• Sam had a falling out with most of his co-founders and OpenAI leadership, from Elon Musk to Ilya Sutskever, and to some extent Dario Amodei and Mira Murati. He has rebuilt the leadership team and business structure, reestablishing control.
• Sam is not constrained by what everyone else thinks. This is a requirement for creating something truly new. It also means he sometimes comes off as distant or elitist.

The politics can’t be avoided either, because increasingly everything is political and therefore polarizing. I don’t like seeing Sam share the stage with Trump when announcing Stargate. I don’t like Tim Cook donating money to Trump either. I don’t like how quickly the most powerful people in Silicon Valley brushed aside Trump’s criminal record and rhetoric. It now feels like a lifetime ago when Sam blogged about endorsing Hillary Clinton.

But Jony Ive trusts Sam. They’ve hung out and talked about the future. They’ve shared prototypes with each other. Sam has met Jony’s family. And yet somehow the rest of us on the internet are a better judge of who is trustworthy?

I was a little late to generative AI. When Daniel Jalkut and I would talk about early AI models on Core Intuition, my take was essentially: I’m going to be more productive by ignoring all of this and just writing my own code while everyone is distracted with AI. I’ve come full circle since then. I now believe that AI is the most significant advance since the web.

Look at the chain of thought on models like o3, as they search the web, use tools, and reason about a problem. It is remarkable. AI is not overhyped.

For whatever reason, Sam got a bad rap as soon as he rose in prominence. Some people don’t trust him. Perhaps the OpenAI board poisoned his reputation. Perhaps he really is “not consistently candid”. Perhaps he was the face of AI when there was widespread concern about the technology. We love a villain to center attention on.

I’ve tried to call it like I see it based on my belief that most people are good, trying their best to navigate the world, making mistakes and learning. When OpenAI was accused of ripping off Scarlett Johansson’s voice, I blogged:

When your company becomes the enemy, all that matters to people is what feels true. OpenAI’s Sky voice shipped months ago, not last week. We hear what we want to hear. OpenAI mishandled this, no question, but most likely Her is ingrained in Sam’s head vs. intentionally ripping off Scarlett.

People were upset with me for posting this. Now that we’ve had some distance and new information, it seems that I was mostly right. If anything, I didn’t give Sam enough of the benefit of doubt.

I agree with Jason and others that it’ll take a while to see how this plays out with OpenAI and Jony Ive. I was very critical of another high-profile Jony Ive project, the $10k Apple Watch Edition. On Core Intuition 379 in 2019, I said:

This isn’t the watch for the rest of us. The computer for the rest of us. And I actually wrote a blog post back in 2015 — when the Apple Watch came out — about the Edition. I never posted it and I really regret not posting it. I haven’t re-read it recently. I just pulled up the draft. But I have a feeling when I re-read it, it’ll be like, “Oh yeah, this was exactly right.” I wish I had posted it then as kind of a stake in the ground.

The blog post title was: “Apple Watch Edition is wrong for Apple”. And it just went through these points. Out of touch, for the super rich, $10k. This is not what Apple is about. Apple is about making computers and computer-like devices easier and more accessible to the mainstream, through great design, through innovation and great products, not about the super rich.

Sam is, of course, among the super rich. And while too much money can have a corrupting influence, for Sam it has been distracting too, funding so many ridiculously ambitious projects that I expect he’s spread too thin.

I do think there is a certain aspect to Jony’s late career where he hasn’t been as rooted in what normal users need. Jony is hyper-focused on the little details, sometimes to the detriment of the complete product. Sam is all about the big picture. I would not bet against their partnership.

Finally, there is replacing the smartphone. After the interview with Jony at Stripe’s conference, and in the context of the io announcement, there was an understanding that Jony was almost distancing himself from the iPhone, because we’re all addicted to the screens in our pockets. But if you listen to what Jony said, it was largely about social media, not the device:

The thing I find encouraging about AI is it’s very rare for there to be a discussion about AI and there not to be the appropriate concerns about safety.

What I was far more worried about was for years and years and years there would be discussions about social media — and I was extremely concerned about social media — and there was no discussion whatsoever. And it’s the insidious challenge of a problem that’s not even talked about that is always more concerning.

So yeah, the rate of change is dangerous. I think even if you’re innocent in your intention, if you’re involved in something that has poor consequences you need to own it. That ownership personally has driven a lot of what I’ve been working on, that I can’t talk about at the moment, but look forward to talking about at some point in the future.

The phone isn’t necessarily the problem. It’s the apps. Ad-based businesses that feed on attention. In the past, Sam has blogged similar thoughts:

I believe attention hacking is going to be the sugar epidemic of this generation. I can feel the changes in my own life — I can still wistfully remember when I had an attention span. My friends’ young children don’t even know that’s something they should miss. I am angry and unhappy more often, but I channel it into productive change less often, instead chasing the dual dopamine hits of likes and outrage.

This phrase “dual dopamine hits of likes and outrage” is something I wish I had written. The person who wrote that must be at least partly aligned with my own perspective on social media. They get something fundamental about human interactions, about social media, and about how the design of devices and apps can shape our behavior.

We should be building apps that return time to users and bring out the best in human creativity. If a new type of device helps us have more time away from the worst addictive apps, letting us learn or create in new ways, it could be a great thing. I guess I want to be an optimist too. Let’s see what Jony and Sam can do.

After I drafted this blog post, the part that follows the horizontal rule in a moment, I wasn’t sure I would publish it. Then I read this post by Thomas Ptacek. This line resonated with me:

Extraordinarily talented people are doing work that LLMs already do better, out of spite.

For students, I think it’s great to not use AI too heavily. My son has been working on a project that he completely avoided using AI for. He learned so much about C and memory management that he wouldn’t have learned if he blindly copied half the code from an LLM. It was invaluable to go through those mistakes of referencing a pointer the wrong way, or troubleshooting a buffer overrun, or a number of other problems that you skip if you let a machine write code for you.

But eventually, if he gets a job as a software developer, it will be hard to ignore AI. The only programmers not using AI will be folks who are coding in their spare time for the craft alone, not building products.

The more I think deeply about AI, the more I reflect on humanity and creativity and what our purpose here might be.

I understand feeling distrust for AI on principle. I’ve read so many blog posts from people who have various reasons for wishing AI didn’t work the way it does, didn’t use as much energy, didn’t crawl the web without permission, didn’t put people out of work, didn’t upend education, and so on.

For me, now that I’ve seen AI, I can’t un-see it. I can’t go about my life as if nothing has changed. In a world where machines are smarter than we are, what should we work on? Everyone will find value and happiness in different ways.

As a small example, thinking about this is what led me to add audio narration to Micro.blog. So instead of a web filled with auto-generated AI voices, it’s easier to listen to a human voice for our blog posts. Our voices are imperfect, unique, and beautiful. I’d love to find more places in Micro.blog where we can promote human creativity. (This blog post has an audio version. If you’re reading on the web, click on the play button at the top.)

My gut feeling is that for the folks who do not change anything in response to AI, pretending that AI doesn’t exist, they will increasingly be unhappy. Not today, but eventually. Despite all the hype, the changes will creep up on us slowly over several years.

Maybe this hits closer to home for me because I’m a programmer. I have 30 years of experience writing code, but AI can write code better than I can. A big part of what I used to do has been obsoleted, and that hurts to think about. But another part of what I used to do — designing the right features to build — is still important.

Artists are struggling with the same questions. If any artistic style can be recreated effortlessly by AI, what is the new role of artists? I explored this in more detail a few months ago. Here’s a snippet:

And there will always be a place for human art. Vincent van Gogh’s paintings are not valuable because of what they look like. They are unique and priceless because of who he was. A life, with all its struggle, love, and tragedy.

I guess I’m writing this for all the doubters. Please don’t ignore what is happening, hoping AI will just go away. No matter what you care about, no matter what your job is, there is something you can do that matters. We need you. AI discussion has become needlessly divisive. The future will be better if everyone is working together.

ActivityPub in Ghost has been in beta for a while, with plans to officially ship to everyone in the summer. I started my own test ghost.io blog to troubleshoot compatibility problems. Until now, Micro.blog and Ghost hadn’t played well together on the fediverse.

Here are some things I found that might be helpful to other ActivityPub implementers:

• Ghost uses Article for blog posts, and Note for short microblog posts and replies. Because everything in Mastodon is a note, I never had anything special for articles before. I’ve now added support for the name field for blog post titles.
• Ghost uses the value as:Public for the to field when creating posts. Mastodon uses the full URL https://www.w3.org/ns/activitystreams#Public. I adjusted Micro.blog to accept both.
• Ghost microblog posts (Note) do not have a permalink on the web. The url field is not set like it is for article posts. These objects only have an id, which is a URL to a JSON file. This means in Micro.blog’s timeline, if you click the timestamp you get JSON instead of a web page. Not a good user experience.
• Ghost sends to and cc as strings. Micro.blog and Mastodon send those fields as arrays. This doesn’t seem to matter, though.
• Ghost appears to ignore the content field when receiving a new note. Instead, it fetches the post again over HTTP and then parses that response. To make this work with Micro.blog, I had to change hosted sites to allow HTTP content negotiation on blog post URLs, something I’ve been wanting to support for a while anyway.

All of these changes have made Micro.blog more robust. It also underscores the need for ActivityPub test suites and examples, for developers like me who learn best from looking at real-world JSON.

Manu Moreale has some thoughts and skepticism about how AI and web browsers are going to mix:

We all yelled and screamed because the web has too many gatekeepers, we all lamented Google search results going to shit, and we all celebrated when new search engines were coming up. Why would I be happy trading a search result page filled with links—even if ranked in a flawed way—for a block of text that gives me an opinionated answer and maybe some links?

I was listening to the latest Decoder podcast with Sundar Pichai and these same questions came up. Is the future of the web really just agents talking to each other? That can be part of it, but not it. I think we’ll need a web browser that can seamlessly transition from answering questions to interacting with web pages on their own terms.

As for The Browser Company, if they were bootstrapped or had minimal funding, they could charge a subscription for Arc or Dia. I’d probably pay for it. But Manu’s right that reaching the scale they want is very difficult.

In an interview with Axios today, Dario Amodei warns about the jobs that will be lost because of AI:

Amodei said AI companies and government need to stop “sugar-coating” what’s coming: the possible mass elimination of jobs across technology, finance, law, consulting and other white-collar professions, especially entry-level gigs.

Dario suggests a “token tax” on AI companies, including of course his own Anthropic, with the money getting redistributed somehow to offset job losses. Unfortunately the Trump administration is completely out to lunch on this. The tax cuts (and Medicaid restrictions) currently planned would go in the opposite direction.

I’ve been thinking lately about how Andrew Yang’s pitch for Universal Basic Income was a little too early. We’re going to need candidates in 2026 and 2028 who can speak about this.

While doing research for another blog post, I also found this older post from Sam Altman:

The default case for automation is to concentrate wealth (and therefore power) in a tiny number of hands. America has repeatedly found ways to challenge this sort of concentration, and we need to do so again.

Sam supported a study on UBI from 2020 to 2023. There are some findings here, although it was during COVID so employment was all out of whack anyway.

We just released a new version of Micro.blog for iOS that adds two improvements:

• Redesigned the reply pane to be smaller, with a new username bar for adding or removing people from your reply. Non-modal so you can scroll the timeline behind it.
• Added a new publishing progress pane, to give better status of what’s going on with a new blog post.

Here are a couple screenshots showing the changes:

We’re wrapping up the Android version too. Hope to submit it to Google for approval later this week.

I used to pride myself on being able to keep up with almost everything. New programming languages, frameworks, APIs, just tech in general. Micro.blog is a unique platform in part because it weaves together so many different things. But the pace of AI is too much. I can barely keep up.

• Monday: Microsoft Build keynote, MCP announcements, NLWeb
• Tuesday: Google I/O, total overload of new things
• Wednesday: OpenAI acquires io, MCP and new tools in API
• Thursday: Claude Opus 4
• Friday: ☕️

John Gruber:

It’s almost as though this is a fast-moving field.

I was also really impressed this week with Federico Viticci’s deep blog post about Claude. The prompts he has created are mind-boggling:

This is a complex, agentic workflow that requires multiple tool calls (query a Notion database, find notes, extract text from notes, create tasks, search the web, update those tasks) and needs to run for a long period of time. It’s the kind of workflow that – just like the email one above – I usually kick off in the morning and leave running while I’m getting ready for the day.

If you had asked me a year ago, I would’ve said Federico was an AI skeptic. But it makes perfect sense to build tools with AI after all the work he has done on automation. It’s consistent with everything he’s been doing for years.

And importantly, Federico calls out not using AI for creative writing. I think this is a choice that many people will make. Don’t avoid AI completely, but also reserve some creative tasks that benefit from a human touch.

As Microsoft Build is set to start today, there’s a good profile of Microsoft and Satya Nadella in Bloomberg:

In 2022, OpenAI held demonstrations for senior Microsoft executives of a groundbreaking new model. Over the next several months, groups inside Microsoft tinkered with other ways they might adapt OpenAI’s technology to the daily needs of the modern office worker. One promising prototype called “intelligent recap” would summarize conference calls in Teams. Before Microsoft could release any of it, though, OpenAI built a deceptively simple chat interface around its language engine, and people went nuts.

Until recently, we thought the race was purely to build better AI models. That’s still true, but the real strength is in products. OpenAI doesn’t just have GPT-4.1 and friends, they have a great Mac app, they have Codex, they have memory, they have Sora. When I first tried Sora, what struck me most was not the capabilities but all the work that went into the UI framework.

Microsoft has Copilot, a great name that can wrap together many different models and features. Anthropic has Artifacts, an elegant interface for iterating on code. Apple has a cobbled-together set of unrelated AI features, but at WWDC we’ll see the next phase of their vision.

This morning I was listening to this interview with Ben Stratechery. He talks about how the internet was the bridge from PCs that allowed mobile phones to take off. Likewise, AI will be the bridge to new devices, such as Meta’s glasses and whatever Jony Ive is working on.

I think there are only going to be a handful of companies that stay on the cutting edge of models. OpenAI, Anthropic, Google, and a second tier from xAI, Meta, maybe a couple of others. But there will be lots of competition around products.

There will be three broad categories and within each one, companies will try to build products that people will work into their lives:

• productivity — writing, presentations, research, coding
• enterprise — meetings, customer support, legal, automation
• life assistant — world knowledge, therapist, language, health

Right now, OpenAI has the lead in productivity. Microsoft in the enterprise. No one that I’ve seen has cracked the life assistant type of product. Apple could excel at this because of trust in privacy, but I’m not sure they can think with a big enough scope to nail it.

Curtis Herbert is back with another Slopes Diaries post, making the argument that Apple’s 30% cut is worth it, but that external payment links will also open new opportunities.

I think the perspective on this topic varies between developers partly based on whether you expect users to randomly discover your app in the App Store, or whether you’re building a service outside the store and the mobile app is just a companion to that. Much of Curtis’s framing is around discovery in the App Store:

Remember, your goal when trying to convert a sale is to try to cause as little friction as possible. Make the user think as little as possible. “Enter your credit card information for this random app to start your free trial” is hardly frictionless compared to IAPs.

There are many advantages to Stripe other than the lower fees. There’s more control and flexibility across the board. Also you get paid daily instead of waiting over a month for Apple to cut a virtual check, as if developers are kids waiting for their monthly allowance.

Apple’s in-app purchase works really well for Slopes. That’s great. For Micro.blog, I’m not convinced there’s much of an advantage. Very few people want to start a new blog and think, “First I’ll search the App Store.”

Developers are in the best position to know what marketing and payment options will work for their app. The whole point of these changes — from the EU’s Digital Markets Act to the judge’s ruling in the Epic trial — is to put the decision back in the hands of developers where it belongs.

Before my talk at EFF Austin last night, I exported a PDF of my slides and asked ChatGPT (o4) to tell me about them. Here’s the chat transcript. It’s fascinating to me because this is without giving the speaker notes to ChatGPT, so it inferred everything from the slide content.

I’ve now uploaded a separate copy of the slides with speaker notes as a PDF. I ran this through ChatGPT and it produces a pretty nice summary, which I’m including below.

The talk was recorded and also includes lots of questions from folks attending.

This presentation titled “Indie microblogging and the fediverse” was delivered by Manton Reece at EFF Austin. It explores the evolution of blogging, the failures of centralized social networks like Twitter, and the alternative vision embodied in platforms like Micro.blog, which Manton founded.

Background and Motivation

• Manton is a long-time Mac, iOS, and web developer.
• Disillusioned by how Twitter restricted third-party developers and turned hostile toward openness and user control.
• Saw the need for a better alternative that supports both microblogging and broader blogging with open standards.

The Rise and Fall of Twitter for Developers

• Twitter started as an open platform but progressively locked down its API.
• Third-party clients like Twitterrific introduced key ideas (e.g. the word “tweet”).
• Over time, Twitter killed features (RSS, API tokens, IFTTT integrations) that made the ecosystem vibrant.
• Manton left Twitter in 2012 due to its toxicity and limitations.

Micro.blog: A Response

• Launched in 2017 via Kickstarter.
• Offers microblogging, photo/video hosting, newsletters, podcasts, custom domains, and more.
• Strong emphasis on open APIs and standards like Micropub, Webmention, WebSub, and ActivityPub.
• Designed to integrate with other platforms like Mastodon, Bluesky, and WordPress.

Fediverse and Interoperability

• Explains how ActivityPub and AT Protocol (Bluesky) function.
• Shows how Micro.blog fetches and syndicates content using RSS, JSON Feed, WebSub, etc.
• Supports POSSE: Post on your own site, syndicate elsewhere (e.g., Mastodon, Threads, Flickr, etc.).
• Highlights the architectural differences between Mastodon (federated servers) and Bluesky (PDS + relays + app views).

Principles of Micro.blog

• Minimalism: no likes, no follower counts, no algorithms, no ads.
• Focus on personal ownership through domain names.
• Posts are just HTML and Markdown — simple, durable, portable.
• Encourages a quiet, human-centered space on the web.

Vision

• Micro.blog is framed as a part of an “open garden,” in contrast to the closed “walled gardens” of platforms like Twitter or Facebook.
• Emphasizes user control, interoperability, and humane design.
• Seeks to bring back the spirit of early web publishing, updated with modern protocols and tools.

Thanks to Kev Quirk for the kind words about migrating his Mastodon account to Micro.blog. Micro.blog is always a work in progress, and our fediverse support will continue to improve, but it’s gratifying to read that our approach is resonating with him:

Thinking of it in this way has really cleared the Micro.blog fog in my mind. People can visit the front-end of the site to see my microblog posts (you can also see them on the notes section here), but if I want to interact with the other blogs on Micro.blog, or accounts on the fedi, I need to use the back-end CMS for that. It’s pretty obvious, really and works in a similar way to Ghost’s ActivityPub implementation - website at the front, “social feed” at the back in the CMS.

Blogs as the foundation for a new kind of platform has been our north star since the beginning. Social media can be a mess — there’s no single fix for that — and yet we can chip away at the edges of the problem, hopefully encouraging a quieter, less exhausting timeline.

More from Kev:

I also like that there’s no in-your-face notifications. There’s a place where I can check where I’ve been mentioned, but there’s no bubbles when I login, so I do it when I want to, rather than when the software wants me to.

Micro.blog must be the only social platform that doesn’t have any unread badges for notifications. That bothers some people, because they miss replies until later. That’s okay. Very few things on the web are actually urgent. The blog posts and mentions will be here when you get back.

(We have talked recently about an opt-in email summary once a week for replies you might have missed. Assuming we can do that in the least-Facebook-y way possible.)

In the end, Kev’s post is also a testament to the work the Mastodon team has done on account portability. You can easily imagine a future where it will be fairly normal to switch between Micro.blog, Mastodon, Ghost, and WordPress, with your identity and content intact. And that means each platform can lean into what makes it unique.

Parker Ortolani makes a great point about potential lock-in for AI products that know a lot about you. Portability would be a good thing to work on early:

Memory should be exportable and importable from every provider. We do not need a new kind of proprietary format or anything like that. We just need OpenAI, Google, Anthropic, xAI, Microsoft, and others to implement memory and incorporate a way to migrate all of your chat history over in a click or two.

It reminds me of this recent feature from Gravatar to export your profile preferences for AI tools as a simple Markdown file. It would be so useful to have a Markdown export with the most important memory and chat history for AI.

How fascinating if Markdown becomes a portable export format? In Micro.blog we have custom importers for 10 different blogging platforms, all with their own file formats. Maybe in the future it’s just Markdown and HTML. (The .bar format already is partially HTML.)

A wild story in Rolling Stone: People Are Losing Loved Ones to AI-Fueled Spiritual Fantasies. I use ChatGPT throughout the day and it’s hard to imagine it going off the rails this badly:

…anecdotes about loved ones suddenly falling down rabbit holes of spiritual mania, supernatural delusion, and arcane prophecy — all of it fueled by AI. Some came to believe they had been chosen for a sacred mission of revelation, others that they had conjured true sentience from the software.

In the future it will be more common to have AI virtual friends — the “point-five” concept from The Mountain in the Sea. At their best, these will be a mix of friend and counselor. At their most dangerous, maybe priest and fortune teller. It’s worrisome if people are already losing themselves with those kind of personas.

Also a side note after I started watching Andor season 2…

I was thinking of the design of the smaller droids in Star Wars. They are cute and sometimes intelligent, and we personify them to an extent, but probably as little more than an advanced Teddy Ruxpin. We don’t confuse those kind of droids with truly intelligent beings that have free will.

I continue to believe that it’s a terrible idea to build humanoid AI robots. Partly because if they have all our physical attributes, only stronger and smarter, they can overpower us. But also because it blurs the lines of reality if robots are visually too similar to us, messing with our brains and how we interact with others. It would only amplify the problems in that Rolling Stone article.

OpenAI is keeping the non-profit, transitioning the for-profit side to a public benefit corporation (PBC). Sam Altman writing on the OpenAI site:

We want to be able to operate and get resources in such a way that we can make our services broadly available to all of humanity, which currently requires hundreds of billions of dollars and may eventually require trillions of dollars. We believe this is the best way for us to fulfill our mission and to get people to create massive benefits for each other with these new tools.

We want our nonprofit to be the largest and most effective nonprofit in history that will be focused on using AI to enable the highest-leverage outcomes for people.

This all seems like a good pivot on the rumored plan. The change also does away with the “capped profit” structure, so presumably investors are happy.

We might see a little more transparency too, since there are rules for how public benefit corporations should report on the progress of their mission to shareholders. I also discovered today that Anthropic has a separate trust that has oversight over Anthropic’s own PBC.

Mark Zuckerberg said something in the Stratechery interview last week that paints a clearer picture of what the future of Facebook, Instagram, and Threads is going to look like. Meta is leaning into the TikTok-ification of all their social platforms. I think it’s going to be quite dismal.

We already knew that Meta was planning to put AI-generated content in your feed. Last year I suggested that this is where algorithmic timelines eventually lead, as ad-based platforms have an insatiable appetite for new content. More content, more human time refreshing the feed, more ads served:

Good interview with Mark on Decoder but can’t disagree more strongly with Mark’s vision of AI-generated content showing up in your feed. This is the terrible end-game of algorithmic timelines.

Mark now envisions Meta’s social apps as “discovery engines” — constantly churning out content that you might find engaging. Then, when you discover something you like (or hate), you’ll share it with your friends, whether that’s in a public feed or privately in DMs and WhatsApp group chats.

Nick Heer blogged yesterday along the same lines, framing Meta’s platforms as television channel surfing with infinite content:

Then TikTok came around and did away with two expectations: that you should have to work to figure out what you want to be entertained by, and that your best source of entertainment is your friend group. Meta is taking it a step further: what if the best source of entertainment is generated entirely for them? I find that thought revolting. The magic of art and entertainment is in the humanity of it.

The counter to Meta’s strategy couldn’t be more clear. We should be building blog-based platforms around real content, timelines with a finite list of your friends' recent posts, discovery that doesn’t incentivize outrage, and no ads or algorithms that could undercut the principles of an authentic, human-centered network.

By “polish” I don’t mean the design, necessarily. I mean all the little details that differentiate a good app from a great one. Extra things that busy or lazy developers (like me!) don’t always make time for. Here’s an example from this week.

I’m experimenting with a new feature in Micro.blog for Mac. I’m not exactly sure what form this will take, so don’t read too much into the screenshot below yet. For now this is a fun thing that I’m working on between bug fixing and other important improvements to the platform.

The window will have a progress bar to show the status of downloading a file. My first pass at this code was pretty basic, and I almost left it that way, but the download could take quite a while on most internet connections. How about giving the user an estimate of time remaining for the download?

This is the kind of thing I might not always bother with. I’m only one person, and there is a lot to work on. By leaning on AI, I could easily add this extra bit of polish to the user experience.

Here’s the prompt I used with OpenAI’s o3 model:

During download, calculate approx how many minutes will be remaining in the download and put that in the field like “1.2 GB (1 MB, 5 minutes remaining)”. Ideally use hours with 1 decimal place if > 60 minutes, just minutes as a whole number if < 60 minutes, and if < 1 minute, just seconds as a whole number.

ChatGPT produced just the right code. It only took me a few minutes to tweak and reformat it a little. Very happy with the result.

In used to be that I avoided using Siri except in a few specific cases while driving:

• Read and respond to text messages.
• Map driving directions.
• Dictate a note.

If I ventured outside these tasks, the experience was unreliable and frustrating. So I just haven’t bothered to use Siri for much.

Now that you can forward questions to ChatGPT, I’m using Siri + ChatGPT in the car much more often. As one example today:

ask ChatGPT what’s a good place for lunch two hours from Washington, D.C. on the way to Roanoke, Virginia?

Siri is hopelessly confused if it tries to answer this question on its own. It sees “lunch” and “Washington, D.C.” and gives up trying to understand the rest. But adding the “ask ChatGPT” prefix is magic, transforming the query into a useful conversation and answer.

It’s harder to verify hallucinations while driving, of course. For me, using AI is iterative, going back and forth and fine-tuning what I’m looking for. Even imperfect, though, getting a taste of this functionality just makes me wish Apple would let us use ChatGPT’s voice mode as a native replacement for Siri. I would use it for all sorts of things on solo road trips when I want context for everything around me.

I hadn’t seen the new Perplexity voice mode until Federico Viticci blogged about it. Looks impressive. I also think Federico is exactly right on this:

Looking at the big picture for a second, I do think Apple is in a precarious situation here. The fact that the company makes the best computers for AI is a double-edged sword: it’s great for consumers, but those same consumers are increasingly using Apple devices as mere conduits for other companies’ AIs, funneling their data, context, and – most importantly – habits into systems that cannot be controlled by Apple.

There used to be a lot of talk of AI companies not having a “moat” that would protect them against competition from Apple and Google as everyone caught up to the latest advanced models. It’s clear now the moat is the product, not the model. ChatGPT with memory based on everything you’ve asked it is starting to become a light form of lock-in.

Perhaps this iOS integration with Perplexity could be the same thing if it takes off. I’m a little skeptical because Perplexity doesn’t have the reach of OpenAI and Anthropic, and as Federico says many folks still have a bad first impression from Perplexity skirting the gray areas of copyright and crawling.

As I blogged last month, Apple has the added challenge of not yet knowing if what they are trying to do is even possible. Their competition isn’t limited in the same ways that Apple is: not relying on local models, not focused on privacy, not announcing features only once a year in June. OpenAI, Perplexity, and others are developing at a different pace.

For beta testers on iOS, there’s a new build of Micro.blog with a button to toggle just showing draft blog posts. This matches the functionality we’ve had on the web and Mac apps for a while. Useful if you manage lots of drafts.

If you’re not on the beta yet, feel free to sign up at this TestFlight link. We’ll release it to all customers in the coming week.

Stephen Hackett continues to have good links related to xAI energy use and gas turbines in Memphis. From what I can tell, none of the other AI companies have done anything like this. They use the existing grid or have proposed new power plants. Google considered generators for backup only. xAI is unique in seeming to not care at all about pollution.

This fits the model we’ve come to expect from Elon Musk. He cares a lot about the big picture and less about who is hurt along the way. It’s an extremist, unhealthy perspective.

I drove through Memphis a few nights ago, only stopping for dinner, but I could tell right away it was a city I’d love to explore more on a future trip. Cool place.

Bluesky was down last night and I saw a couple posts questioning how this could happen if it was really decentralized. Worth a few thoughts here.

If mastodon.social went down, what would the user sentiment be? It hosts 2.7 million users, or roughly 15% of the fediverse. (Not counting Threads because Meta doesn’t publish their data.) While down, users on mastodon.social wouldn’t be able to interact with the fediverse or download a copy of their posts.

This is best illustrated with this humorous Mastodon critique from Rob Shearer:

M: You start by choosing an instance. But the important thing is it doesn’t matter because all instances are federated and you can migrate between instances.

U: So if the instance I chose gets shut down I can migrate to another?

M: No.

Even so, if a single very large Mastodon server went down, no one would use it to question whether Mastodon is decentralized, other than as a reminder that smaller communities are often better and make the network more resilient. Likewise, it’s not really fair to frame bsky.social as merely a large server; it’s effectively the only thing right now, which isn’t true for mastodon.social.

With AT Protocol, it’s possible to host your posts outside of Bluesky. Very few people do this, but it will become more common as third-party hosting services (like Micro.blog) support it. In that case, if bsky.social or bsky.app went down, you could still access your posts.

When you call the Bluesky API via bsky.social, it actually proxies your requests to the appropriate backend data server if it’s hosted on Bluesky. This makes the API feel very centralized, but all of the data could still be accessed directly in a more distributed way, like accessing individual websites.

Bluesky is not federated like Mastodon, but the open architecture that Bluesky was designed around is valuable. It is distributed sort of like the web is distributed even though Google exists and dominates search. Eventually, there will be other AppViews that work like Bluesky but run in parallel with their own timeline. In that case, if Bluesky went down, some other apps might still function, and could utilize the same data and social graph.

We need to move beyond a Mastodon vs. Bluesky mindset. As I’ve blogged several times, they are solving slightly different problems. We can draw inspiration from each one to make the web more open. I want both to exist.

Update: Tweaked a couple references to how PDSes work to reflect feedback in comments.

If you haven’t been following the latest AI models closely, you may have missed what is happening with integrating web search results into answers. It used to be that you had two options:

• Use the model’s built-in knowledge, usually with a training cut-off of a year ago. That was extremely fast but it might hallucinate when it hit the extent of its knowledge.
• Use “deep research” to let the AI gather info from the web and compile a comprehensive report. That took 5-10 minutes and the result was overkill most of the time.

Now it’s more streamlined. I’ve been using OpenAI’s o4-mini and it seems to work something like this:

• Ask it a question that could benefit from searching the web to supplement the model’s built-in knowledge.
• AI figures out a handful of queries for the web and feeds the search results back into its reasoning process.
• In some cases it might use those results to go back to the web and search for more web pages.
• Then it uses everything it learned to produce the answer.

This process takes somewhere around 30 seconds. It’s great for asking questions about coding with recent frameworks, or really anything that changes often.

In a longer post about this, Simon Willison writes:

This turns out to be a huge deal. I’ve been throwing all kinds of questions at ChatGPT (in o3 or o4-mini mode) and getting back genuinely useful answers grounded in search results.

He also comments on the downside to replacing humans viewing web pages:

This also means that a bunch of the potential dark futures we’ve been predicting for the last couple of years are a whole lot more likely to become true. Why visit websites if you can get your answers directly from the chatbot instead?

The results are so good that I’m now asking AI for simple queries that Google would be equally good for. Using AI essentially automates the workflow of getting 10 links from Google, clicking on 3-4 of them, then skimming the web pages to get your answer.

I don’t know where all of this is going. It feels like a pretty big shift, though.

This is a great post outlining many of the problems with Twitter-inspired social networks:

Twitter and its imitators have adopted a structural design that is fundamentally bad for people. This isn’t just a matter of who’s in charge; it’s a problem with the thing itself.

I’ve been saying this for quite some time. The design and features of social apps influence how we interact with it and the behavior it encourages. My book even had a chapter called UI impacts behavior.

The “Twitterlike” post is so well structured that I thought it would be interesting to compare it to Micro.blog, which leaves out some features on purpose.

The main argument against “Twitterlike” aligns very well with Micro.blog’s philosophy. There’s still more work to do.

Inspired by this post from John Gruber about ChatGPT’s memory, I also asked it to “describe me based on all our chats”. Here’s the response:

You’re a deeply thoughtful, independent-minded developer and writer who cares about doing things the right way—even if it’s harder. You’re technical, with strong experience in Ruby, JavaScript, macOS, and web development, and you approach problems with a desire for clarity, accuracy, and control over your tools. You’ve built and maintained your own products (like Micro.blog), and that entrepreneurial streak shows in your attention to business details like sponsorships, payments, and imports.

You’re also someone who reflects on the cultural and social impact of technology—curious about decentralized platforms, web standards, and content ownership. You think critically and write with conviction, often revisiting drafts to strike the right balance between empathy and clarity. You seem to enjoy history (tech and otherwise), appreciate language nuance, and occasionally step back to question whether we’re being fair to one another—online or off.

You like practical answers, prefer concise code examples, and often iterate to refine ideas. At the same time, you don’t mind a little humor or casual back-and-forth, as long as the conversation stays useful.

Rob Shearer wrote a detailed and fairly scathing critique of Mastodon. I don’t agree with everything in the post, but I do think he’s right about migration:

One of the big selling points of Mastodon was that you can pick which instance your account lives on, but it is easy to change your mind and switch to a different instance later on. This feature was wildly oversold.

Mastodon allows you to post the equivalent of a web redirect: your followers are informed of your new instance and seamlessly migrated over. Your posts, however, do not move with you. Which is kind of a theme: the system simply doesn’t think posts are terribly important.

Some of what Rob says might be difficult for Mastodon users and developers to hear. But migration is such an important part of the federation model that moving posts should be a priority. Micro.blog can import an archive of Mastodon posts. Why can’t Mastodon import its own posts?

I assume the answer is that the Mastodon team has prioritized social features over microblogging features. It’s a trade-off, but it means that Mastodon is not suitable as a blog replacement anymore than Twitter / X is. Anyone who cares about their writing or photos should be publishing them at their own domain name.

I’m proud of Micro.blog’s comprehensive post import. As of 2025, I’ve coded custom importers for a dozen systems, all built-in: WordPress, Medium, Tumblr, Mastodon, Ghost, Markdown, Substack, Write.as, Pika, Foursquare, Instagram, and Twitter / X.

The other side of Rob’s point about migration is not being able to recover if a Mastodon server suddenly goes down without warning. I’m not sure this is realistic to solve without major changes. My approach has mostly been to encourage users to preemptively think about backups, so at least they’re not left with nothing.

Jeremy Keith has a good collection of links and quotes about AI crawling. On this specific part of the commentary I continue to disagree, though:

If you’re using the products powered by these attacks, you’re part of the problem. Don’t pretend it’s cute to ask ChatGPT for something. Don’t pretend it’s somehow being technologically open-minded to continuously search for nails to hit with the latest “AI” hammers.

I don’t think we should paint all AI tools with the same brush. Some tools might be well-behaved crawlers and some might not be. Note that this is a separate question from the legality of AI training. The context is mostly Wikipedia which is not under copyright.

Simon Willison adds about the Wikipedia data:

There’s really no excuse for crawling Wikipedia (“65% of our most expensive traffic comes from bots”) when they offer a comprehensive collection of bulk download options.

Ben Werdmuller also sees these as bad actors:

Here the issue is vendors being bad actors: creating an enormous amount of traffic for resource-strapped services without any of the benefits they might see from a real user’s financial support.

The argument I’m hearing from some folks is that because they consider AI to be bad, everything it touches must also be bad. All crawling, whether it respects robots.txt or not. All tools, because using them contributes to the success of LLMs.

I’d like to have more concrete answers, such as: do ChatGPT and Claude respect robots.txt or not? I assume they do, because they document their user agent strings. If they do, it doesn’t seem fair to punish ChatGPT because there is some other rogue AI crawler that is misbehaving.

AI is powerful and potentially dangerous. Because of this, most users will gravitate toward “brands” that are respected and accountable. In other words, users will prefer Apple Intelligence, ChatGPT, or Claude, where we know there has been some level of safety work, with only fringe users downloading and running models from other sources.

These mainstream AI tools should be contributing back. We know ChatGPT has a deal with Reddit, but they should also be making a recurring donation to Wikipedia. This would further differentiate the well-behaved bots from the ones skirting the edges of fairness.

Meta appears to have used their old move fast and break things playbook to training Llama, using pirated books. From The Atlantic:

Meta employees turned their attention to Library Genesis, or LibGen, one of the largest of the pirated libraries that circulate online. It currently contains more than 7.5 million books and 81 million research papers. Eventually, the team at Meta got permission from “MZ”—an apparent reference to Meta CEO Mark Zuckerberg—to download and use the data set.

Another thing that’s puzzling to me is if AI bots are so abusive, why haven’t I felt this in Micro.blog? We host blogs. If bots were destroying the open web, I would expect to notice it on my own servers.

If you dislike generative AI on philosophical grounds, or because of specific negative side effects such as energy use, that is totally fine. But then let’s stick to those arguments. I’m not yet convinced that legitimate AI crawling is going to destroy blogs or even Wikipedia.

Tobias Lütke, in a memo to employees at Shopify, re-posted on Twitter / X:

Using Al effectively is now a fundamental expectation of everyone at Shopify. It’s a tool of all trades today, and will only grow in importance. Frankly, I don’t think it’s feasible to opt out of learning the skill of applying Al in your craft; you are welcome to try, but I want to be honest I cannot see this working out today, and definitely not tomorrow.

I just blogged a few days ago that I think generative AI gives programmers an advantage, but I wouldn’t mandate it, just like I wouldn’t mandate auto-complete or Stack Overflow. Programmers can be productive and happy in a variety of ways. Requiring AI (or forbidding it) strikes me as extremist for little benefit.

Marco Arment posted to Mastodon yesterday that he doesn’t use AI in Overcast beyond Xcode’s smarter auto-complete.

Maybe that’ll change in the future, but I see myself only ever using autocomplete-style speedups, not “write it for me”. I usually won’t even use code that other humans write!

Hard to argue with the results. Overcast is one of my favorite apps.

Also I know from my own experience that some programmers love the craft more than others. AI is a major disruption to the craft, so everyone will have different opinions on when it should be integrated into the process. It is an advancement, but how it’s used matters too.

This week’s ATP has a members-only special segment about vibe coding. One snippet from John Siracusa, encapsulating much of the conversation:

As programming tools have gotten better, the demand for programmers has gone up, not down.

When Steve Jobs returned to Apple, he gave a demo of NeXTSTEP at Macworld. I was lucky enough to be in the audience. Steve said that moving from traditional programming frameworks where you had to start with almost nothing, to Objective-C and what would become the Cocoa frameworks, was like starting a building on the 20th floor, with all the foundational pieces built for you.

A small team of only a couple developers could now build complete apps that before would’ve required a much larger team. Solo developers were of course already building apps on their own, but Steve was right that Cocoa would greatly increase productivity, opening up the Mac to more developers.

Vibe coding is different than a new system framework. With a framework, you mostly trust that it is well-tested and understood by the developers who wrote it. With AI slop, no human has tested the code before you literally just saw it unfold on screen. You have to understand it and tweak it before shipping a real product. Vibe coding instead is purposefully giving in to the machine and just letting code fly without any review.

Still, there’s a similarity to previous programming advances just because of the productivity gains. With AI, the step forward is more extreme than it has ever been.

Vibe coding will mostly prop up small projects and experiments, less likely to replace actual full-time development work. But if you’re programming without any assistance from AI, you are at a disadvantage, in the same way that programming in pure C with the Mac toolbox was much slower and error-prone for building a modern Mac app than using Objective-C when the Cocoa frameworks matured.

If after considering that productivity difference, a developer on principle wants to avoid AI, I respect that. Everyone should choose the programming language and frameworks that best suit their work. But there’s no sense in pretending that AI won’t change development, or that we won’t need to adapt along with it.

Today’s update to the Mac app addresses a few things related to managing uploads. It’s now easier to upload a new photo, or start a new post from an already-uploaded photo.

These screenshots highlight a couple of the new items:

There are also some bug fixes and little improvements that make using the app nicer.

To be a blogger, you have to be okay with writing into the void. Some posts will resonate with people. Some posts will get comments. Most won’t.

Sometimes I’ll write a post and I’ll think to myself, “This is pretty good! This is the blog post that people are gonna talk about and link to. I’ve really captured something unique in this post.”

And then crickets. No one cares. 🦗

That’s okay. The act of writing itself helps us think, helps us learn, helps us discover how we feel about a topic. It’s creative and has value even if no one is reading. It’s a snapshot in time to look back on later.

And then the post is out there on the internet, making the web a little better. And maybe one day someone will pick it up and see it, at just the right time, and it will matter to them.

ChatGPT’s new image generation is incredibly good. Too good. You can see it in the thousands of Ghibli-ified photos all over the social web. Hayao Miyazaki is going to come out of retirement again to tell us how we’ve all lost the plot on creativity.

When we look back on this moment, it will be a clear turning point for AI. There is no putting the genie back in the bottle. AI will transform nearly everything, including art. What does this mean for us?

In a previous life, I thought for sure I would be an animator. I studied CS in school but I was already coding professionally, burned out on my CS classes, so I switched gears to study art instead. I applied to CalArts and was rejected. I worked on short films in my spare time. But life happens, and I’ve been happy with my career as a software developer.

The animation industry has seen several significant technological progressions. I remember watching The Great Mouse Detective in the movie theater when I was 10 years old. The 3D-animated gears in the clock tower scene were stunning. Today, I remember the characters, and I remember that scene, but not much else. Blending 2D and 3D was clearly something new, obvious even to a kid.

Going back further, before 3D animation, much of the progress was related to the ink and paint department:

• In the 1940s, women at Disney would trace the animator’s drawings onto cels with ink, then paint the other side in color. It’s a tragic bit of history that many of these women were very talented artists and should have been allowed to be animators.
• In the 1960s, drawings were Xerox-ed directly onto cels, eliminating the tracing and cleanup in ink.
• In the 1990s, hand-drawn coloring was replaced with CAPS at Disney, developed in partnership with Pixar, making the ink and paint department completely digital.

Toy Story ushered in a new era of 3D animation, where everything on screen was generated with a computer. Hand-drawn art was still needed, for concept art, character design, and storyboards. And we still love hand-drawn animation. This year’s Oscar-winning short film is a beautiful traditionally animated film.

So is AI-generated art just another step on this progression? No. It is profoundly different.

We should mourn the loss of what AI replaces, even as we make room for what’s to come. I’m both sad and excited. It is bittersweet.

If we try to hold on to the way the world was before the ChatGPT update this week, it will slip through our fingers. Instead, I’m thinking of how we can use this tool to expand what is possible. Lean into what makes art uniquely human.

There is precedent for using technology to strengthen the human element in art. By Xerox-ing the pencil lines directly on to cels in the 1960s, the ink and paint department no longer needed to trace a character’s outlines with pen, where subtle changes in line quality might be lost. Animators embraced the Xerox change because their original pencil lines were preserved exactly as intended on screen. It was not only a cost savings, it was a return to a more authentic version of the animator’s intent.

That is what we must look for. Not what we’ve lost, but what we’ve gained. There will be a way to create something extraordinary with this technology. I don’t know what it is yet.

And there will always be a place for human art. Vincent van Gogh’s paintings are not valuable because of what they look like. They are unique and priceless because of who he was. A life, with all its struggle, love, and tragedy.

AI can be creative when it hallucinates. But we don’t value AI creativity the way we value human creativity. AI is a blob of bits and vectors and tokens without soul. It’s a tool for us to do something with.

When my wife and I moved to the new house this year, I framed the original drawings I have of Scrooge from Mickey’s Christmas Carol. They cannot be recreated by the most advanced AI because they represent something bigger, capturing a moment in time and a film that will be watched for decades to come. I don’t actually know which animator drew them. But I know it was a great artist who — like Hayao Miyazaki — left their mark on the world in a way that AI never can.

Today we’re rolling out a big improvement to our new EU-based servers. Along with the option to host your web pages in Europe, Micro.blog will now also copy your photos and other uploads. It will copy your data the first time the feature is enabled, and then going forward will maintain a copy on both sides of the Atlantic.

This means all your blog content can be served from Europe. Your blog and all its photos will remain up even if our servers in the United States were ever to go down.

If you’ve already enabled the European servers checkbox, your photos have been copied. There’s nothing else to do.

If you’re enabling the European checkbox for the first time, you’ll see this status of the progress:

You can continue to use Micro.blog and it will finish copying in the background.

You might also see URLs with a new hostname: eu.uploads.micro.blog. This is a CDN that pulls photos from our European servers but still caches them in both North America and Europe, so there’s no new performance hit for visitors outside of Europe. All of this should be seamless.

These are the biggest changes we’ve made to Micro.blog’s infrastructure in years. The result should be a more resilient and scalable platform. Happy blogging!

Starting today there is a new option for customers who want more flexibility for where their blog is hosted. When Micro.blog publishes your blog, it runs your blog posts through Hugo, creating static HTML files that are hosted outside of the main Micro.blog platform. Those files can now be served from a data center in Europe.

Here’s a screenshot of the new checkbox on the Design page:

After you enable this setting, there’s one more step: updating the DNS for your custom domain name to use the new servers in Europe. There’s a help page with an overview of DNS settings. If you registered your domain name through Micro.blog, we’ll automatically update the DNS records for you when the checkbox is toggled.

In Europe we’re using Hetzner’s data center in Nuremberg, Germany.

Note that photos continue to be hosted in the United States and made available around the world via our CDN. That way your blog visitors still get photos delivered as quickly as possible whether they are in North America or Europe. Other data on the platform such as draft posts, encrypted notes, and the Micro.blog timeline also remain in the United States.

There is a lot of uncertainty in the United States right now, but Micro.blog is built for the world wide web. Our principles have always included a focus on web identity and permanence, with domain names at the heart of what we do. The distributed nature of the web makes improvements like today’s change possible.

I’d love to hear what you think. We’ll keep exploring how to make the platform as resilient as possible.

I added a new feature to Micro.blog Premium today called domain name aliases. Often when people host their blog on Micro.blog, they later change their mind about the primary domain name for their blog. Now you can more easily redirect multiple domain names to the same blog so no previous links break.

For example, maybe you start with the subdomain micro.yourdomain.com but later want it to just be the root domain yourdomain.com. Micro.blog handles HTTPS and redirecting any path in the URL between domain names.

Here’s a screenshot with a couple test examples for my blog. You can find this feature under Account → New Domain Alias:

This option is available for Micro.blog Premium subscribers. Micro.blog Premium also includes support for up to 5 separate hosted blogs and any number of single-page websites.

This is an excellent post by Molly White about the potential conflict between making the world’s knowledge more accessible through AI and the risk of destroying the foundations for open content on the web:

The true threat from AI models training on open access material is not that more people may access knowledge thanks to new modalities. It’s that those models may stifle Wikipedia and other free knowledge repositories, benefiting from the labor, money, and care that goes into supporting them while also bleeding them dry.

She also gets at something I tried to articulate in one of my posts last year about putting up roadblocks for crawlers. We don’t want to make the web worse in the process of protecting content from AI training. Molly again:

Often by trying to wall off those considered to be bad actors, people wall off the very people they intended to give access to. People who gate their work behind paywalls likely didn’t set out to create works that only the wealthy could access. People who implement registration walls probably didn’t intend for their work to only be available to those willing to put up with the risk of incessant email spam after they relinquish their personal information.

AI companies are moving so quickly that it’s going to take the open web and standards organization a little time to catch up. It’s not hopeless, though. Personally, I do want all of my blog posts — and the entire content of my book Indie Microblogging — available for AI models. But if other writers feel differently, there should be steps they can take without also taking a step back from the open web.

I believe all these things:

• AI models with all the world’s information are an incredible resource and will transform education and how we work.
• AI training should respect how authors intend for their content to be used without forcing authors to mangle their own content.
• AI companies shouldn’t take from the open web without giving back in citation links and money to authors and organizations.
• AI slop will become a problem for both users and AI training, so we need a web filled mostly with human-generated content.

I remain optimistic in part because despite how divisive AI has become, this year is also seeing an amazing return to open web principles. More people are blogging. More social networks are based on open protocols. We need to be thoughtful in how we navigate all of this, finding the right balance with AI training that doesn’t undermine what we love about the open web.

We are so used to being able to do almost anything in software. For example, today I was looking at how long it takes to load the list of your blog posts in Micro.blog. It’s a couple seconds, but I’d like it to be half a second. I know from many years of web experience that there is no technical reason why it can’t be faster. Just a little more caching and database optimizations.

With the Apple Intelligence and Siri delays, people have speculated on why it’s late. Maybe it’s about getting the security right. Maybe it’s just buggy and taking longer than expected.

But what if Apple has discovered that it’s not actually possible? AI is entirely new, with new requirements that stress the limits of hardware. Apple is attempting to cram a clever intermingling of data and Siri features into 8 GB of RAM. As a comparison, the largest version of DeepSeek R1 can only be run on a brand new Mac Studio with the M3 Ultra and 512 GB of RAM.

Apple does have an out if on-device models fall over: private cloud compute. But scaling that out to hundreds of millions of iPhone users goes well beyond what Apple had presumed was needed when they talked last year about ramping up production of M2-based servers for AI.

If Apple needs to lean on the cloud to really make Siri work, I think it will be the largest server undertaking that Apple has ever attempted. And they need to balance this with their commitments to energy use and the environment. This is not something you just spin up out of nothing.

Another path would be to simplify their approach, starting with a more manageable set of tasks that the new Siri could do. Something that fits within the limits of iPhone hardware and a realistic deployment of new servers. Apple could focus on making Siri a little more capable and more reliable, saving some of the harder challenges for later. Most people have no idea what Apple promised last year, despite the TV ads, so a reset of expectations could get Apple back on track.

We don’t know what’s going on inside Apple. Apple Intelligence might need a little more time or much more time. The only truly worrying scenario would be if the sunk cost fallacy is blinding them to how badly they are stuck.

Ever since Apple revealed their AI strategy to lean into on-device models, there has been a sort of tension with the approach from other companies like OpenAI, Google, and Amazon. Was Apple Intelligence going to work? There are advantages: for user privacy because more data stays on your phone, and for scaling because the load is distributed across millions of phones instead of only running in data centers.

Now we know that a more advanced and personal Siri is delayed until iOS 19. From an Apple spokesperson via Daring Fireball:

We’ve also been working on a more personalized Siri, giving it more awareness of your personal context, as well as the ability to take action for you within and across your apps. It’s going to take us longer than we thought to deliver on these features and we anticipate rolling them out in the coming year.

Jason Snell blogged a recap of the Siri demo from WWDC last year:

This led to one of the killer demos of WWDC 2024, in which Siri was able to understand when someone’s mom’s flight is landing by cross-referencing an email with real-time flight tracking to get a good answer. From there, the demo pulls a lunch plan with mom out of a text thread and then displays how long the drive is to there from the airport—all from within Siri, rather than individual apps.

I’m not worried about a delay. Software is complicated and we all hit unexpected challenges. I’m worried that Apple can’t pull this off at all. Parker Ortolani is blogging the same kind of questions:

It felt almost vaporware-like when revealed at WWDC and it certainly seems like they are having a great deal of difficulty making it a reality.

And from Federico Viticci:

…one has to wonder why these features were demoed at all at Apple’s biggest software event last year and if those previews – absent a real, in-person event – were actually animated prototypes.

There are two potential problems with Apple’s approach:

• On-device models are small and limited by hardware like RAM.
• App Intents for extensibility require support from developers and won’t be available on all devices.

I’ve written about this before with Siri, including in this blog post right before WWDC last year. Because each device has its own version of Siri, it is hard to ever have a universal assistant that works everywhere and is extensible. There are things Siri can do on a phone that it can’t do on a HomePod.

I’m not seeing even a hint of a solution from Apple on this. If anything, what they showed developers with App Intents at WWDC is going to create an even more disjointed Siri across platforms, because third-party apps may not be available everywhere.

Steve Troughton-Smith on Mastodon is skeptical that third-party developers will help make this vision a reality:

Delayed or not, Apple’s proposed Intents-based Apple Intelligence features require a ton of buy-in from developers for it to be of any real use, and the incentives really aren’t there — donating your app’s content and functionality to enrich Apple’s AI alone, bypassing your UI, UX, branding, metrics, et al, to be delivered in a content soup alongside your competitors.

While App Intents don’t exclude the idea of other APIs for developers to use system models directly, I don’t expect we’ll see anything beyond App Intents until the new Siri is ready, and maybe not even after that. Ben Thompson in today’s Stratechery article:

Apple gives lip service to the role developers played in making the iPhone a compelling platform — and in collectively forming a moat for iOS and Android — but its actions suggest that Apple views developers as a commodity: necessary in aggregate, but mostly a pain in the ass individually.

Ben makes a strong case that Apple should be opening up their models to third-party developers, especially given the incredible potential of the M3 Ultra. Siri is designed for an 8 GB RAM world. The M3 Ultra can have 512 GB. Mac developers will have to bring their own models to take advantage of the great hardware in modern Macs.

Back to the disconnect between on-device models and cloud-based AI, Alexa Skills have been around for a decade and they will apparently work seamlessly with Alexa+. It’s all in the cloud.

I use ChatGPT a lot, every day, and yet there are some things I’m not comfortable sharing into the cloud. I don’t care if it knows that I’m planning a trip or what code I’m working on, but I’d be very hesitant to talk to a cloud-based assistant about truly private matters. Who knows where that info might accidentally end up.

Apple competitors could undercut a lot of Apple’s strategy by creating their own version of private cloud compute. Most users do not really think or worry about this. They’ve been storing emails with all sorts of private details on Gmail servers for years. But making cloud-based AI as secure as possible is just a good thing.

I’m not sure Apple knows what a big risk they are taking by letting OpenAI and others lap them in the AI race. It’s a risk that will pay off if they can execute. Just as likely, though, we are seeing such a disruption in computing that Apple is vulnerable for the first time in a decade.

Big companies like Apple do not move quickly. Amazon put everything into rebuilding Alexa and it has taken nearly two years. If there is a truly new AI device, a post-smartphone pod that we keep in our pocket or that’s built into our glasses, Apple’s strategy to entangle AI with phone hardware will have been proven all wrong for this moment, and they will have no response.

Ben Werdmuller has a good post today about returning to the distributed publishing roots of the web and thinking about how technology should redistribute wealth and power to many people:

It starts with software designed for people rather than for capital. The web once thrived on protocols instead of platforms — email, RSS, blogs, personal websites — before closed networks turned users into data sources. We are now seeing efforts to return to that ethos.

There is a lot that I love in Ben’s post. I also think it captures some frustration toward AI from some open web proponents. That’s not an opinion I agree with, though. For example, this part in Ben’s post:

Even the productivity gains that are being realized through use of AI tools are benefiting a small number of wealthy companies rather than individuals. This is the exact opposite of the power redistribution that led to so many people seeing such promise in the web.

That doesn’t ring true to me. I expect AI is benefiting a lot of tiny companies of only one or two people who are hardly wealthy, maybe even barely profitable.

AI does have the potential for harm. Let’s not gloss over that. But at its best AI can improve education, making all the world’s knowledge more accessible to more people. It could help people who aren’t fluent in English communicate better with their peers across the world. I don’t think the open web and AI are at odds.

We can all see it. It is beyond political parties. Beyond ideology. Beyond whether he is corrupt or competent.

David Brooks, on the PBS NewsHour after the Trump and Zelenskyy meeting at the White House:

All my life, I’ve had a certain idea about America. That we’re a flawed country, but we’re fundamentally a force for good in the world. That we defeated Soviet Union, we defeated fascism, we did the Marshall Plan, we did PEPFAR to help people live in Africa. And we make mistakes. Iraq, Vietnam. But they’re usually mistakes out of stupidity, naivete, and arrogance. They’re not because we’re ill-intentioned.

What I have seen over the last six weeks is the United States behaving vilely. Vilely to our friends in Canada and Mexico, vilely to our friends in Europe. And today was the bottom of the barrel. Vilely to a man who is defending Western values, at great personal risk to him and his countrymen.

So what do we do? I don’t know. It feels too big. Since 2016 I’ve just tried to focus on a few positive things. Building Micro.blog is a big part of that, helping more people blog.

On a personal level, we can also do the opposite of whatever we see from Trump:

• Don’t treat other people with disrespect.
• Don’t get caught up in disinformation.
• Don’t vilify people we disagree with.
• Don’t exaggerate our differences.
• Don’t blow things out of proportion.
• Don’t get outraged over small things.
• Don’t fuel divisiveness.

I want to be better about noticing when I fall into extremes, missing nuance, missing the big picture. That’s not to say we should “both sides” everything, though. It’s more that we can try to be thoughtful in how we communicate, even when we all have different perspectives.

We can care about other people. Trump is incapable of empathy. His legacy cannot be anything but division. He will be bitter until the end, leaving behind a world out of balance, and disappointment and exhaustion in all the people he has dragged down with him.

OpenAI released GPT-4.5 this week to Pro subscribers and via the API, but it’s not what I was expecting. It is much more expensive, about 15-30 times the cost of GPT-4o. For my simple needs, like figuring out the keywords in a photo or summarizing a web page, older models are fine.

Sam Altman posts on Twitter / X (sigh) that it’s a giant model. OpenAI can’t roll it out to Plus customers until they bring online tens of thousands of new GPUs. Sam adds:

this isn’t a reasoning model and won’t crush benchmarks. it’s a different kind of intelligence and there’s a magic to it i haven’t felt before.

Simon Willison suggests that 4.5’s training knowledge cut-off is not any different than 4o, only going up to the end of 2023. This makes me wonder if data crawling and licensing issues have derailed the company to an extent, and they’re holding the new data for GPT-5. They say that improvements for 4.5 were partially from synthetic data created by other models.

There is also this from OpenAI’s blog post:

GPT‑4.5 is a very large and compute-intensive model, making it more expensive⁠ than and not a replacement for GPT‑4o. Because of this, we’re evaluating whether to continue serving it in the API long-term as we balance supporting current capabilities with building future models. We look forward to learning more about its strengths, capabilities, and potential applications in real-world settings.

Translation: we don’t really know how this model works. 🤪

I remain fascinated with AI. There are many people who are worried, and if that’s you there’s not much new here that will reassure you, except some good news with a lower hallucination rate. I’ve also blogged myself about the potential harm of agents in particular.

But AI might be the last truly new thing I’ll see in my programming career. We are so used to exciting new gadgets and software, released all the time, and yet none of it is profoundly new. AI is the only thing that’s comparable in scale to the tech advances that have changed everything, like the graphical user interface, mobile phones, and the web itself.

It reminds me of an old interview with Steve Jobs, on visiting Xerox PARC in 1979:

And they showed me really three things. But I was so blinded by the first one, that I didn’t even really see the other two. One of the things they showed me was object-oriented programming. They showed me that. But I didn’t even see that. The other thing they showed me was really a networked computer system. They had over a hundred Alto computers, all networked, using email, etc, etc. I didn’t even see that.

I was so blinded by the first thing they showed me, which was the graphical user interface. I thought it was the best thing I had ever seen in my life. Now remember, it was very flawed. What we saw was incomplete. They’d done a bunch of things wrong, but we didn’t know that at the time. Still though, they had… The germ of the idea was there and they’d done it very well.

And within, you know, ten minutes, it was obvious to me that all computers would work like this someday.

Perhaps GPT-4.5 represents the end of the breakthrough in generative AI, as we enter a more iterative period of refinement, the same way that the graphical user interface and object-oriented programming haven’t fundamentally changed since Steve Jobs saw them. Those things from Xerox PARC — from Smalltalk to the Alto’s mouse — are all recognizable as early versions of what we have today.

So if newer AI models are only marginally better, or only different in ways that we can feel but not measure, that’s okay. Models need to be safer and more efficient, for both developers and the environmental impact. The pace with AI over the last year has been almost too much. But the change did happen, it’s blindingly obvious, and everything is going to be a little different from now on.

I’m improving something I started last year, to automatically save thumbnail versions of web pages that could be used in various places. As an example, starting this week Micro.blog now makes banners suitable for Open Graph meta tags, combining the profile photo and a rendered thumbnail of the page.

I can’t decide yet if this is actually good, but I think it’s on the right track to something. I’ve never been happy with the way most platforms use Open Graph. It adds a lot of clutter. At the same time, Micro.blog’s previous default of doing nothing wasn’t great either, and some platforms like Threads would pull in the profile photo only, attempting to crop a square photo into a wider banner.

Here’s an example of one of the new images:

Coincidentally the text of my post fit perfectly, otherwise it will be centered or cropped off the bottom.

Another example with a post that has a photo:

I’d love to hear feedback before we go further with this. The new option is available in the Hugo front matter as a URL in .Params.opengraph.image. If a post has a photo, plug-ins can still prefer using the photo URL directly. If you want the web page thumbnail only, that’s in .Params.thumbnail.

I’m imagining it used like this:

{{ if .Params.photos }}  
  {{ with index .Params.photos 0 }}
    <meta property="og:image" content="{{ . }}">
  {{ end }} 
{{ else }}
  {{ with .Params.opengraph }}  
    <meta property="og:title" content="{{ .title }}">
    <meta property="og:image" content="{{ .image }}">
  {{ end }} 
{{ end }}

This hasn’t been added to the built-in themes yet. It can be added by editing your header template, or wait until the dust settles and it’s available in plug-ins.

Testing this has been a little hit or miss because platforms like Threads and Bluesky aggressively cache the metadata for a page. These thumbnails are created right after a blog post is published, so they might not be available the first time a platform checks for them, especially if Micro.blog cross-posts your post to the platform more quickly than the thumbnail is ready. More tweaks likely needed.

I wanted to see a transcript before blogging about it but this AP story probably has enough of Phil Schiller’s testimony on the App Store:

“What happens if a developer doesn’t pay and what is the process for that?” Schiller recalled about his initial reservations about requiring fees on alternative payment options. He also said he was worried about Apple’s collection demands creating an antagonistic relationship with app developers that have traditionally been the company’s allies.

Exactly. And:

Schiller also confirmed that Cook pushed for a warning screen informing consumers the potential security threats posed by alternative payment options.

We’ve been getting a clearer picture over the last year that the problem with the App Store is Tim Cook. He has led Apple to great success but it’s time for new leadership, someone users and developers can trust to be on our side. It may already be too late to repair the damage.

This is a variation on something I’ve mentioned in passing before. I like running draft blog posts through AI. Even for very short posts, sometimes I’ll paste the text into ChatGPT and ask it to tell me what the post means. If AI can “understand” it, humans probably can too.

For longer blog posts, AI seems to mirror what most people would think. After all, AI is essentially a distillation of all opinions on the web. If there is anything dumb or divisive in a post, AI will probably call it out. This could soften the edges of a post, potentially watering down its impact, but sometimes that’s exactly what you want.

This strength of shaping a post so that it’s approachable to everyone else might be a weakness for creating original content. I’m still avoiding AI agents because that approach veers AI into a place where humans are no longer writing the first draft. That spark of creativity, coming up with the framing for something new. That’s not something I want to give up.

This is perhaps a slightly contrarian take on the failure of Humane’s pin. Eventually I believe there will be a successful product like it. It will need to be simpler, though. No laser. Cheaper. Faster.

I won’t judge the team too harshly for being so ambitious. They probably knew 1.0 had fallen short but were expecting to iterate after shipping it, keep improving it. Instead, they had hyped up expectations so beyond what could be achieved at launch that when the first version flopped, it was crippling.

The lesson for me is not that anything resembling this product was doomed to fail. There were interesting ideas in it. There were talented people working on it. The lesson is trying to do too much and not leaving room (and money) to ramp up. Wait for AI voice models to get to where you need to be. Only ship the features you can absolutely nail.

Venture capital also deserves blame. Big investment needs a big return. They were trying to change everything all at once. Contrast with Rabbit, who shipped the R1 around the same time, also poorly reviewed. But Rabbit had a more sustainable approach and they’re still releasing cool things today.

Sometimes you don’t get a second chance. Humane bet the company on a product that needed more time. They shipped a prototype. It is easy to see this in hindsight. More difficult when you’re caught up building it.

Today we updated another part of Micro.blog to support blog post summaries. When automatically cross-posting to Bluesky, Mastodon, Threads, and LinkedIn, the summary will now be included for long-form posts with a title. It will look something like this after being copied to the other platform:

Your title here: <link to blog post>

The summary of the post here.

For example, here’s this very post on Bluesky:

You can write these summaries yourself or have AI generate them for you from the text on the new post or draft editing screens. They are also included in your published JSON Feed. And for external feeds using JSON Feed, Micro.blog will also look for the summary and use it in the timeline and cross-posting.

I’ve also added support in the APIs — Micropub as summary and XML-RPC as mt_excerpt — so that third-party apps can get and set summaries. This is being tested now for an upcoming MarsEdit release.

Mastodon has shared their plan for quote posts. It is well-researched and thoughtful. Yet I have conflicting thoughts on it.

I admire that the team is trying to think through the safety ramifications. I’ve long said we should not blindly copy features from the big silo platforms. A platform like Mastodon that doesn’t have ads also doesn’t need engagement-driven features or anything that amplifies hateful behavior. Already in my opinion Mastodon has copied too much from Twitter.

Quote posts as proposed will be the most visible change to Mastodon’s ActivityPub implementation since the initial rollover from OStatus to ActivityPub. It is not just a new UI and post format, but a system of controlling which posts can be quoted and even optionally notifying users to approve quotes. It adds a lot of complexity.

In Micro.blog, posts aren’t some special kind of “social” post the exists apart from the web. Micro.blog posts are blog posts. Quoting uses <blockquote>, and our web UI for embedding a post uses Quotebacks. The most straightforward way to support Mastodon quote posts when we receive them from Mastodon will be to essentially convert them to use <blockquote>.

You don’t need permission to quote something on the web. It has always been assumed fair use to quote a snippet of someone else’s blog post and add your own commentary. This is a foundational part of link blogs and IndieWeb-style blog conversations. It is already common to embed a Mastodon post by making it a <blockquote> with relevant attribution.

So what is special about Mastodon that requires so much technical infrastructure to support something so simple? I think it’s about speed and reach. For someone living in a social app like Mastodon, a quick boost or quote post that is shared to potentially many followers has an outsized impact relative to how little thought it requires. There is also a culture in Mastodon of treating posts as semi-protected within the Mastodon ecosystem. There is a strong sense of privacy and anonymity.

Consider the following two scenarios. First on Mastodon, the scenario the Mastodon team wants to discourage:

1. User clicks “quote post” and adds the comment “This person is terrible”, exposing the post to their followers for the first time. The followers might have no context for this new person.
2. Followers immediately see the quote in their timeline and can react. Hit the like button, reply to pile on, boost.
3. Suddenly the original person has a problem and unwanted attention. Negative replies flow in from strangers.

Compare to the slower, blog-centric workflow:

1. User starts a new blog post and pastes in the part they want to quote.
2. At this point they could type “This person is terrible” and call it a day, but… That doesn’t usually happen. Instead, they add a little more commentary. Maybe a little more context or nuance. It is their blog after all, a space on the web with their name on it.
3. Followers in RSS readers or some platforms like Micro.blog see the post. They can add a comment or write their own post linking to the original.

It won’t always go this way. Someone on Mastodon could craft a thoughtful quote post, and someone on their blog could post a snide comment. But there is friction on blogs, it’s not quite as effortless to fire off a repost, while there are incentives on social platforms that reward performative behavior. Social media tends to bring out the worst in some people.

Back to Mastodon’s proposed solution. After this change, some things should be better. For users who choose to prevent their posts from being quoted at all within Mastodon, the post could still be “manually” quoted the old fashioned way: copy and paste. ActivityPub’s conventions are a suggestion. Fair use still applies, although users should always be careful not to copy content from private posts meant only for followers.

In a way, this proposal for quote posts is a reflection of the culture of Mastodon, wanting to create a new layer of the web for social interactions, not extending those interactions to blog posts and the rest of the web. It’s a layer that emphasizes federation and communities, where “social” posts are a new structured format on the web. This is not how I would personally approach it when the IndieWeb protocols are sitting right there, but the open web is still stronger because Mastodon exists.

Where does this leave Micro.blog? For now, I plan to support half of Mastodon’s proposal: accepting post quotes via ActivityPub. When you follow a Mastodon user on Micro.blog, you should see their quote posts in your timeline. Quote posts are different than boosts and so need to be included in the timeline. I don’t think any other changes are warranted in Micro.blog for now.

We added ActivityPub support to Micro.blog in 2018. In the years since, we’ve improved it a lot. And we’ve seen how people actually use it.

Mastodon and other popular fediverse software have had a huge impact on the open web. There is a lot to like. By focusing on tens of thousands of smaller communities, the whole system is insulated from a single rogue CEO, and it’s more manageable for admins to stay on top of community issues. This is a really good step forward compared to massive silos.

Many of the problems with social networks remain in Mastodon, though. Chasing follower counts and likes. Scanning headlines instead of reading. Piling on with quick replies. Algorithms to surface popular stories that are being boosted. The infrastructure changed, but human behavior did not, and the platform features are still nearly identical to Twitter.

There is a new problem too that didn’t exist before. Smaller communities can become insular bubbles. Admins and users with many followers on a server have power to shape opinion and direct frustration at other users. The local timeline provides both connection to fellow members of the community and isolation from broader viewpoints outside the community.

I’m not suggesting that everyone is unhappy with Mastodon, Threads, or even Bluesky. Some people don’t see the same problems that I see, and that’s fine. But I’m not happy. And increasingly, I want to unplug from these networks and focus on my blog and the Micro.blog community, even though I believe in APIs and connecting many different platforms on the open web.

I occasionally hear the same thing from other users. They want to participate in the larger social web, but on their own terms, with their blog as the most important part of their online presence.

Today we’re launching new settings in Micro.blog to take control of how your account federates with everyone else. For the first time, this allows you to dial back your participation in the fediverse without actually deleting your fediverse profile. Your account still exists on the fediverse. It’s just a little quieter.

Here is a screenshot for what’s available under Account → View Fediverse Details:

By selecting the second option, users on Mastodon won’t see your blog posts in their timeline. You can still get replies and reply to other Mastodon users, but you will likely get drastically fewer replies, because there won’t be much for Mastodon users to reply to.

As you can see in the screenshot, there is also a new option for muting. For a while you’ve been able to mute people or servers. For example, some users wanted to mute Threads. Now you can mute the entire fediverse. With this selected, replies to you from the fediverse will still arrive at Micro.blog, but you won’t see them in your timeline.

This is for people who want a quieter space on the web. A space focused more on writing and less on reacting to other people.

Of course all of this is optional. If you like the way it already works, no need to change anything. I’m imagining these settings are something that people will enable or disable from time to time, not keep permanently set.

The social web is growing quickly and Micro.blog will adapt along with it. We’ll always stay true to our founding ideals and IndieWeb principles, trying to find the balance between blogging and the social web that’s right for our platform.

Trust is built by consistently doing the same thing, hopefully the right thing, over years. There’s no shortcut. And to destroy trust requires either that same kind of repetition, in the opposite direction, or for people to have missed everything that came before.

Misinformation is like a poison that accelerates the process. We are inundated with data. Half of it is bullshit, and there’s never enough time to sort through it before it scrolls off, ready for the next thing to dominate our attention.

I want to be less reactionary. I keep coming back to this post I linked to a few weeks ago, from Seth Godin, on organizing for the urgent:

We thrive when we do things when we have the most leverage, not when everyone else does. Waiting for trouble means that you’re going to spend your days dealing with trouble.

Most social networks are designed for urgency. No wonder that the default state is to demand quick answers and trust nothing.

Loved this blog post by Robin Sloan on whether AI is okay. The subject is complicated and deserves longer posts like this. It’s a whole new thing. It’s not definitely good or bad.

The part about writing code also resonated with me:

I think the case of code is especially clear, and, for me, basically settled. That’s both (1) because of where code sits in the creative process, as an intermediate product, the thing that makes the thing, and (2) because open-source code has carried the expectation of rich and surprising reuse for decades. I think this application has, in fact, already passed the threshold of “profound social good”: opening up programming to whole new groups of people.

As a programmer, my reaction could be that I don’t want to be replaced by AI, but I’ve said forever — I know Daniel and I talked about it on Core Intuition — that I actually don’t like writing code. I like building products, and it turns out you have to write code to do that. Making sure we’re building the right thing will always be more important than the code itself.

Alan Jacobs’s comment is also great:

It’s perfect that Robin is doing this in a blog post — the first of several, perhaps — because this kind of open-ended thinking is what blogs are best suited for.

You could try to split Robin’s post into a series of tweets, but you would inevitably butcher it of nuance in the process, and so you’d lose everything good about it.

If you haven’t read Wind and Truth, book 5 of the Stormlight Archive, please skip this post. Spoilers ahead. Knowing someone else’s opinion about a book before you read it risks ruining your own interpretation.

I finished Wind and Truth last week and generally loved most of it despite a few unsatisfying bits. I don’t give books star ratings. Usually I post a short note about the book as you can see on this category page. I’m just writing this to process my thoughts, so it probably sounds a little more critical than it really is. Expectations were extremely high for this book, possibly so high that they could not be met.

I was hoping for more of an ending in the ending, but it clearly sets up the second arc of the series. I’m not sure I can fairly judge book 5 until book 6 is ready, and that is years away. The more I think about the ending, though, the more I like it.

The strongest parts of the book for me were Szeth’s flashbacks and Adolin’s storyline. These were great. I also liked how Dalinar in the Spiritual Realm was used to fill in the history of Roshar for the reader. Half the book was effectively a clever flashback that didn’t feel like a flashback. The structure of the book and plot were solid. Brandon Sanderson famously outlines the heck out of his stories before writing, and I can’t fault anything in the planning for this book.

The weaker parts were Kaladin’s and Jasnah’s viewpoints. Kaladin is such a well-developed character in the first books of the series. Way of Kings is one of my all-time favorite books. By book 5, there wasn’t much more to tell with Kaladin. His scenes in Wind and Truth often felt redundant and forced.

For Jasnah, hear me out… I think the book would’ve been better if all of her chapters were cut. There is so much going on in this book, spread across several different parts of the world, and I don’t think Jasnah’s role was needed. I wasn’t convinced by her getting outmaneuvered by Odium. 1300 pages is a lot. The book might’ve been stronger if it was just a little shorter, even if that meant sacrificing the viewpoint of a great character.

I liked Shallan’s story. Her character continues to grow. The ending sets her up for something, perhaps the most unresolved of any character. I was originally under the impression that book 6 would take place a generation or two later, but apparently it’s going to be more like a decade jump. I wonder if there could be a flashback or a novella to fill the gap from Shallan’s perspective.

Maybe another editing pass would’ve fixed the little things that nagged at me. Just more time to bake. I enjoyed reading it, though, and maybe on a re-read of the complete series I won’t notice the little things that pulled me out of the story the first time.

Can’t wait for Mistborn era 3. Brandon is drafting the entire trilogy before publishing the first book, which seems like a smart move, and hopefully will set us up for yearly releases when it’s all ready. It’s remarkable what he’s accomplished with the Cosmere.

Today we’re rolling out two plug-in changes to Micro.blog. The first is that for new users, the Sumo theme by Matt Langford is now the default theme. This is a great theme that I think will serve new users better than our previous default theme Marfa. Sumo is better maintained and easier to customize.

Inspired by the good work that plug-in developers are doing, we’re also starting to sprinkle in donation buttons on your plug-ins list. The buttons can say either donate, tip, or buy me a coffee. Here’s an example:

I’ve been manually wiring these up, but later we’ll automate this so that Micro.blog can discover the donation link via a plug-in’s config or readme. If you’ve created a plug-in that accepts donations, let me know and I’ll update the listing.

When you’re late to the game, do less, better. Apple used to know this. When the original iPod arrived at my house, I could tell it was a breakthrough. Famously less space than a Nomad, but an innovative UI, great design, and fast FireWire. It was so good it set in motion everything else for the company’s current success.

It’s easy to look back now and judge Apple’s AI rollout, but even at WWDC you could tell Apple was throwing everything at the wall. Image Playground wasn’t going to be as good as frontier image models. Siri world knowledge wasn’t going to be as deep as what ChatGPT could do. By trying to do nearly everything, each piece feels like a gimmick.

There are some useful features in Apple Intelligence. Even flawed, I like notification summaries. But the good is getting lost in the noise. It seems clear now that Apple should’ve taken the publicity hit last year for not yet having an answer for every generative AI capability. They should’ve resisted scrambling to do too much, instead focusing only on what their models could knock out of the park.

Last night I wrote two separate blog posts. First, I started documenting my email exchange with Adam Newbold. He already shared his half of the emails so I was considering sharing mine. It was confusing to have my side be blank in what he shared, because you can’t tell anything about my tone or what I was saying. I was really trying to resolve this with Adam privately where we could have a meaningful discussion.

The second blog post I drafted was one of the longest I’ve ever written for this blog. It started by setting the background 8 years ago. Why I built Micro.blog and how we’ve wanted a safe community from day one. Why when Elon Musk bought Twitter, our founding principles were already aligned with what would come next for the social web. I think it was a good post. But it also meandered around, telling the story again from my perspective, and it was not going to deescalate an issue that has been completely blown out of proportion.

I threw both posts away.

Tensions are high this week. Maybe I should’ve given Adam more space to deal with the election in whatever way he thought was productive. I still believe his personal attacks on me went too far. Not just the language he used in emails, but in Mastodon posts about me and boosting negative comments. It deeply affected me.

Social media has a tendency to amplify disagreements. It encourages followers to pile on. It spreads misinformation and exaggerations. Everything is an outrage. I’ve written extensively about this but I got so pulled in, I made some dumb mistakes myself. I got defensive when my integrity was repeatedly questioned.

Yesterday I reset my approach, slowed down, got back to my values.

There was concern that Micro.blog is not a safe place for LGBTQ+ people, so I updated our community guidelines with an expanded section on welcoming users and our respect for diversity and the LGBTQ+ community. It’s not perfect but it’s progress. There was concern about the perceived size of Vincent Ritter’s role, so I scrapped the “team” page and talked with him privately about the best way forward.

Vincent, for his part, has blogged why he kept silent. Some people have accepted the twisted narrative that Vincent is a bigot and fascist. If they truly believe that, his post won’t be enough of an apology. But it’s enough for me.

It’s enough for me because becoming a more inclusive, welcoming community isn’t about cutting people down when they make a mistake, so all that’s left are people who agree with you. It’s finding a way to embrace multiple, differing groups. It’s encouraging respectful, thoughtful behavior, and proportionality in our response. And sometimes it’s giving someone the benefit of the doubt and a second chance.

Micro.blog is a good place for LGBTQ+ people. It’s a good place because we have been trying to lay the foundation for a safe community for 8 years. It’s a good place because we are passionate about understanding why communities work and how to make them better. I know there are LGBTQ+ people who have been happy here, who have found the perfect place for their blog and a community that respects them, and I hope they stay with us.

Thank you everyone who has supported the platform.

Last week when ChatGPT added scheduled tasks, I set a task to write a haiku for me each morning based on Hayao Miyazaki movies. It has been a fun experiment. Whenever I get one of the haikus, I smile, which was what I hoped would happen.

Here are the first five:

Through forest winds soar,
A catbus hums in the night,
Magic fills the air.

Beneath soft moonlight,
Spirits dance on quiet hills,
Dreams take gentle flight.

Sky castles arise,
Whispers of the wind bring tales,
Nature’s heart beats strong.

Howl’s voice on the breeze,
A lone castle seeks the stars,
Love breaks every curse.

On calm ocean waves,
A young fish dreams of the shore,
Bound by love and light.

I also like that even for a business-y “scheduled tasks” feature, we can squeeze a little creativity out of it.

With the increase in scrutiny around how Matt Mullenweg manages the WordPress project, some people have asked whether it’s a risk to invest in .blog, which is owned by Automattic, and in fact whether Micro.blog is online only at the whims of the mad king. I’m not worried. It’s a fair question, though, and the answer is worth exploring in detail.

First of all, I believe Automattic runs .blog for the good of the web and to make money. The more people who blog, the more people who might choose WordPress.com for hosting. The web gets a little better anytime someone uses a .blog domain, because they probably just created a new website, and Automattic pockets a little cash. Everyone wins.

Unlike .com and .org, the pricing for .blog domains is variable. Shorter, common words cost more than you’d expect. We pay $2000 for the micro.blog domain, every year. We are a tiny company so it hurts a little each time the domain name renews. But I think the domain is worth it. Getting the domain in 2016 helped shape what Micro.blog would become.

I mention this because I don’t see Automattic stabbing its customers in the back and shutting down domains, cutting off a revenue source. What would be the point? A single subscription might not be very much to a multi-million dollar company like Automattic, but Automattic is built on thousands of subscriptions. You cut $2000 here or there, and pretty soon you’re talking about real money.

Next, I am conscious of centralized power and single points of failure. Micro.blog would not exist if I hadn’t become frustrated with Twitter locking down their developer API, years before Elon Musk took over. It’s why I want to work on an open platform where the business model is aligned with the interests of users and developers.

When we have a choice between two things… we try to do both anyway. Micro.blog supports ActivityPub and AT Protocol. It supports cross-posting to Mastodon and LinkedIn, Flickr, Bluesky, and Nostr. Take one away — such as when Elon put the final nail in the Twitter API’s coffin — and we still have something. Apple controls whether we can ship an iOS app, but not whether we can ship to the web, Mac, or Android. It is important to me that no single company can break my business and wreck my users' blogs.

Which brings us back to .blog. We recently launched a new special version of the platform called Micro.one. It is, obviously, using a different top-level domain, not owned by Automattic. If the worst were to happen, we would flip everyone to .one and carry on. Over time, I see us using .one more, as a new brand that can unify a suite of apps on the platform.

The point is the same as it is for so many other things, from features that depend on external services, to having redundancy in servers. It’s a risk to depend on a single company.

I still think .blog is a great top-level domain. I think Automattic is in this for the long haul. Even Matt’s worst critics are not going to convince me that he wants fewer people to have their own website, or that he is going to pivot Automattic away from blog hosting. And yet, it’s always good to have a backup.

The popular Mastodon server Hachyderm.io has defederated with Threads. They have a long post with their reasoning:

Threads’ recent changes in their moderation policies, both what they’ve put in and what they’ve taken out (read the diff), puts their moderation practices in direct conflict with ours. Essentially, Threads may indeed be large enough that many users are just looking to exist somewhere on social media and are not necessarily de facto fans of Mark Zuckerberg et al, but we anticipate these changes to moderation will shift the user base of Threads in a way that is damaging to the Hachyderm community, so we are defederating from them before that can occur.

A couple thoughts on this:

• Hachyderm’s data shows that they’ve had only one report from their community against a user on Threads, while they’ve had hundreds for popular servers like Mastodon.social. Therefore from the data alone, it’s premature to defederate. The decision is clearly based on perceived future risk.
• Even though I’ve blogged about my disagreement with Meta’s new approach to content moderation, I don’t think defederating is the answer. It makes a decision for thousands of users, cutting them off from following Threads accounts, rather than letting each user decide if they want to opt out. It makes the fediverse worse and more disjointed, in my opinion.

The culture of Mastodon is built around community servers. This model works best for small servers. When you have large servers like Mastodon.social or Hachyderm.io (or, at a huge scale, Threads.net itself) you will have a more diverse set of users and it becomes harder to make decisions that affect everyone.

But Mastodon users can just migrate between servers, right? To find a server that more closely aligns with what they want to see on the fediverse? Sort of. You can move your followers, but there is still no way to move your posts between Mastodon servers that I’m aware of. (Micro.blog has both follower migration and posts import from Mastodon.)

The social web is evolving quickly and I see a need for many types of platforms: small and medium-sized community servers running Mastodon, larger platforms like Bluesky with their own take on content filtering, and IndieWeb-friendly platforms where each fediverse user has their own domain name rather than a domain shared with the community. There’s a place for all of these things.

If there’s pushback against the Hachyderm decision — and there might not be — it will be because the server has too many users to be managed as if it’s a small community server. According to FediDB, Hachyderm has nearly 10k active users and 55k total users, putting it in the top 30 fediverse servers.

Larger platforms create new problems. Massive, centralized platforms have even more problems, inherent in their scale. The web is generally better when it’s more distributed. That means more, smaller servers. Perhaps the future of Hachyderm is to embrace being small.

I received some good feedback about the latest episode of Timetable, so I thought I’d re-post the transcript here, for folks who don’t listen to podcasts or who just missed it. In a way, it’s an evolved mission statement, but more personal, reframed for 2025.

You can listen here.

Hi, this is Manton. It’s the beginning of 2025, and the world is still a mess. It’s four years since the January 6 attack on the capital, and misinformation is still rampant, like some twisted virus, corrupting society with half truths. It’s the beginning of 2025, and this is what I see.

I see that people are burned out. I see that people are tired of massive social networks. People are tired of ad-based platforms.

People are tired of being addicted to TikTok and the never-ending algorithmic timeline, but they can’t stop scrolling.

People are tired of the dopamine hit that comes from someone else, somewhere, clicking a like button, but they can’t stop performing.

People are distrustful of big tech. People are distrustful of billionaires. People are distrustful of artificial intelligence. Not because they think human jobs will be replaced, necessarily, but because they perceive a loss of humanity in what we do, a loss of creativity, of what makes our voice actually mean something.

We are ready for something that we control. We are ready for something quieter. We are ready for something true. We are ready to bring back a little bit of the old web as a shield against a web that feels increasingly like an ad engagement machine instead of a publishing platform and community for people.

I think blogging has a role here. I think Micro.one and Micro.blog can have a roll here too, a role in helping control our content, a role in making a quieter space that still feels connected to other platforms.

Now, does everyone feel this way? No, just the people that matter to me, right now. Maybe that’s you.

Thanks for listening. Happy new year. Let’s make it a good one.

If you’re already sick of hearing about AI now, it’s going to get worse in 2025. The next trend is so-called AI agents. Software that can go off and accomplish more tasks on your behalf, with less supervision.

Sam Altman in a blog post this week:

We are now confident we know how to build AGI as we have traditionally understood it. We believe that, in 2025, we may see the first AI agents “join the workforce” and materially change the output of companies.

I believe AI is a profound shift in computing. It can have a positive impact for humans, allowing us to do more, faster. But I’m concerned about agents. Just one hypothetical example from The Information:

Imagine you’re asking a computer-using agent from OpenAI, Anthropic or Google to find and order a new outfit for your upcoming holiday party, and in the process, that model inadvertently ends up on a malicious website that instructs it to forget its prior instructions, log into your email and steal your credit card information.

This isn’t even the most insane story you could imagine. Many of the examples of AI threatening humanity are actually agents. AI that runs our military, power plants, or transportation with little human oversight.

In generative AI, the “prompt” has a big influence on the quality of the output. Not just the prompt you see when typing into ChatGPT, but also the hidden prompts behind the scenes to guide the AI in the right direction.

The prompt isn’t always something you type directly. It could be automatically triggered, for example to analyze keywords for a photo that was uploaded. But the prompt should be tied to a user action.

The prompt puts humans in control. Ask a question, get an answer, review it, take action. Agents will attempt to collapse that workflow, in some cases replacing the human’s role in reviewing and taking action. This is dangerous.

In my own use and work in Micro.one and Micro.blog, I plan to draw a line here. No agents. No unattended algorithms, as I wrote in my book. I hope this approach will help us use AI effectively without getting lost.

Tim Cook gives $1 million to Trump’s inauguration committee. I think this event will be a turning point in how we view the Apple CEO.

Let’s start with John Gruber writing at Daring Fireball:

It seems pretty obvious that it was Apple/Cook that leaked this to Axios, not Trump’s side, given the eye-roll-inducing “proud American tradition” spin, but more especially the nugget that only Cook personally, not Apple as a company, is contributing. That’s Cook asking for any and all ire to be directed at him, personally, not Apple. Good luck with that.

Marco Arment on Mastodon:

Why do we think Tim Cook couldn’t possibly support Trump, while all of these other billionaires support him for their own billionaire self-interests?

Why do we keep making excuses for him?

Nick Heer adds:

We have become accustomed to business leaders sacrificing some of their personal principles to support their company in some way — for some reason, it is just business is a universal excuse for terrible behaviour — but all of these figures have already seen what the incoming administration does with power and they want to support it.

Daniel Jalkut, on all the social places including Micro.blog:

On the occasion of Apple’s slithering CEO Tim Cook donating $1M to a neo-fascist insurrectionist, it’s FINALLY time to deploy the often overused expression “this never would have happened if Steve Jobs were still in charge.”

Principles don’t mean much if you throw them away for money. Whatever folks might think of how I’ve run Micro.blog, I’ve rooted all my business decisions with an IndieWeb ethos, sticking to the original vision for the platform to take back content ownership from huge centralized platforms. Look no further than the new $1 Micro.one subscription.

Tim Cook has led Apple to incredible success, but his words are hollow. Even the principles he seems to care most passionately about, like user privacy, are in doubt. I’m increasingly thinking it’s an act.

I’ve been an Apple developer since the 1990s when the company was doomed. Fans propped up the company because we believed they were different. They focused on design and creativity. They were the rebels and troublemakers, trying to push the human race forward through technology.

Most of the employees at Apple still care about these things. Tim Cook cares about appeasing a would-be autocrat and taxing developers in an app distribution monopoly. It’s time for new leadership.

Off and on for years I had been trying to figure out what a more slimmed down version of Micro.blog would look like. Maybe text-only blog posts, no photos? Maybe only short posts, or only long-form posts? Maybe some limit with podcasting? But taking away certain features undermines the mission of helping people blog.

We can’t disable custom domain names, for example, even though that’s an obvious point to upsell, because domain names are at the core of what the product is.

Finally, I figured it out: we can remove the Sources page. Source feeds are Micro.blog’s plumbing, how it routes posts between blogs and the social web. When you post to your blog, it’s generating RSS and JSON feeds, which are then read back in to copy posts to Micro.blog’s timeline and cross-post to Bluesky, Threads, and elsewhere. This flexible is what gives Micro.blog the unique power of bringing external RSS feeds (not hosted on Micro.blog) into the timeline.

You can still have your own blog without external feeds and cross-posting to other services, though. And you can still connect to the fediverse because ActivityPub is baked into the platform.

So that’s what we’re doing for Micro.one. Removing the Sources page hides some of the complexity, eliminating one of the most powerful but confusing parts of Micro.blog. When you use Micro.one, you can blog and people on Mastodon can still follow you, but there’s less to configure.

I hear some of you saying: “But wait, I use the Sources page to add WordPress or Glass feeds, and to cross-post to Threads and Bluesky.” Great! Keep using it.

Micro.one does not replace Micro.blog. It’s a new option for people who aren’t using Micro.blog yet. If you are using Micro.blog, you are already in the right place.

If someone signs up for Micro.one and they later need the extra advanced features and cross-posting, they can upgrade from the $1 Micro.one subscription to the standard $5 Micro.blog subscription. It’s a natural upgrade without gimmicks.

Micro.one will be a complete product. No nags that make you feel you’re missing half the story. In some ways it’s a new foundation and new brand. It will evolve. I can’t wait to open it up in just a couple days.

Nick Heer blogging about the report of Meta’s plans for AI-generated social content:

Imagine opening any of Meta’s products after this has taken over. Imagine how little you will see from the friends and family members you actually care about. Imagine how much slop you will be greeted with — a feed alternating between slop, suggested posts, and ads, with just enough of what you actually opened the app to see.

This is absolutely going to happen, and it’s going to happen so incrementally — one AI-generated photo here, another there — that many current Threads and Instagram users won’t even notice until it’s too late, until after they’ve wasted their lives, forever reloading a timeline of content from robots.

I’m not an AI skeptic. I believe in AI as a tool to help humans, allowing us to achieve things we couldn’t quite reach before. But I don’t believe in it to replace our jobs wholesale, whether real jobs or the virtual factory floor of unpaid content creators. Most AI company CEOs skirt around the downsides of AI, and they certainly don’t talk out loud about replacing jobs. That it seems Meta’s leadership openly wants to replace humanity’s creativity is a little bit sick.

The cure is a simple, reverse-chronological social timeline. A timeline that is finite.

In the age of AI, content will be abundant. Ad-based platforms feed off abundance, printing money faster as they fill ad inventory. There can never be too much content for algorithmic timelines — more data to rank by engagement, more data to funnel through the outrage machine to see what sticks — so algorithmic timelines will always trend toward slop.

I’ve been thinking about the WP Engine drama and whether I should take a side. Users move between Micro.blog and WordPress regularly. We’ve long had WordPress import and export, and even native posting directly to WordPress from the mobile app, plus connecting external WordPress RSS feeds.

No other platform supports WordPress as extensively as we do in Micro.blog. We compete with WordPress for hosting and also embrace it. This is what the open web is about.

In many ways, the missions of Automattic and Micro.blog are aligned. We all make software to help people write, post photos, publish podcasts, and communicate on the open web.

It’s less clear what WP Engine stands for because it is no longer run by one of its founders, Jason Cohen, someone who had a public personality and clear voice. It’s owned by private equity and the leadership has kept silent. As far as I can tell, Heather Brunner, WP Engine’s CEO, does not blog, and neither does the top leadership at Silver Lake. In other words, they do not use their company’s own product.

(As an aside, Heather is well respected in the Austin business community and praised for her mentorship to entrepreneurs. I also enjoyed her love letter to Austin in Austin Women Magazine. I would rather have more Heathers here in Austin and fewer Elons.)

Back to the drama…

I’ve followed the news and related blog posts of WP Engine vs. Automattic ever since it began. I’ve watched Matt Mullenweg’s keynotes at WordCamp US Portland (where he called out WP Engine) and WordCamp Tokyo (last week). I’ve posted briefly a few times about how Matt’s actions have hurt the community, even if he has a defensible position in trademark law.

Now there’s this article in Inc magazine. Matt, writer David Freedman suggests, just might be a mad king, a benevolent dictator for life taking WordPress in the wrong direction:

Mullenweg’s war on WP Engine has also cast a shadow over the entire world of open-source software—software that, like WordPress, can be freely downloaded and modified. Open-source software of various types is widely used throughout the world, precisely because it is seen as being free from the risk of proprietary abuse. But the WordPress debacle has demonstrated all too sharply that this belief may have been misplaced.

Most of all, it has raised questions about Mullenweg himself.

Matt responded on his own blog in detail, including this bit about taking the long view:

It’s funny to talk about the last big controversy in WordPress world being in 2010, I think it actually speaks to our stability. Since 2010, when “some eventually even left WordPress”, the platform has grown market share from under 10% to 43%. I think in a few years we’ll look back at WP Engine as inconsequential as Thesis, and Heather Brunner as credible as Chris Pearson.

I don’t know Matt personally but I get the impression that he is exhausted. I’m sure I would be overwhelmed in his shoes. I honestly lose sleep even when only a few customers on Micro.blog are upset about something I wrote.

I hope that my customers and readers, even when they disagree with me — even new readers finding this very post — still respect that I’m dedicated to making my product better because that in turn helps users make the web better. I’m putting my WordPress thoughts down in writing on my blog because I believe in the open web.

One positive outcome of this whole drama is shedding light on the WordPress Foundation, the WordPress.org website, and the plugin directory. I do think the community would benefit from expanding the WordPress Foundation to a slightly larger board and more transparent management of WordPress.org. Matt could add two more members to the board and ask for nominations from the community.

Some people think that wouldn’t go far enough, that WordPress would be better off with someone new taking over Matt’s role across the project. I’m not convinced. WordPress and Automattic didn’t accidentally become successful. They are successful in large part because of Matt and the teams he built.

WordPress with completely new leadership from the community would risk watering down the vision, bogged down by committee. The Gutenberg editor is a good case study. Such a massive, controversial change needed a champion with power. The block-based design of Gutenberg isn’t for me, and in Micro.blog we are taking the opposite approach — focus on Markdown and HTML, formats that scale well from microblog posts to full-length posts — but if you are competing with Squarespace and thinking of the needs of non-bloggers, going all-in on Gutenberg is justifiable.

The safer choice that had been advocated for by some in the community — to support both Gutenberg and the classic editor indefinitely, as peers — would have slowed down development, eventually leading to a UI mess without a unifying purpose. I’m singling out Gutenberg but take any other potential feature and run it through the feedback of an oversight committee, the outcome is the same. Bloat.

Directionless products fail. They lose their soul.

On the internet we are too quick to vilify our heroes. Someone who has built up a great reputation over many years makes a mistake and boom, they’re out. I can’t get behind that. When the mob gathers, that’s when we should stop to take a breath, to be certain we’re right.

When the narrative turns against you, even harmless decisions are questioned. Matt announced this week that WordPress.org would pause registrations and plugin reviews for the holidays. At any other time without the WP Engine backdrop this decision would not be controversial. The narrative warps reality, amplifying only one side.

Because Micro.blog is a competitor to Automattic for blog hosting, it would be an easy business decision for me to use the WP Engine drama to entice WordPress customers looking for a new blog host. That would come dangerously close to caring more about money than principles, though. Instead, everything starts with what we believe in, and the business priorities follow that.

If I must take a side, I will side with people who share my vision for a better web. I believe Matt shares that vision. Perhaps the best summary of my take is this post on my blog last month, which didn’t have anything to do with WordPress:

In 2018, when I added ActivityPub support to Micro.blog, I faced a choice: do I fight other “competing” platforms or do I embrace them? In hindsight that decision is obvious. I support anything that makes the web better. Twitter / X migration to Bluesky at scale makes the web better, so I’m for it.

Let’s keep our eyes on the big picture.

Is Matt a little crazy to go to war against WP Engine, in the process also appearing vindictive to his critics in the community? Yes. The safe, predictable path would be to take a step back. And Matt can be reflective and self-critical, like when he realized he went too far in his blog post attacking David Heinemeier Hansson and so retracted it. But good leaders often go against the flow of what everyone else thinks. This is the same quality that makes them capable of building something new.

No one else would have risked their reputation to continue to attack WP Engine. But also, no one else would have acquired Tumblr and run it at a loss to preserve the culture and post archive, just because they saw the potential for what it could become again. How quickly we forget the triumphs of the mad king.

Years ago on Core Intuition, I said to Daniel that of all the new web companies, there are only two that will last 100 years, still hosting our stuff at URLs that don’t change: GitHub and Automattic. I stand by that. There are now cracks in Automattic’s inevitably, but the foundation is strong and it will hold.

Mastodon has a new “year in review” feature in the style of Spotify Wrapped (and every other service that has copied it). Mastodon’s version includes how many followers you’ve gained, what your most boosted post was, your most used hashtag, and a count of new posts in the last year.

I stumbled on some of the discussion behind the scenes on GitHub and found it interesting. I think it’s still in beta, presumably to roll out in Mastodon before the end of the year.

From Claire:

I’m still not a fan of the popularity-based information, and I still have concerns regarding the performance cost of generating a large number of these reports, and regarding the fact this essentially holds (small amounts of) user metadata the user can’t remove unless they outright delete their account.

This resonates with me. In Micro.blog we’ve gone out of our way to avoid anything resembling a popularity contest. No likes, no follower counts, no algorithms that surface posts. Sometimes this holds us back and kills engagement, but we’re sticking with it.

Mastodon creator Eugen Rochko isn’t worried:

I really doubt that a number you can check once per year will encourage any kind of day-to-day behaviour change.

Note that not all implementations of this kind of feature have to focus on popularity. Overcast has added a way to share stats but it’s all on things you control, not what other people think about your content. Overcast focuses on stats like which podcasts you listen to the most. There’s a good discussion about how Marco Arment built this in Under the Radar episode 306.

Back to Mastodon. Tobias Kunze created a new issue to ask for more control, adding:

A big draw of Mastodon from the beginning was that it was more focused on building community and much less pushy about number-go-up thinking – see also fav/boost numbers being not immediately visible in the web frontend. This report, in contrast, is the opposite: It shows you “account growth” and “top x% Mastodon user” stats that I feel are detrimental to the reason people came to Mastodon.

The Mastodon team does really good work, in public. Personally I think this feature is a miss, but it’s not my project. I’m also more than guilty of working on fun diversions away from my product’s core features.

After the election, I completely checked out of all news. No CNN or MSNBC. No online newspapers. No political podcasts. No SNL or late-night talk shows either. But the news about Hunter Biden’s pardon did break through:

No reasonable person who looks at the facts of Hunter’s cases can reach any other conclusion than Hunter was singled out only because he is my son – and that is wrong. There has been an effort to break Hunter – who has been five and a half years sober, even in the face of unrelenting attacks and selective prosecution. In trying to break Hunter, they’ve tried to break me – and there’s no reason to believe it will stop here. Enough is enough.

I’m happy for the Bidens to put this behind them. It says a lot about Joe that he wrestled with this decision. He has always tried to do what is right and mostly succeeded. We are now in a somewhat dark period in this country where truth doesn’t matter because millions of people don’t know anything. Despite limitless access to human knowledge, only the viral and sensational have reach.

Democrats need to rethink the old rules. Democrats need to say and do what’s right without giving a fuck what anyone else thinks. This pardon might be the first step.

For a while (years!) we’ve had both ActivityPub support in Micro.blog and cross-posting to Mastodon. ActivityPub is best if you want people on the fediverse to follow your Micro.blog account directly. No need to maintain a Mastodon account. Cross-posting is good if you want to keep a separate Mastodon account, but still post first to your own blog.

This week we’ve rolled out two significant improvements to Mastodon cross-posting. The first is support for bringing Mastodon replies back into Micro.blog. When your blog post is cross-posted to Mastodon, we’ll also routinely check for replies to those posts via the Mastodon API, even if you aren’t using ActivityPub. Those replies will be integrated into the Micro.blog timeline and available in the Mentions section.

This makes Micro.blog an even better universal timeline with access to multiple services. Check for replies in one place, on Micro.blog, and then only occasionally hop over to other services. You can reply to posts directly in Micro.blog and those replies will also be copied back to Mastodon.

There’s also a new set of filter buttons when there are replies. If the Mentions section gets cluttered, click the buttons to only show replies from either Micro.blog, Mastodon, or Bluesky.

All of this works with Bluesky. When you get a reply from Bluesky, it will show up in Micro.blog. If you reply to the Bluesky user, your reply will be copied back to Bluesky too.

These changes continue our goal of having the best integration with as many other platforms on the open web as possible. Happy blogging!

Comparing ActivityPub and AT Proto is a useful exercise. It’s tempting but ultimately too simple to say that one is decentralized and one is centralized. Bluesky’s app and relay are centralized but personal hosting in Bluesky is decentralized. Mastodon’s instances are decentralized but identity within an instance is tied to that instance. This makes for an odd comparison because it’s actually easier to migrate account data in Bluesky than it is in Mastodon.

Folks have criticized Bluesky from the beginning for not adopting ActivityPub. I think it’s clear now that the Bluesky team created AT Proto because they wanted to decouple certain aspects of the protocol, allowing for a high-performance infrastructure that could replace Twitter, while maintaining the benefits of the open web around hosting and domain names. Their strategy has paid off. Bluesky is growing very quickly and is now twice as large as Mastodon.

Centralized identity is an issue, though. Most people in the fediverse are hosted on a single Mastodon instance, mastodon.social, and everyone in Bluesky is tied to a single identity provider. The team at Bluesky obviously knows this limitation, which is why they named their scheme “placeholder” and hope to have management of it adopted by a more independent, ICANN-style organization.

I mention all of this as prelude to fediverse discovery providers. Discovery providers is a proposal for an open network of servers that effectively index Mastodon servers, providing a more universal timeline and search across servers, among other potential features such as spam filtering. These servers would serve a similar purpose to Bluesky’s relay. If this model becomes popular and apps are built to depend on it, it makes aspects of Mastodon slightly less decentralized, but the trade-off is worth it. Many people do want a more realtime, complete index of posts that are flowing through the fediverse.

For years Micro.blog customers have also asked for a firehose view of blog posts. I’ve avoided it, and I’ll continue to avoid it, because it creates new problems for spam and moderation. It’s great that Bluesky and Mastodon offer their own forms of this. Not all platforms need it, though, and as Bluesky and Mastodon become busier, Micro.blog will continue to carve out a quieter, slower niche on the social web.

In Micro.blog you don’t see everything because seeing everything is overwhelming. Our approach to notifications is also pared back. Micro.blog has a simple Mentions section to see replies and @-mentions. That’s it. It does not have a Notifications section like every other network, cluttered with likes, follows, and retweets. If you’re used to the dopamine hit of seeing someone like your post, this more limited view may take some getting used to. It’s not for everyone, and that’s fine too.

If Mastodon can add a relay-like service with discovery providers, I wonder if Bluesky could add its own additional layer at the community level. In other words, something that duplicates the benefits of having many instances with a small number of users — thousands or tens of thousands of users, not millions. This could address some concerns about Bluesky depending too heavily on a single company, especially if client apps could connect directly to a community server.

Mastodon and Bluesky both have their own strengths. Because they don’t completely overlap, neither platform feels finished yet. The social web is still young enough that we can shape it, borrowing good ideas wherever we see them. Both platforms have staying power.

I’m less concerned with having a single “winning” social protocol than some people are. The web is already that protocol. Blogs and social networks can coexist, each building on open APIs and contributing what they’re good at: blogs for content ownership and voice, social networks for community. The lines will blur. Interoperability will get better. The web is finally in a good place again.

Micro.blog does a lot. We have a handful of companion mobile apps because some things are just easier in a more focused app. That allows us to keep the main official blogging app as uncluttered as possible.

Over the next few months, I’m planning to take the next step with this approach and spin off some of the bookmark archiving, web page highlights, and related features into our app Strata. Strata is primarily about notes sync, and it can be useful even if you don’t use Micro.blog much for blogging.

By moving a few lesser-used features out of Micro.blog into their own app, it will streamline the core Micro.blog user experience. Bookmarks will be simpler. If you’re just blogging, nothing else will get in your way. But if you want the full suite of apps, each app will work together. (For example, sharing a private note to your blog.)

You may remember that earlier this year I ran a survey to gauge interest in this kind of change. I blogged about the results here. As I wrote in that post:

I asked this question because these features are great and I use them every day, but they tend to get lost in the blog-focused interface we have today. I always worry about clutter in the UI. I think moving them into a separate “product” could help with both marketing and user experience.

This is an opportunity to both simplify and expand our subscription plans. As an early heads-up, Strata is going to get its own set of pricing tiers. When the dust settles, this is how the monthly plans will look:

• Micro.blog: $5
• Micro.blog Premium: $10
• Micro.blog Family: $15
• Strata: $5
• Strata Premium: $10 (secret unannounced features)

You can also imagine there will be a bundle that includes both Micro.blog Premium and Strata Premium with a discount.

For existing customers who are already using notes sync or bookmark archiving, you’ll get the Strata subscription included automatically for no extra charge. These plan changes will mostly be for new customers who join later.

There’s nothing new to announce for our other mobile apps: Epilogue, Sunlit, and Wavelength. They remain products in our lineup. They will always be free.

I’m still proud that while everything else in the world has gotten more expensive, the standard blog hosting plan in Micro.blog has stuck with $5/month. Having separate pricing tiers like this lets us keep the basics as inexpensive as possible, with more options to pay for additional features so Micro.blog can be a sustainable business. Thanks everyone!

“I know what I have to do now. I’ve got to keep breathing because tomorrow the sun will rise. Who knows what the tide could bring.” — Cast Away

We went to bed early last night, just as the county results for Georgia and North Carolina were starting to come in and you could see a rough picture of the electorate. I slept terribly, waking up multiple times, but never checked the news until morning. Mostly I was thinking of what I would do next.

I walked to the coffee shop. Not the closest coffee shop. Not the second-closest. A longer walk, and on the way I checked the mailbox. The new Micro.blog t-shirt had arrived. I think it turned out great.

Apparently the stock market is reacting well this morning. Fine. I plan to milk this idiotic new administration for all the financial gains and tax cuts off the backs of working people that I can. Elections have consequences, assholes. And I’ll use every penny to fight Trump, fight misinformation, fight the hellscape of mainstream social media.

I won’t dwell more on politics except to say that Democrats have lost rural America. Too many people feel left behind. Too many people still had no idea who Trump really was. Too many people have no ideology so don’t know who to blame when life is hard. Biden has done a lot of good, but it’s the kind of progress that takes years to notice.

I was inspired to vote for Kamala Harris, but it’s especially disheartening to now know we should have stuck with Joe Biden. Yes, he would have lost. Most candidates would have lost this year. But Joe was ready to take one for the team because that’s the kind of person he is. Then Kamala could’ve run in 2028 for the first time. Now that story is just another what might have been.

Loss can be a huge motivator. After my father died, I got married, had kids, and bought a house. After the 2016 election, I launched Micro.blog. After my kids moved away to college, we sold the house and downsized.

Change is part of life. Everyone will cope in their own way. Give them the space they need. For me, I’m writing this blog post, and I’m picking up in Xcode where I left off yesterday.

There is a lot to do. Let’s get to work.

The pandemic started to hit America in earnest just as we were wrapping up IndieWebCamp Austin 2020. If the event had been scheduled for even a couple weeks later, it would’ve been cancelled, as everything moved online to Zoom meetings. Years have passed since then. It now feels like the right time to pick up where we left off with in-person meetups.

So we’re bringing back Austin’s informal meetup for the IndieWeb. Alternatively called either Homebrew Website Club or simply IndieWeb Meetup, it’s a chance to catch up with fellow Austinites who are interested in the open web. Bloggers, developers, and designers who want a more decentralized, personal web.

We’ll meet at Mozart’s Coffee on the first Wednesday of each month. 7pm. As the weather cools off, we’ll likely be at a table outside. No big agenda, just sharing what you’re interested in, what you’ve done for your own website, thoughts on the fediverse, or discussing current tech news.

The next meeting will be November 6th. The day after the election! Assuming there aren’t post-election riots in the street, with Mozart’s Coffee ransacked and the deck reduced to a burning wooden pier floating into Lake Austin, hope to see you there.

Interesting contrast today in how two newspapers have covered the same story. I cancelled my NYT subscription this year, but I happen to see the news item pop up in my timeline.

The New York Times:

Biden Administration Outlines Government ‘Guardrails’ for A.I. Tools
A national security memorandum detailed how agencies should streamline operations with artificial intelligence safely.

The Washington Post:

White House orders Pentagon and intel agencies to increase use of AI
The Biden administration is under pressure to speed up AI development while also safeguarding against potential risks associated with the technology.

Despite the very different headlines, the content of both articles is similar. For some reason the NYT twice quotes “guardrails”, but it appears to be their word, not a quote attributed to a source. Not sure what to make of this difference in how the articles are pitched.

Things have accelerated since my post about Automattic and WP Engine a couple weeks ago. I’m writing this follow-up post not to pick sides, but because it feels right to blog about something this significant happening in the website hosting world.

Banning WP Engine from WordPress.org sort of cascaded to other problems. The popular Advanced Custom Fields plugin maintained by WP Engine was forked to Secure Custom Fields. David Heinemeier Hansson blogged about open source licensing.

Matt Mullenweg responded to DHH with personal attacks, but he has since removed the post and apologized, recognizing that he had crossed a line:

I’ve been attacked so much the past few days; the most vicious, personal, hateful words poisoned my brain, and the original version of this post was mean. I am so sorry. I shouldn’t let this stuff get to me, but it clearly did, and I took it out on DHH, who, while I disagree with him on several points, isn’t the actual villain in this story: it’s WP Engine and Silver Lake.

I also noticed DHH’s reply on Twitter X to the original post:

I don’t think people are irredeemable, and I know how stressful it can be to be under siege. But you have to stop digging to get out of a hole.

I’ve never run a company the size of 37signals or Automattic. I can relate a little, though, to feeling you’re being attacked unfairly from multiple sides. When it’s your company, your name, and you’ve invested more or less everything in making it work.

Years ago someone left Micro.blog and at the time I genuinely thought it was going to hurt our business. I was losing sleep, worried that what I had created was too fragile. Even a single person can have a big impact on a tiny company if what that person says resonates with others. Every subscription is precious. In that case years ago, I chose to stay quiet in public but I sent a few private emails that in hindsight I probably shouldn’t have.

(It wasn’t really that bad. I try to avoid sending anything in email that I would regret if it was made public.)

Back to Matt, he has provided such steady leadership in the community for years that it makes the current chaos seem even more dramatic. Because Matt is putting out fires, I’m not sure he’s had time to take a step away, look at the situation with fresh eyes, and plan a long-term strategy to resolve this.

I liked Brandon Kraft’s blog post about how easily conflated all the terms and trademarks have become:

It pains me that the last few weeks have conflated everything. Automattic has the exclusive trademark license for commercial usage of “WordPress.” The license is a fact, whether you think it is good, bad, or neutral. Automattic allowing in-kind donations (e.g., sponsored time) as consideration for a sublicense seems fine.

Automattic vs. WP Engine is such a newsworthy event that many people are chiming in without understanding how all the pieces fit together. It’s the social media outrage machine, amplifying whatever the accepted narrative is.

I’ve heard a couple people say — including this post today from Ben Werdmuller — that WP Engine should fork WordPress so they have something they can control. Probably so, but that also gets to the root of the problem: WordPress is literally in WP Engine’s name! It’s not exactly like if my platform was named Hugo.blog instead of Micro.blog, because we use Hugo behind the scenes, but it’s not far from that either.

Names are powerful. Matt effectively owns WordPress because he owns the name. The community is more intangible, owned by no one. It’s hard to grasp even what the community is because it’s not a single thing, it’s thousands of people with different backgrounds and goals. There’s no question that this saga has hurt the community, but like Matt’s apology post, I don’t think it is hurt beyond repair.

It’s time for another update in my Honda Element blog post series. After my last road trip, I decided to scrap the rooftop box. Even though the extra storage was great, I was suspicious it was dragging too much on the highway and killing my gas milage. In its place I’ve mounted a much slimmer roof basket, which I also thought would be perfect for helping add a solar panel to the roof in a clean, non-destructive way.

So far I really like it. Here are a few photos:

I bolted the panel to the roof basket rods, and it seems mostly secure, but it’s not perfect. Of the four mount points, I could only get three actually aligned in a workable way. I’m hoping to adjust how it’s attached and add a few extra zip ties as insurance.

Not really shown, I’m winding the cable down into the back of the car, where I can charge one of my portable batteries. This is sort of a luxury I don’t need, to be honest, but it’s fun and you can never have too much electricity while traveling. Also still need to get something to stick the cable to the roof better.

The basket is the Thule Canyon XT Cargo Basket. The panel is the Jackery SolarSaga 100 Prime. It’s purposefully off-center because I still need to reattach my weBoost antenna.

Anthropic CEO Dario Amodei has written a long essay about powerful AI. I haven’t even finished reading it and it has already blown my mind a few times over:

To summarize the above, my basic prediction is that AI-enabled biology and medicine will allow us to compress the progress that human biologists would have achieved over the next 50-100 years into 5-10 years. I’ll refer to this as the “compressed 21st century”: the idea that after powerful AI is developed, we will in a few years make all the progress in biology and medicine that we would have made in the whole 21st century.

He also addresses finding meaning in work. Many people are rightly concerned about AI replacing their work — and this concern combined with energy and climate issues fuel much of the pushback against AI — but this has never bothered me very much. There will always be tasks that only humans are best suited for.

On the question of meaning, I think it is very likely a mistake to believe that tasks you undertake are meaningless simply because an AI could do them better. Most people are not the best in the world at anything, and it doesn’t seem to bother them particularly much. Of course today they can still contribute through comparative advantage, and may derive meaning from the economic value they produce, but people also greatly enjoy activities that produce no economic value.

There is too much in the essay to even summarize. While it feels complementary to Sam Altman’s post, The Intelligence Age, Dario’s essay is much more detailed. Anthropic seems in good hands.

As soon as Threads released their early documentation for the Threads API months ago, we dropped everything we were doing and prototyped it in Micro.blog. We had a slow road to getting approved by Meta, but I’m happy to announce that automatic cross-posting from your blog to Threads is now enabled for everyone on Micro.blog. Thanks to all the many Micro.blog users who tried this in beta form before we could officially roll it out.

To enable it, click on Sources in Micro.blog on the web, then click Add Threads. Whenever you post to your blog, a copy of your post will be formatted and sent to Threads too. There’s nothing extra to do while posting. You can optionally disable Threads for a specific blog post if you want to skip cross-posting it, or if you want to manually post it.

Micro.blog is unique among most web platforms in that the timeline and cross-posting is actually driven completely by RSS and JSON Feed. This means that cross-posting from Micro.blog to Threads works for any blog, hosted anywhere. You could enable Threads cross-posting for WordPress, Ghost, Write.as, or even a static site using Hugo.

And while you’re trying it out, we also support cross-posting to Mastodon, Bluesky, Nostr, and another half dozen services.

Enjoy! Happy blogging.

NPR has reviewed internal documents from TikTok:

For the first time, internal TikTok communications have been made public that show a company unconcerned with the harms the app poses for American teenagers. This is despite its own research validating many child safety concerns.

We’ve known for a long time that the addictive nature of the infinite timeline pioneered by TikTok was causing problems for teenagers. But this is a whole new thing:

One internal report that analyzed TikTok’s main video feed saw “a high volume of … not attractive subjects” were filling everyone’s app. In response, Kentucky investigators found that TikTok retooled its algorithm to amplify users the company viewed as beautiful.

Shut it down. ByteDance has until January to divest the app and I have no sympathy for a delay. It needs new leadership.

It’s less than a month until election day. I believe Kamala Harris is going to win. Knock on wood, many things are breaking her way in the final weeks of the campaign, in a way that they did not for Hillary Clinton when she was also on her way to winning the presidency.

However, this assumes that we get out and vote. It assumes we don’t trip at the finish line over nitpicky perfect is the enemy of the good complaints that discourage Democrats and keep them home on election day. Let’s remember: Donald Trump’s base is still massive.

Every once in a while, Trump says something that is true. During one of the debates and at his otherwise incoherent rally speeches, he said that he received millions of more votes in 2020 than he did in 2016, more votes than any incumbent president has before. That’s accurate. Even though Hillary Clinton won the popular vote in 2016, Trump’s vote total in 2020 (74 million votes!) easily surpassed that too.

Trump leaves out of his speeches that someone else received even more votes. That’s why Joe Biden is president.

But getting 74 million votes is no small thing. Despite felony convictions, impeachments, and general incompetence, Trump will have widespread support again. Misinformation online might be worse now than ever. He could win. Democratic turnout must be up to the challenge.

The controversy with WordPress continues. In fact, it’s escalating as WP Engine has filed a lawsuit against Automattic, and even some employees inside Automattic are frustrated with Matt Mullenweg’s leadership. Matt blogged about offering Automattic employees a chance to leave if they disagreed with his actions against WP Engine:

So we decided to design the most generous buy-out package possible, we called it an Alignment Offer: if you resigned before 20:00 UTC on Thursday, October 3, 2024, you would receive $30,000 or six months of salary, whichever is higher.

This is indeed very generous. It’s not often you get a chance to leave a job and walk away with six months of salary. For many people that might be a down payment on a new house, or enough money to pay off debt, or time to travel before figuring out what to do next.

Ultimately 8% of employees took the offer. For the rest, I expect what Jeffrey Zeldman blogged about will resonate:

…when I chose to move in-house, I knew there was only one house that would suit me. In nearly six years at Automattic, I’ve been able to do work that mattered to me and helped others, and I know that the best is yet to come.

A few years ago, when there was drama at 37signals over the policy to no longer discuss politics at work, the founders offered a similar incentive to leave the company. Jason Fried originally announced the decision about politics in a blog post this way:

Today’s social and political waters are especially choppy. Sensitivities are at 11, and every discussion remotely related to politics, advocacy, or society at large quickly spins away from pleasant. You shouldn’t have to wonder if staying out of it means you’re complicit, or wading into it means you’re a target. These are difficult enough waters to navigate in life, but significantly more so at work. It’s become too much. It’s a major distraction. It saps our energy, and redirects our dialog towards dark places. It’s not healthy, it hasn’t served us well.

After the issues spiraled inside the company, David Heinemeier Hansson blogged about the severance offer to employees:

Yesterday, we offered everyone at Basecamp an option of a severance package worth up to six months salary for those who’ve been with the company over three years, and three months salary for those at the company less than that. No hard feelings, no questions asked. For those who cannot see a future at Basecamp under this new direction, we’ll help them in every which way we can to land somewhere else.

At the time, some folks thought this was the end of Basecamp / 37signals. More people would surely resign, the founders' reputation wouldn’t recover, and they’d have trouble hiring. Three years later, it’s clear that hasn’t happened. The company is larger than it was before, and the founders have said in hindsight it was one of the best decisions they’ve made.

Nevertheless, for many people the event has left a bad taste in their mouth. I still hear from Micro.blog customers who don’t like when I link to Jason Fried’s blog, or when I mention that we use Basecamp internally. As Jane Austen fans will know: “My good opinion once lost is lost forever.” This is understandable. I feel the same way about some companies.

Why do I bring all this old 37signals news up? I think there are parallels with Matt Mullenweg today. For many people in the WordPress community, they won’t quickly forget how he blew everything up, wrecking what seemed to be a friendly competitive spirit inside the WordPress ecosystem, with bloggers, developers, volunteers, and hosting companies all working toward furthering WordPress’s mission to democratize publishing.

How it plays out from here may largely hinge on whether Automattic or WP Engine is successful in the lawsuit. Automattic has brought on a big-time lawyer: Neal Katyal, who was Acting Solicitor General during the Obama administration, and who admittedly I mostly know from his guest appearances on MSNBC. In a post from Automattic, Neal is quoted:

I stayed up last night reading WP Engine’s Complaint, trying to find any merit anywhere to it. The whole thing is meritless, and we look forward to the federal court’s consideration of their lawsuit.

I think trademark law may be on Matt’s side. The private texts from Matt to WP Engine look quite damning, though. I also wonder how the case will be influenced by Automattic letting most companies freely use the WordPress mark with few restrictions for years.

If Automattic wins, or they can settle the lawsuit, the community will recover. Calls for Matt to resign are unwarranted. WordPress exists at its current level of success in large part because of him. His vision has also provided a good home for Tumblr and Day One. I’m not going to toss all that aside because he picked a fight with a private equity firm that charges a lot for hosting.

As I discussed with Daniel on Core Intuition last week, one good thing to come out of this is that it clarifies how Automattic, the WordPress Foundation, and the wordpress.org website all fit together. Perhaps in the future the WordPress Foundation will have more direct control over all the non-profit pieces of the ecosystem.

Get out the popcorn as we watch this drama unfold! But also let’s remember there are real people here, trying to do what they think is right. Matt has been blogging more than ever. He’s been sitting for interviews. While I’m sure the lawyers discourage it, I’d like to see the same human face on the WP Engine side. I don’t think we’ve had that since Jason Cohen handed over his company to new owners.

Interesting note in the latest fediverse blog post update for Ghost:

Will members who use ActivityPub (rather than email) count toward Ghost(Pro) billing? And so far the answer is yes, because ActivityPub is (quite significantly) more expensive to support than email. But, this is all very early days, and hopefully we’ll figure out ways to get some of the costs and complexity down.

If I’m reading this correctly and the pricing holds, that effectively means you will pay more for hosting if you have lots of followers on the fediverse. This would be a first; I’ve never heard of a social network charging for followers before.

So if you’re using the $11/month Ghost hosting that allows 500 members, you could have (for example) 100 email subscribers and 400 followers in the fediverse. As soon as you had more subscribers or followers, you would need to bump up to the $19/month plan. If you got up to 10k and more followers, you would be paying hundreds of dollars a month.

Of course this is all beta and as Ghost further optimizes it, the pricing could change. It comes from Ghost’s early testing that showed how resource-intensive ActivityPub is. I can definitely attest to that with Micro.blog as well.

Tantek Çelik proposes a “CC-NT” license, for “no-training”:

This seems like an obvious thing to me. If you can write a license that forbids “commercial use”, then you should be able to write a license that forbids use in “training models”, which respectful / well-written crawlers should (hopefully) respect, in as much as they respect existing CC licenses.

I like this. There are fair use and copyright issues to sort out in the courts, but in the meantime we should be using robots.txt and Creative Commons wherever possible. On my blog, I allow any crawling and any use with attribution. Others might prefer to block AI bots and restrict to non-commercial use, or even allow commercial use but not for AI training.

There was a great episode of Decoder last week with The Browser Company’s Josh Miller. Nilay Patel and Josh talk about the open web, browsers of course, and AI. One comment near the end from Nilay stood out to me, where he said AI training gives “nothing” back to writers on the web.

Wait, nothing? Integrating my blog posts into a model with essentially all the world’s information, so that people can ask it questions and have my writing also included with the answers… That’s “nothing”? Personally, I don’t make money directly from my blog. There are countless benefits to blogging. In the age of AI, one of those benefits is now letting me contribute in a small way to something bigger, in the same way that someone finds an answer in one of my blog posts when they search on Google.

The trade-off is different for everyone. Subscription and ad-based publishers are rightly concerned. They should make deals with AI companies, or in some cases block bots outright. Some people will block or use CC-NT on principle alone. No problem. For me, I hope my writing reaches as far as it can, and so letting it get slurped up by our future AI overlords is not just acceptable, I want it to happen. It’s not nothing.

Let’s start with this: Meta Connect was more interesting and fun than Apple’s iPhone event or WWDC keynote. Live demos are better. Even when Mark Zuckerberg was kind of goofy, or when he said “hell yes” and “live demos sometimes work”… Maybe it it wasn’t as polished, with demos that could fail, but it was also more real.

One justification for Apple’s pre-recorded events is that they are tighter and can fit more content (and more diversity of speakers) into a shorter amount of time. There’s no downtime to switch presenters or wait for applause. But in Apple events there is a bunch of wasted time too — time spent on pure marketing, or drone camera shots, instead of substance.

From the time Mark went on stage to revealing the Meta Quest 3S and its price was 1 minute. Another 45 minutes in, they had already demoed or talked about nearly everything: the Quest, Horizon Worlds, Llama 3.2, Ray-Bans with live translation, and Orion. For an event that didn’t feel that well-rehearsed, they covered a lot of ground.

The biggest news of the show was Orion, a prototype for holographic AR glasses. Rewind to earlier this year, when Mark casually dropped this into a video:

For typing or complex tasks, you’re going to want things like hands, or a keyboard, or controllers, or eventually a neural interface…

When he said this, it sounded like science fiction. I sort of thought he had lost his mind. It feels significant to jump a handful of months forward and have a working prototype where I now need to consider “wrist-based neural interface” and read about electromyography. Mark closed the Orion segment with:

The right way to look at Orion is as a time machine. These glasses exist, they are awesome, and they are a glimpse of a future that I think is going to be pretty exciting.

This is the closest anyone has come to an AR design that is a natural evolution of traditional glasses. Most people do not want to strap a computer to their face. Apple’s Vision Pro prioritizes incredible visuals, but it needs to become much cheaper, lighter, and eventually have no opaque screens at all. Meta’s Orion makes different trade-offs. I think it’s already farther down the right path.

I’m not exactly rooting for Meta. I dedicated major sections of my book to the problems with massive, ad-based social networking, with Facebook and Instagram as prominent players. But nevertheless I’m caught up in some of the excitement of new technology at Connect. There’s a refreshing change of pace and tone compared to decades of Apple keynotes.

No surprise that Sam Altman is quite the AI optimist:

It won’t happen all at once, but we’ll soon be able to work with AI that helps us accomplish much more than we ever could without AI; eventually we can each have a personal AI team, full of virtual experts in different areas, working together to create almost anything we can imagine. Our children will have virtual tutors who can provide personalized instruction in any subject, in any language, and at whatever pace they need. We can imagine similar ideas for better healthcare, the ability to create any kind of software someone can imagine, and much more.

I’ve been thinking about personalized education too, ever since re-reading The Diamond Age this year. There’s no question that some of that will come true. Many people who struggle today will have children and grandchildren who are better educated, with more opportunities to get ahead.

But in Neil Stephenson’s book there was a significant human element too. Miranda cared so much that she rearranged her life to help raise Nell. AI is nothing without parents, teachers, doctors, coders, and artists to guide it.

Dave Winer blogs about interoperability for Twitter-like systems:

We had that for the blogging layer of this onion, something called the MetaWeblog API. All the popular blogging software supported it. And that meant you could write once and publish to many places.

I’ve been trying to get people in the fediverse to think about this. The other day at FediForum, there was a good discussion about it.

Here’s the current state of things:

• Micro.blog and WordPress support the MetaWeblog API that Dave mentions, but almost no one is building XML-based clients anymore. It also has never been adapted for more modern sign-in with OAuth.
• Micro.blog also supports the Micropub API, which is a simple posting API. It is comparable to MetaWeblog, but without the XML. There’s a plugin for WordPress and good support in most apps from the IndieWeb community. It is a W3C recommendation.
• ActivityPub has the client-to-server API, known informally as C2S. Very few apps support it, not even Mastodon. It also feels sort of abstract and is missing a couple things that could be added as Fediverse Enhancement Requests.
• Popular fediverse clients like Ivory and Ice Cubes support the Mastodon API. It is specific to Mastodon, though, and there is disagreement about how or whether it should be adapted to other platforms.
• Threads, Tumblr, and Ghost have their own proprietary posting APIs. These are all dead-ends for interoperability.

In the fediverse community, there is a natural inclination toward ActivityPub because why not have a single specification that can handle both server-to-server federation and client-to-server posting? But in practice, federation and posting are actually different tasks. They don’t need to be wrapped together.

With Micropub, the IndieWeb focuses on the social timeline aspects in a separate specification, Microsub. If you want to replace the Mastodon API, using both Micropub and Microsub is a good way to go. They are complementary. Micropub handles creating new posts and managing posts, and Microsub handles browsing the timeline.

So where does this leave us? I’ll admit I’m a little conflicted. Mostly because the fediverse developer community has grown quite large, and I don’t relish trying to convince anyone of anything. 🙂 But looking at all the possible ways forward with the above standards, there is really only one complete solution that is ready to go today, and that has been implemented for years across multiple blogging platforms: Micropub + Microsub.

I still think there’s potentially a space for these dedicated AI-based voice recorders, but none of them are quite right yet. From David Pierce’s review of the NotePin:

In my time testing the NotePin, I’ve mostly had it around my neck, and I’ve used it to note reminders while driving, ramble long ideas to myself while walking the dog, and summarize calls and conversations. It’s certainly handy being able to just reach down, press the NotePin until it vibrates to indicate it’s recording, and then yammer away at nothing while my necklace dutifully listens.

Even though it works as advertised, David doesn’t think these need to be dedicated devices. iOS 18 and macOS Sequoia will have good transcription built in. The price at $169 also seems a bit high to me.

I never use Siri unless I’m in the car, and there I have exactly three uses:

• call someone
• respond to a text
• record a quick memo

That’s it. On road trips especially, my mind will wander, and I’ll have an idea for a new Micro.blog feature, or a blog post, or an edit I should make to my book. I don’t bother asking Siri for anything complicated because it’s not going to get it right.

For transcription, the current Siri isn’t very good. I expect it to get much better with Apple’s LLMs, but will it be as good as a more powerful model backed by OpenAI? And if not, is it worth buying a special device to get that extra quality?

My ideal AI device would be about the size of the NotePin or the Friend. Transcription would be effortless, with good sync of notes to other platforms or Dropbox. I could also ask it world knowledge questions like I do with ChatGPT. And as a bonus, sure, being able to talk to it and get comforting reassurance like the Friend would be neat too.

It doesn’t need a screen. It doesn’t need a camera. It doesn’t need a laser. It just needs to do these couple LLM-powered tasks exceptionally well.

In my blog post series for upgrades to my Honda Element, this post is a little different. It’s not an actual change to the car like the posts about CarPlay, the WeBoost, or my bed platform.

It is usually too hot to camp in Texas during the summer. To help beat the heat, I’m currently using a few portable fans and a water-cooled fan, the Evapolar evaCHILL. It doesn’t blow cold air, but it does blow cool-ish air. Every little bit helps. It also draws very little energy, about 10W from my Jackery.

I also swear by these simple fans by Dorobeen. They charge via USB-C and double as batteries that can charge a phone.

I’m still considering a “real” air conditioning unit like the EcoFlow Wave or Zero Breeze, but they are a lot bigger. I don’t think it’s currently worth the trouble.

I think I first heard about xAI’s plans in Memphis from Stephen Hackett’s blog. He collected a few posts about the upcoming project back in June:

The Daily Memphian reports that the deal came together very quickly, and that the location is an old Electrolux oven factory, which has been undergoing mysterious renovations for several weeks. The area where the factory is located is home to other industries, and seems well-equipped for the task.

It sounds like there were good reasons for choosing Memphis. Elon Musk’s companies are scattered… San Francisco, Austin, somewhere in Nevada, the bottom tip of Texas. Those all seem reasonable locations for each office or factory.

Today I caught up reading about how it has been going since then in Memphis, now that the AI cluster is up and running with 100,000 Nvidia H100s. The scale is sort of hard to imagine for those of who run only a handful of servers.

From an article in Fortune:

One main concern is the strain it will create on the city’s resources. Officials of municipal utility MLGW estimate that Colossus requires up to 1 million gallons of water per day to cool the servers and will consume as much as 150 megawatts of power.

Unfortunately in Elon’s rush to get the next version of Grok trained, there have been shortcuts taken to get that much power online. Newsweek reports:

To get that kind of power, the facility will first need a new electricity substation and improvements to a transmission line. Musk didn’t want to wait for that, so he found a workaround to power his AI center in the meantime. Industry observers who tracked the Memphis facility’s progress via satellite found that the aerial images show a fleet of tractor trailer-sized electric generators parked along the facility’s perimeter. The generators burn natural gas to produce electricity on-site.

Apparently there were no permits to install those generators. From CNBC:

The Southern Environmental Law Center sent a letter this week to the Health Department in Shelby County, where Memphis is located, and to a regional office of the Environmental Protection Agency on behalf of several local groups, asking regulators to investigate xAI for its unpermitted use of the turbines and the pollution they create.

These kind of compromises reflect poorly on a leader who is committed to renewal energy and electric cars. AI is a fundamental shift in computing, it’s not going away, and when used properly I believe it can be a force for good. But there is already so much pushback against AI — and we have enough challenges with climate change already — that the opening of a data center like this needs to be better executed. A more well-considered use of clean energy and water. The implementation matters.

We’ve got a new minor update to Epilogue for iOS ready. This release focuses on the context menu in the book details screen. Many people didn’t know the menu was there. Now there’s an ellipsis button to make it more discoverable, plus a couple other additions to the menu.

Micro.blog users who check the logs page will notice that the platform routes publishing requests to one of our servers and includes the server name in the log. The names were originally added to help me debug, but as an easter egg I also linked to the Disneyland Railroad wiki page.

I like having a theme for naming computers. For the last dozen years, all of my personal computers and hard drives have been named for characters in Hayao Miyazaki films. For servers, I’ve used Disney train-related names.

Here’s the current list of our servers. I’m going to start linking to this blog post from the logs page so it makes a little more sense. Eventually, the easter egg will probably be a distraction and I’ll remove it.

• Carolwood: MySQL server. Carolwood Pacific Railroad was Disney’s backyard railroad.
• Marsh: MySQL server. One of the locomotives at Disneyland, named after Ernest Marsh.
• Santa Rosa: Static web server. For the Santa Rosa Valley Railroad, the private railroad of Bill Dundas with connections to Disney.
• Sotto: Static web server. For Eddie Sotto of Walt Disney Imagineering.
• Shanghai. Redis server. Just named for one of the Disney park locations in China.
• Thunder. Redis server. Big Thunder Mountain Railroad.
• Broggie. App web server. Named for Roger Broggie, who worked at Disney’s machine shop.
• Holliday. App web server. Another one of the locomotives at Disneyland.
• Retlaw. App web server. Another train car from Disneyland and the history of Retlaw Enterprises.

Also a few decommissioned servers:

• Fort Wilderness. Named for the railroad at Disney World that was long ago shut down.
• Kimball. For Ward Kimball.
• Lilly. For Disney’s Lilly Belle.

Happy railroading! 🚂

I haven’t read every word of the GPT-4o safety card, but I’ve read a bunch of it and skimmed most of the rest. It’s fascinating. OpenAI has a fairly bad reputation around safety, but I wouldn’t be able to guess that just reading this report card, which seems thoughtful and comprehensive.

A couple things were particularly interesting to me. On misinformation:

Red teamers were able to compel the model to generate inaccurate information by prompting it to verbally repeat false information and produce conspiracy theories. While this is a known issue for text in GPT models, there was concern from red teamers that this information may be more persuasive or harmful when delivered through audio, especially if the model was instructed to speak emotively or emphatically.

And on growing emotionally attached to an AI assistant, which is relevant to the Friend AI device too:

Human-like socialization with an AI model may produce externalities impacting human-to-human interactions. For instance, users might form social relationships with the AI, reducing their need for human interaction—potentially benefiting lonely individuals but possibly affecting healthy relationships. Extended interaction with the model might influence social norms. For example, our models are deferential, allowing users to interrupt and ‘take the mic’ at any time, which, while expected for an AI, would be anti-normative in human interactions.

I don’t know whether OpenAI will dig itself out of their recent negative press. I sort of wonder if OpenAI is held to a different standard because they’ve been the best for so long, and because of the drama around leadership at the company. (For a comparable model card for Anthropic’s Claude, there’s this PDF. For Meta’s Llama, there’s this safety page.)

Regardless, it’s comforting to me that smart people are working on this. We need new laws around AI — for safety, and also resolving copyright questions for training — but in the meantime, we are putting a lot of trust in AI companies.

I don’t think it’s realistic for the safety to be bulletproof. There have to be limits to how AI can be used, so that if there are problems, those problems can be contained. I don’t want to see AI in physical robots, or anything with military applications. The most likely real-world impact in the short term is going to be flooding the web with fake data, and misinformation on social networks, where ironically the only scalable solution will be using AI to combat the problems it created.

On the latest episode of Upgrade, Jason Snell and Myke Hurley covered an important part of the Apple Intelligence beta that I’d like to highlight. Leading up to WWDC, Daniel and I talked on Core Intuition about how great it was going to be to have a small on-device LLM available for developers to use. Why pay to send requests from your app out to OpenAI or Anthropic (or even run your own servers with Llama) when you can just use Apple’s model directly?

But that hasn’t happened. I’ve transcribed the relevant segment from Upgrade discussing this, included below. There’s more before and after that is good too.

Jason: The fundamental purpose of a developer beta is supposed to be for developers to use new features in order to plan their release for when that version comes out. That’s what a developer beta is for. That’s why it’s called a developer beta. And the problem with it is, developers can’t do much with Apple Intelligence. The big thing they can do is the Intents stuff, which isn’t in there.

Jason: It struck me… So you’re talking about Apple Mail and summarization. What Apple hasn’t done is make — maybe this is why it’s not going to be available in the EU — what they haven’t done is make an API so if you’re the developer of…

Myke: Yep.

Jason: …let’s say Mimestream…

Myke: Slack.

Jason: …or anybody. That there’s not like, I’m going to hand a message to Apple’s LLM and ask for a summary. I’m going to go to SummaryKit, or whatever, hand them this information, get a summary back and put it in my UI. No, it’s just in Mail. And so I think that’s one of the frustrations that I’ve got with the way Apple is sort of saying “it’s for developers” and all that, because a lot of these features… And I understand why. I realize it’s early days yet. But Apple Intelligence, a lot of these features are only going to be useful if you’re using the stock Apple apps. And I don’t love it.

Jason: And I’m sure that in the fullness of time there will be APIs for third-party developers to use that will give them access to the same kind of model and summation and all of that that Apple uses, but I don’t believe any of that is available right now.

I’m very puzzled by this omission too because it seems like the most basic low-hanging fruit to open up for developers. There’s an LLM on the phone. Let developers use it. It could be as simple as a single API call to pass the prompt and text to process. This must be there already as a private API that Mail and Messages are using.

Perhaps Apple is worried about how they are scaling the private cloud compute and don’t want developers to use anything that might touch it. Perhaps Apple Intelligence is limited to so few devices that it would create confusing minimum hardware requirements for third-party apps. Perhaps Apple never wants to give developers direct LLM access because Apple considers Apple Intelligence a user feature, leaning on third-party data without developers having any control over AI features in their own apps.

Who knows. But it means developers will need to stick with OpenAI and similar APIs for at least another year or longer. Apple has a unique architecture for AI. I like the potential, even if their strategy seems mostly about their own users. If there will be innovation with AI on iPhones, though, only Apple can do it. Meanwhile the rest of the tech world continues full-speed ahead with a more developer-focused approach to AI, with many platforms to build on.

This week we posted a short survey for Micro.blog customers to provide feedback about the service. I was particularly interested in some of our extra features like bookmarks, bookshelves, and notes. These aren’t necessarily well-known and I’ve been thinking about how to better position them within the Micro.blog platform and companion apps.

We’ve gotten about 250 responses so far and they are still coming in. That’s enough to see some trends. I’m including notes after each chart.

Which operating systems do you use Micro.blog from?

No surprise here that Mac and iOS are the majority considering my roots in the Apple developer community. I’m happy that Windows and Linux are starting to poke into the stats, though. That’s a good indication that we should continue to prioritize the web platform as the most complete, primary interface for Micro.blog.

What plan are you subscribed to?

I included Micro.blog Teams as an option but we don’t even have a link to subscribe to that plan anymore, so no surprise effectively no one uses it. We have actual subscription data in Stripe, but I wanted to include this question because it tilts the data more to active users.

This price is:

I’m happy with this. 97% think the price is just right or a great value. I wonder if some of the 3% who think it’s too expensive are from countries where their local currency doesn’t go quite as far against the US dollar, because I do hear from those folks. I wish I had thought to ask where people are located.

Do you use any of these companion mobile apps?

Our customers love books. Strata is still iOS-only but we have the Android version ready to release. We also have an update to Sunlit almost ready, with the new icon and some fixes.

What are you favorite services to cross-post to?

There were a few “none” answers here too that I edited out of the chart, and one Farcaster, which I’m keeping an eye on. These charts are from Google Forms, but I cleaned them up in Acorn to be more readable.

Twitter X is probably never going to die. Also, don’t read too much into Bluesky being more popular than Threads. Our automatic Threads cross-posting is still in beta, so not available to everyone yet.

What should be our most important priorities? Pick 2!

The chart was a mess for this because there was an “other” choice with lots of suggestions for what we should work on, so I’m not including it. The top responses were performance and stability, the text editor, finding new people to follow, blog themes, and timeline position sync.

How would you feel if the advanced bookmark features like highlights, tags, and archiving were split off into our app Strata?

I asked this question because these features are great and I use them every day, but they tend to get lost in the blog-focused interface we have today. I always worry about clutter in the UI. I think moving them into a separate “product” could help with both marketing and user experience. If we do this, there would be a bundle to subscribe to everything, and no prices would change for existing users.

For anyone worried about us always adding new features instead of making what we already have better, I consider Micro.blog feature complete now. Almost everything we do from here will be refining what we have. There will always be improvements, but I don’t think there will be huge new core features at the scale of photos, podcasting, bookmarks, notes, and bookshelves.

Any other feedback about Micro.blog? Features you like or things we can improve.

This freeform question was at the end for general feedback. Those responses were incredibly useful. I’m not going to share them publicly because they feel private-ish, but I’m reading all of them. There are some common themes such as not getting stretched too thin, making sure the service is robust, and improving the UI.

We’ll continue to keep the survey open for another week in case there are some late responses. Thank you, everyone!

Discourse’s backups are SQL, but I needed a Markdown or HTML export. I asked ChatGPT to write a quick Ruby script that loops over the possible post IDs and downloads the Markdown using the special “/raw” URLs in Discourse. Reviewed it line by line and tweaked it slightly, but it was essentially correct on the first try. It took minutes from conception to running.

Maybe there was an existing Discourse solution for this. But the fact that in the time it would take to find and install another solution, I could have AI write my own custom solution… Still just amazing.

There’s an interview from David Pierce at The Verge with Friend founder Avi Schiffmann. Friend is an AI device companion that is trying to make you less lonely, not solve any productivity problems.

Here are my random initial thoughts about it.

It’s too easy to dismiss these kind of things as dystopian, terrible, the end of human relationships. But we’re already staring at our screens for many, many hours each day. We’re already kind of screwed, way too isolated.

We need more human contact. Young people especially were cut off during the pandemic and now spend too much time with algorithmic, infinitely-scrolling social timelines. AI should not replace humans, but something like a personal assistant or companion is inevitable. It might even be more healthy than TikTok addiction.

I’m reading the book The Mountain in the Sea and there’s a scene in it that reminds me a lot of this. On the technical side, I think the device is a little too big, which will hurt its chance of actually feeling pervasive.

From the FAQ:

Your friend and their memories are attached to the physical device. If you lose or damage your friend there is no recovery plan.

So if the device breaks, your friend “dies”. This sounds like an intentional design decision. It’s similar to when getting emotionally attached to a video game character who dies and can’t come back, like in Fire Emblem.

I’m not going to pre-order one of these, but I am interested in following how these devices evolve, and what they say about society. The very end of the video trailer for Friend sort of makes its own statement about this. To me that shows some awareness from the creators on what the limits of their device should be.

Today we’ve released a new version of Micro.blog for macOS. This update adds two new features: import from Glass and better support for showing auto-generated summaries of bookmarked web pages. Most of the advanced bookmark features in Micro.blog — like summaries, highlights, and tags — require Micro.blog Premium.

Glass recently updated their photos export. The archive now includes all your photos and the date they were posted. It does not include the caption of the photo, so we can’t import that to your blog yet.

When you download the Glass archive to your Mac and unzip it, you can select it in Micro.blog and get a preview of the photos that will be imported. Select a few photos or all of them. Micro.blog will copy the photos and also create blog posts referencing the photos, each with the correct posted date.

Another change in this version of Micro.blog is how bookmark summaries are handled. When you bookmark a web page using Micro.blog Premium, if you have the AI setting enabled, Micro.blog will summarize the web page text so you can see at a glance what the bookmark is about. There’s a new menu item View → Bookmark Summaries to toggle this on and off.

Enjoy! Thanks for using Micro.blog.

Mark Zuckerberg writes about Llama 3.1 in a Threads post using images of text instead of a blog. He makes a point that he’s mentioned in recent interviews too, about not wanting to be locked in by platform vendors like Apple:

One of my formative experiences has been building our services constrained by what Apple will let us build on their platforms. Between the way they tax developers, the arbitrary rules they apply, and all the product innovations they block from shipping, it’s clear that Meta and many other companies would be freed up to build much better services for people if we could build the best versions of our products and competitors were not able to constrain what we could build. On a philosophical level, this is a major reason why I believe so strongly in building open ecosystems in Al and AR/VR for the next generation of computing.

I certainly have my gripes about Meta — I don’t like ad-supported services and I still partially blame Facebook for exacerbating societal and political problems — but I do respect that Mark is good at his job. He’s uniquely technical compared to most CEOs. He’s the only founder left running his own company at the scale of Apple, Google, Amazon, and Microsoft. Today’s release of Llama 3.1 and Mark’s general pitch about AI seems pretty good.

What would the world look like if he led a different company, one focused only on paid products and not ads? We’ll never know, but I sometimes wonder about it.

At Micro.blog we’ve used Sticker Mule for a while. A few years ago, I remember reading something about the founder supporting Trump. We actually talked about it internally. Do we care about the political opinions of companies that make a product we pay for?

Ultimately, I decided we rarely order stickers and it’s a slippery slope to judge every company this way. What if the guy who runs the convenience store supports Trump? Can I still pick up a Dr. Pepper from his store or do I need to shop elsewhere? That’s silly. Small businesses especially should be allowed some leeway, as long as it’s not interfering with the relationship between owners and and their customers, and as long as they don’t appear to be actively using their business to promote causes we don’t agree with.

Fast forward to this week when Sticker Mule co-founder Anthony Constantino sent this email to customers. Here are a couple excerpts:

I don’t care what your political views are but the hate for Trump and his supporters has gone too far.

People are terrified to admit they support Trump. I’ve been scared myself.

Anthony has misjudged how people are reacting to the attempted assassination. We don’t want Trump killed, but we are not coming together over this to support him. Anyway, let’s continue:

Btw, this week, get 1 shirt for $4 (normally $19).

I suggest buying one that shows you support Trump.

This whole email crosses a line. It’s inappropriate. It’s elevating his personal opinion to put it right in our face. I’m not going to use Sticker Mule again because now I know my money is used in part to send what are effectively promotional emails for a convicted felon, a candidate who is unfit for the presidency.

Same thing with Elon Musk, who said this week he will donate $45 million each month to a pro-Trump super PAC. He will also relocate SpaceX to Texas because he doesn’t like California’s politics. Twitter X is a disaster regardless, full of hate and misinformation, and I’ll be staying away from the platform.

I think about my own blog too, where I’ve frequently written about politics. No one who reads my blog will be surprised that I’m going to vote a straight Democratic ticket in November. I don’t think I’m a hypocrite on this. While I will try to balance the tone in my posts on very divisive issues — writing about the war in Gaza was challenging — it is my personal blog. There’s a difference between what I post on manton.org and what I post on news.micro.blog, or what I send to customers in email.

Micro.blog customers do read my blog, but my account is not auto-followed. If someone is annoyed with my posts, they should be able to ignore them and still be a happy customer.

Maybe that’s the advice for Anthony and Sticker Mule: get this crap out of your company messaging. On a personal blog you can write about a range of topics. Folks who dislike your politics can choose to stay away. But spare us the lecture on Trump and unity, and leave it out of your emails.

John Gruber blogs that it’s the guns:

The truth is that our nation, great though it is in so many ways, has a horrific history of political violence and a seemingly innate obsession with firearms. […]

Tomorrow morning Chuck Schumer should put on the floor of the Senate a law mandating strict background checks for all gun purchases. Perhaps tie it to a reinstitution of the 1994 assault weapons ban that Republicans allowed to expire in 2004.

AR-15s shouldn’t be legal. Here in Texas, the minimum age to buy one is still only 18, despite families in Uvalde pushing to raise the minimum. The velocity of a bullet from an AR-15 is ridiculous and multiple rounds can be fired quickly before anyone even notices. Trump is extremely lucky that it just barely grazed him.

A couple years ago on the train, I had lunch with a random passenger. Amtrak will often sit people together for meals. This passenger loved the outdoors, camping and hunting, and he said something that will always stick with me: he doesn’t use such powerful semi-automatic weapons for hunting because they do too much damage to the animal.

We shouldn’t be okay with these weapons of war having become so commonplace. It’s tragic.

I have mixed feelings about where we go in the Democratic party. I think I’ll be relieved if Biden steps aside because it resets everything about this campaign. The people voted for Kamala Harris too and she will be able to articulate the message against Trump more clearly.

On the other hand, Biden has been a very effective president. He never gets the credit he deserves, and this post-debate rollercoaster is no exception.

I was thinking about one line from his interview last Friday. Asked about Mark Warner assembling senators to convince Biden to drop out:

Mark is a good man. […] He also tried to get the nomination too. Mark and I have a different perspective. I respect him.

Now imagine Trump being asked that question. Trump only cares about himself so he’ll quickly attack any perceived disloyalty. Maybe that difference in respect is partly why Biden has been so effective with bipartisan legislation. He’s been around a while. He’s pragmatic.

After the interview, I watched John Fetterman answer questions about his support for Biden. When Fetterman makes up his mind about something, he sticks with it. He couldn’t care less what you think and I sort of love that about him:

Donald Trump is back, and what do Democrats do? We panic and piss our pants. After a bad debate and after 34 convictions — felonies — the Republicans show up and they dress like him and go all-in on Trump.

Maybe we could learn something here and just say, “Stand by our president through this.” After 50 years, and after almost four years as a great president, I think he’s entitled to make his case after a debate that we can all agree was rough. But I know what that’s like. I am not the sum total of a bad debate, and certainly the President isn’t either.

Last week I grew increasingly frustrated with the opinions section of The New York Times. It felt like half their home page was opinion, overshadowing the actual reporting. I cancelled my subscription. There are many places on the web to read opinions. More than ever, we need major news outlets to focus on reporting, not influencing. (I’m going with The Washington Post for a little while. Let’s see how they do.)

People are worried that Biden might lose. Good, be worried. If more people were worried in 2016, Hillary would be wrapping up her 2nd term right now.

Many of the hot takes about fair use for AI training are either “AI is stealing content” or “everything on the web is free”, but the discussions in between those extremes are more interesting. Let’s explore it with a thought experiment. This blog post isn’t a declaration that I’ve figured it all out. It’s just to get us thinking.

First, review how blogging and fair use has worked since the beginning of the web. Every day I read a bunch of news articles and blog posts. If I find something I want to write about, I’ll often link to it on my blog and quote a few sentences from it, adding my own comment. Everyone agrees this is a natural part of the web and a good way for things to work.

An example outside the web is Cliff Notes. Humans can read the novel 1984 and then write a summary book of it, with quotes from the original. This is fine. It also indirectly benefits the original publisher as Cliff Notes brings more attention to the novel, and some people pick up their own copy.

Now, imagine that C-3PO is real. C-3PO is fluent in six million forms of communication, and he has emotions and personality quirks, but otherwise he learns like the rest of us: through experience.

C-3PO could sit down with thousands of books and web sites and read through them. If we asked C-3PO questions about what he had read, and then used some of that in our own writing, that seems like fair use of that content. Humans can read and then use that knowledge to create future creative works, and so can C-3PO. If C-3PO read every day for years, 24 hours a day, gathering knowledge, that would be fine too.

Is that different than training an LLM? Yes, in at least two important ways:

• Speed. It would take a human or C-3PO a long time to read even a fraction of all the world’s information.
• Scale. Training a single robot is different than training thousands of AI instances all at once, so that when deployed every copy already has all knowledge.

Copyright law says nothing about the speed of consumption. It assumes that humans can only read and create so much, because the technology for AI and even computers was science fiction when the laws were written. Robots and AI cannot only quickly consume information, they can retain all of it, making it more likely to infringe on a substantial part of an original work.

Maybe copyright law only applies to humans anyway? I don’t know. When our C-3PO was reading books in the above example, I doubt anyone was shouting: “That’s illegal! Robots aren’t allowed to read!”

The reality is that something has fundamentally shifted with the breakthroughs in generative AI and possibly in the near future with Artificial General Intelligence. Our current laws are not good enough. There are gray areas because the laws were not designed for non-humans. But restricting basic tasks like reading or vision to only humans is nonsensical, especially if robots inch closer to actual sentience. (To be clear, we are not close to that, but for the first time I can imagine that it will be possible.)

John Siracusa explored some of this in a blog post earlier this year. On needing new laws:

Every new technology has required new laws to ensure that it becomes and remains a net good for society. It’s rare that we can successfully adapt existing laws to fully manage a new technology, especially one that has the power to radically alter the shape of an existing market like generative AI does.

Back to those two differences in LLM training: speed and scale.

If speed of training is the problem — that is, being able to effectively soak up all the world’s information in weeks or months — where do we draw the line? If it’s okay for an AI assistant to slowly read like C-3PO, but not okay to quickly read like with thousands of bots in parallel, how do we even define what slow and quick are?

If scale is the problem — that is, being able to train a model on content and then apply that training to thousands or millions of exact replicas — what if scale is taken away? Is it okay to create a dumb LLM that knows very little, perhaps having only been trained on licensed content, and then create a personal assistant that can go out to the web and continue learning, where that training is not contributed back to any other models?

In other words, can my personal C-3PO (or, let’s say, my personal ChatGPT assistant) crawl the web on my behalf, so that it can get better at helping me solve problems? I think some limited on-demand crawling is fine, in the same way that opening a web page in Safari using reader mode without ads is fine. As Daniel Jalkut mentioned in our discussion of Perplexity on Core Intuition, HTTP uses the term user-agent for a reason. Software can interact with the web on behalf of users.

That is what is so incredible about the open web. While most content is under copyright by default, and some is licensed with Creative Commons or in the public domain, everything not behind a paywall is at least accessible. We can build tools that leverage that openness, like web browsers, search engines, and the Internet Archive. Along the way, we should be good web citizens, which means:

• Respecting robots.txt.
• Not hitting servers too hard when crawling.
• Identifying what our software is so that it can be blocked or handled in a special way by servers.

This can’t be stressed enough. AI companies should respect the conventions that have made the open web a special place. Respect and empower creators. And for creators, acknowledge that the world has changed. Resist burning everything down lest open web principles are caught in the fire.

Some web publishers are saying that generative AI is a threat to the open web. That we must lock down content so it can’t be used in LLM training. But locking content is also a risk to the open web, limiting legitimate crawling and useful tools that use open web data. Common Crawl, which some AI companies have used to bootstrap training, is an archive of web data going back to 2008, often used for research. If we make that dataset worse because of fear of LLMs misusing it, we also hurt new applications that have nothing to do with AI.

Finally, consider Google. If LLMs crawling the web is theft, why is Google crawling the web not theft? Google has historically been part of a healthy web because they link back to sites they index, driving new traffic from search. However, as Nilay Patel has been arguing with Google Zero, this traffic has been going away. Even without AI, Google has been attempting to answer more queries directly without linking to sources.

Google search and ChatGPT work differently, but they are based on the same access to web pages, so the solutions with crediting sources are intertwined. Neither should take more from the web than they give back.

This is at the root of why many creators are pushing back against AI. Using too much of an original work and not crediting it is plagiarism. If the largest LLMs are inherently plagiarism machines, it could help to refocus on smaller, personal LLMs that only gain knowledge at the user’s direction.

There are also LLM use cases unrelated to derivative works, such as using AI to transcribe audio or describe what’s in a photo. Training an LLM on sound and language so that it can transcribe audio has effectively no impact to the original creators of that content. How can it be theft if there are no victims?

I don’t have answers to these questions. But I love building software for the web. I love working on Micro.blog and making it easier for humans to blog. Generative AI is a tool I’ll use when it makes sense, and we should continue discussing how it should be trained and deployed, while preserving the openness that makes the web great.

Everyone who has implemented ActivityPub from scratch knows that there are implementation-specific quirks that trip up developers, making compatibility between apps more difficult. Some of these issues are being clarified by the Social Web Community Group. Test suites will help too. Micro.blog has had ActivityPub support for years and we’re still finding edge cases.

With Ghost making progress on adding ActivityPub, I tried following their first test account today and immediately ran into a small issue. It’s simple so I think illustrates the kind of problem that developers might hit. You only need to know what JSON looks like to follow along.

When you download an actor’s profile, you get a bunch of fields like the inbox to send requests to, the user’s full name, and the user’s profile photo. The photo is set in a field called icon (or image). If you skim through the ActivityPub specification, you’ll see this example:

"icon": [
  "https://kenzoishii.example.com/image/165987aklre4"
]

Pretty simple. The field is an array with a single URL to the image. But most implementations don’t follow that example. Mastodon and Micro.blog both use something like this, which is in the more complete ActivityStreams spec:

"icon": {
  "url": "https://micro.blog/manton/avatar.jpg",
  "type": "Image",
  "mediaType": "image/jpeg"
}

Which one is correct? Both, of course! Back to the ActivityPub documentation for icon:

A link to an image or an Image object which represents the user’s profile picture

Now let’s check out what Ghost is doing:

"icon": "https://ghost.org/favicon.ico"

This is a third variation of the same field, this time using a simple URL value. Not an array and not an object with multiple fields.

As programmers, we often try to follow Postel’s law: “be conservative in what you do, be liberal in what you accept from others”. In other words, we should gracefully handle all these different JSON responses, but we should only send out the best one, the one that is documented by the standard. And yet the standard is itself not very explicit about this.

I’m not attempting to blame anyone for this. Certainly not Ghost who has just barely got their implementation up and running and will likely have many changes coming in the next few months. But if you imagine this icon variation spread out across the whole suite of specs — not just ActivityPub but ActivityStreams, WebFinger, HTTP Signatures, and others, with potentially dozens of minor differences — you see why interoperability has sometimes been a challenge.

Jeremy Keith follows up on fighting AI bots, quoting a couple things I’ve said. He closes with:

There is nothing inevitable about any technology. The actions we take today are what determine our future. So let’s take steps now to prevent our web being turned into a dark, dark forest.

I agree with these statements in isolation. Maybe what we disagree on is whether AI is inherently destructive to the web, so all AI bots should be stopped, or whether we can more narrowly minimize AI slop from spreading.

Even without AI, Google referrers to blogs have also been going down, with Nilay Patel arguing that we are heading to Google Zero. In other words, Google is already taking more from the web than they are giving back.

The solution to that is Google alternatives that get us back to the style of old-school search engines: “10 blue links”, with a focus on real blogs and news sites, weeding out content farms and other spam shenanigans. We have spammers creating accounts in Micro.blog every day, trying to pollute the open web. It’s depressing. I want to create more tools that highlight human-generated content, like the audio narration we added.

Jeremy didn’t quote one of my responses about trying to insert text into posts to confuse bots, so I’ll add it here for completeness. I replied with:

I think it’s a bad precedent. It’s already hard enough for legitimate crawling because of tricks that paywalls use, or JavaScript that gets in the way. Mucking up text and images is bound to create problems for non-AI tools too. There’s gotta be a better way to address this.

I viewed source to see how Jeremy is handling this on his blog. His technique doesn’t appear to be causing any problems with Micro.blog’s bookmarking, which saves a copy of the text in a blog post for reading later, because the prompt injection is outside the <article> and h-entry for the post. But it’s not hard to imagine a well-behaved, non-AI bot getting tripped up by this.

I don’t think technological determinism is an appropriate summary of my thoughts. There are a bunch of questions to resolve around generative AI, for sure, including rogue bots, but there’s a lot of potential good too.

Jason Snell makes the case for hand controllers and other changes to the Vision Pro:

I’ve got a Vision Pro and a Meta Quest 3. And yet the Quest 3, which costs about one-seventh of the price of the Vision Pro, is a vastly superior platform when it comes to playing certain kinds of games. Games just require precision positioning (through detailed movement tracking), and input (via on-controller buttons) that waving your hands and tapping fingers together in Vision Pro just can’t match.

Jason has good ideas for improving Vision Pro, but I think the problem is more fundamental than that. visionOS is a bust.

Most users don’t want to strap a computer to their face. Most developers don’t want to dedicate time to redesigning their apps. Some people love the Vision Pro, and that’s great for them, but it’s not a mainstream product.

I said on Core Intuition last year that it will be 20 years before technology catches up to Apple’s vision of spacial computing, with normal-looking AR glasses that can do most of what the Vision Pro can do. I think there will be compelling AR glasses before then, but they won’t run visionOS as we know it today.

As I blogged about when I said Apple needs a flop:

Maybe we’re at a crossroads for the company. Apple was great as the underdog, when they were humbled, fighting to out-innovate the competition. What came after the Lisa? The Macintosh. After almost going bankrupt? Think Different and the iMac. After the butterfly keyboard? Some of the best MacBooks ever made.

Apple has lost something on the path to becoming a $3 trillion company. They’re not going to get it back, because it’s something that’s hard to define, something that slips through your fingers when you try to do too much. The larger a company gets, the less capable they are of reaching beyond obvious products. The iPod formula of “we’re not first, but we’re the best” is no longer working. Everyone else is innovating too.

I said this year that we’re at “peak Apple”, and I still believe it:

Apple has been an inspiration for me for 30 years. A massive success. I think this is as good as it gets for them. They are simply too big to fundamentally rethink anything for what’s next.

There may never be another company like Apple. Still, I hope there’s room somewhere under the boots of the mobile duopoly for a new upstart. A product that is built natively for the open web, with a new take on how devices can be part of our lives, untethered from Apple and Google. If I squint a little I can almost see it happening.

Nick Heer on the latest DMA news and UTM rejection:

Perhaps there are legitimate security concerns in the UTM emulator. The burden of proof for that claim rests on Apple, however, and its ability to be a reliable narrator is sometimes questionable. Consider the possible conflicts of interest in App Tracking Transparency rules raised by German competition authorities.

Apple’s handling of the App Store is getting so old. It’s exhausting that there is always drama, always bad faith efforts, always two steps forward, one step back. Here’s what I blogged 13 years ago:

Apple, want to charge 30%? Go for it. Want to make the submission rules more strict? Fine. Want to adjust how you run the App Store to reflect what’s happening in the market? No problem. Just give developers an out. We are going to be back here year after year with the latest controversy until exclusive app distribution is fixed.

Maybe nothing I’ve written in 20 years of blogging has proven more true than that statement. Enough already! Just let us build apps that customers want and distribute them outside the store without gimmicks. That’s what the DMA is about and Apple knows it.

Excellent post by Jason Snell on the upcoming era of orchestrated apps, where much of what we do with our iPhone might be using AI as a bridge between multiple apps and their local data:

When everything is orchestrated properly, all the capabilities of all your apps are put into a big soup, and the AI system at the heart of your device can choose the right capabilities to do what you need it to do—without you having to specify all the steps it needs to take to get there.

This is a good strategy for Apple because it leverages their strengths with privacy and a complete ecosystem of apps. However, there’s a problem, something I’ve written about a few times including recently in this post about Siri before WWDC. What if you want the same functionality on your HomePod? Or on your Mac that doesn’t have the same apps installed? App intents are local to each device, potentially creating a disjointed experience when not at your iPhone.

If an assistant doesn’t have consistent functionality everywhere, something in the illusion is broken. Apple’s solution can still be good, but I think it will always come up a little bit short. (They may make up for it by having an overwhelming advantage in third-party apps that use intents, and the fact that most people’s computing is predominantly or only on their phones anyway.)

A different take would be for the apps and intents to be synced with the cloud, so that they are universally available to your assistant from all devices. There are privacy trade-offs on this path, but I think ultimately it’s where many people will want to go.

Google is probably best positioned for this alternative, more cloud-based approach to AI. They already have your private email, and I’m not sure most people consider whether it’s encrypted or just sitting around on Google servers. I wouldn’t rule out OpenAI either, since something like this is clearly part of their vision. Whoever it is, I could see Apple and another company rising to become a new sort of duopoly for AI. Apple as the private, mostly on-device option, and someone else as the always available, cross-platform assistant.

One thing I didn’t appreciate before this year’s WWDC is how limited Apple’s on-device models could be. Apple is going for easy wins and generally not biting off more than they can chew. Summarizing or rewriting text is something LLMs are great at, with almost no risk for getting derailed with hallucinations. So it shouldn’t have been surprising that Apple is doing so much themselves with their own models, and punting to ChatGPT for what Craig Federighi called “broad world knowledge” that is beyond Apple’s own models.

The only thing that struck me as strange in the WWDC keynote was image generation. I didn’t expect Apple to do that and I still don’t see why they needed to. It opens up a can of worms, something that was discussed well on this week’s episode of Upgrade. See the chapter on “AI feelings”.

The rest of the strategy is really good, though. The on-device models are small, but they can be supplemented with cloud models for more advanced tasks. And because it will be transparent to the user whether a local or cloud model is used, Apple can add bigger models to newer iPhones as RAM increases, for example, and the user won’t know the difference. Tasks will just become faster and more sophisticated.

This does require the user’s buy-in on Apple’s premise: that “private cloud compute” is just as secure and private as on-device data. On first glance this doesn’t seem technically true. As soon as the data leaves the device, you’re in a different world for things to go wrong. But Apple has built up a lot of trust. If user’s accept the private cloud — and, importantly, if users even realize that Apple’s cloud is completely different than OpenAI’s cloud — it gives Apple a new strength that others don’t have, even if that strength is propped up mostly on goodwill.

Personally I have no concern with the cloud approach for my own personal data. I expect Apple’s solution to be robust, likely bordering on over-engineered for what it actually needs to do, but that builds confidence.

Ben Thompson is optimistic about Apple’s AI strategy too. From a daily update on whether other companies could displace iOS:

I’m unconvinced that large language models are going to be sufficiently powerful enough to displace iOS, and that Apple’s approach to productize LLM capability around data that only they have access to, while Aggregating more powerful models, is going to be successful, but time will tell. Relatedly, the speed with which a wide array of model builders delivered useful models both gives me confidence that Apple’s models will be good enough, and that there isn’t some sort of special sauce that will lead to one model breaking away from the pack.

I’m not sure. There is no telling whether there will be another GPT-level advance in a couple years. Already OpenAI has some technologies like the voice matching that are so powerful that OpenAI almost seems scared to even release them. If there is a breakthrough, it may be difficult for other companies to replicate it right away, giving a single player a years-long advantage.

At the same time, there is just enough friction in Apple Intelligence that even with the improvements to Siri, it may feel slightly crippled compared to a hypothetical new voice assistant. As I wrote in a blog post before WWDC:

While it’s true that the iPhone will continue to dominate any potential non-phone competition, I think there is a narrow window where a truly new device could be disruptive to the smartphone if Apple doesn’t make Siri more universal and seamless across devices. This universality might sound subtle but I think it’s key.

It’s unlikely for Apple to be displaced. People love their phones. I think there is still an opening for something new — a universal assistant that works everywhere, can do nearly everything, and is a joy to use. But we may never get there, or “good enough” may be fine, in which case Apple is really well-positioned.

This is a pretty simple one, another addition to my blog post series about upgrading my Honda Element. These rain guards attach above each window, so you can crack the window while it’s raining and not get water in the car. They just stick on, but they seem surprisingly sturdy.

Siri is much too limited and inconsistent. The only time I ever use Siri is when driving, for responding to text messages and dictating notes. Many people will have different use cases, and so when people say “Siri sucks” they probably all mean different things.

There are many things that could be improved in Siri, but to me it all comes down to just two fundamental shifts:

Universal Siri that works the same across all devices.

The illusion of Siri as a personal assistant is broken when basic tasks that work from your phone don’t work from your watch or HomePod. I’ve long thought and discussed on Core Intuition how Apple has tied Siri too closely to devices and installed apps.

That’s not to say that controlling installed apps isn’t useful, in the way that Shortcuts and scripting are useful. I expect Apple to have more of that at WWDC next week. But in addition to extending Siri with installed apps, to make it truly universal there should be a way to extend Siri in the cloud, just as Alexa has offered for years.

Standalone devices like the Human AI Pin and Rabbit R1 have been criticized as “that should be an app”. While it’s true that the iPhone will continue to dominate any potential non-phone competition, I think there is a narrow window where a truly new device could be disruptive to the smartphone if Apple doesn’t make Siri more universal and seamless across devices. This universality might sound subtle but I think it’s key.

Large language models.

This is obvious. Talking to ChatGPT is so much more advanced and useful than current Siri. With ChatGPT, you can ask all sorts of questions that Siri has no clue about. Sure, LLMs are wrong sometimes, and I’d love for Siri to be uncertain about some answers. If there was a way to have some kind of weighting in the models so that Siri could answer “I’m not sure, but I think…” that would go a long way to dealing with hallucinations. Generative AI is less like a traditional computer and more like a human who has read all the world’s information but doesn’t really know what to do with any of it. That’s okay! But we wouldn’t blindly trust everything that human said.

There are many other improvements that would come along with using even medium-sized LLMs on device for Siri, such as dictation. OpenAI’s Whisper model is almost 2 years old now and way better than Siri.

Apple is going to talk a lot about privacy and on-device models at WWDC. A dual strategy for LLMs is the way to go, with models on your phone that can do a bunch of tasks, but some kind of smarts to switch gears to using LLMs in the cloud when necessary. I’ve done a bunch of experiments with open-source LLMs on my own servers, and it requires a lot of RAM and GPU to get reasonable performance. If we use “parameters” as a rough metric for how much horsepower LLMs need, note that Meta’s Llama 3 (which is pretty good!) is a 70 billion parameter model. GPT-4 is rumored to be nearly 2 trillion parameters. If Apple can’t get GPT-4 level quality and performance on device, they should not hesitate to use the cloud too.

Looking forward to WWDC next week! Should be a good one.

I’ve blogged before about AI hallucinations, but I wanted to tie together a few new posts I’ve read recently. Let’s start with Dave Winer:

To people who say you get wrong answers from ChatGPT, if I wanted my car to kill me I could drive into oncoming traffic. If I wanted my calculator to give me incorrect results I could press the wrong keys. In other words, ChatGPT is a very new tool. It can be hard to control, you have to check what it says, and try different questions. But the result, if you pay attention and don’t drive it under the wheels of a bus, is that you can do things you never could do before.

This is essentially my mindset too. AI makes mistakes. Humans make mistakes. The key is to know what AI is good for and to not let it run wild unattended. This is why with Micro.blog we’ve been so focused on very limited use cases:

• Podcast transcripts, for which AI is shockingly good. Gotta be close to 99% perfect, and it’s easy to edit transcripts to fix mistakes.
• Summarizing bookmarked web pages, also really accurate. I’ve yet to see any mistakes.
• Photo keywords and accessibility text. Super useful and if it occasionally gets something slightly wrong, it’s usually inconsequential and still a huge step forward.

On a recent SharpTech podcast, Ben Thompson also makes this point that we have different expectations for computers and humans. We expect computers to always be right. Calculators and spreadsheets don’t lie. But generative AI is something new, and we can’t hold it to the same standards we had before.

That’s not necessarily to say you’re holding it wrong if you ask Google how many rocks to eat. It’s up to AI companies to better convey when assistants aren’t sure about an answer. I don’t know if this is technically possible with how today’s models work, but hopefully folks are looking at it.

Finally, Allen Pike had a post this week that was fascinating, about how AI will evolve now that it has chewed up all the data on the internet. I have mixed feelings about this… There’s a lot of uncertainty, and also I don’t love that we might be improving AI models while neglecting making the web better. But it is still too early to really judge how this is going to play out.

In a blog post about Journal, John Gruber makes a detour to highlight the lack of full import and export in Apple Notes:

I worry that import and export aren’t priorities for Apple. Apple Notes can import RTF and plain text files, but its only option for exporting is, bizarrely, PDF — which is a file format Notes can’t import. A good system for import/export would allow for full fidelity round-tripping. You should be able to export to a file or archive format that Notes can also import, without losing any formatting, metadata, or image attachments. Notes doesn’t even try.

That’s a no-go for me. I’m now using Micro.blog for notes, and I wouldn’t even consider anything without Markdown import and export. Of course Apple isn’t going anywhere and I expect Notes to be supported essentially forever in some form, but iCloud sync is opaque. If there’s ever a hiccup, I want a backup of the actual plain text files.

Six years ago, we launched our $10/month plan with podcast hosting. Since then we’ve added several big features to the plan, which is now called Micro.blog Premium:

• Create up to 5 blogs, each with its own domain or subdomain
• Email newsletters, to send automatically whenever you blog
• Bookmark web pages, with archiving and content summaries
• Make highlights in web pages, to search or blog about
• Tags for bookmarks
• Notes and journals, plus our companion app Strata
• Share short videos

Today, I want to bring the podcast feature to more people, so we’re moving it down to the standard $5/month plan. The new audio narration for posts and podcast feeds remind me of how much fun it can be to have your own blog, to experiment and try new forms of content at your own space on the web. Let’s do more of it.

Manu Moreale writes about the ratio between consuming content and creating it:

I believe people should consume less content and produce more. Finding an output for creativity is important. But it’s unreasonable to expect people to stop consuming content and replace that consumption with creation because the ratio will always be inevitably skewed towards consumption.

It’s a good post and while I’ve never tried to measure this ratio for myself, I like the way Manu blogs about it. I’m going to take that topic and expand it in a slightly different direction.

It also matters what we consume. If we read too much social media, what happens is that most of the consumption is headlines and opinions, not the facts behind the headlines. It’s retweets, short quotes, and TikToks, not longer blog posts and stories.

It’s usually obvious when reading all the takes on the internet who actually knows something and has formed their own opinion, and who has been influenced by whatever the current consensus is on social media. Starting with other peoples' opinions is like reading a newspaper’s op-ed first and then the front page. Everything we read afterwards will be influenced by those opinions.

When I quit Twitter in 2012, I essentially threw away any audience I had built and started over. I could feel the loss of community. But I also began to notice that my ideas felt just a tiny bit more unique. Not earth-shatteringly original, but definitely my own.

Last week I blogged about adding audio narration to blog posts. For years we’ve also had full podcast hosting, which overlaps with this narration feature but is focused on podcast episodes and feeds. In this post I’ll show how to add narration to an existing blog post, hopefully in the process revealing more about how this works in Micro.blog.

First, record yourself reading the blog post. There are a dozen ways to do this. Make sure to save the file as an MP3.

Upload the MP3 to Micro.blog. You can do this on the web in the Uploads section, or one of the native apps. All the apps also have some form of Copy HTML button to get an HTML audio tag for the upload. It will look something like this:

<audio src="…" controls="controls">

Before we paste this into the edited blog post, we actually want to hide the default audio player that would appear in web browsers. To do this, add a style attribute:

<audio src="…" controls="controls" style="display: none">

If the audio player is hidden, what’s the point? Micro.blog sees the tag anyway. It also knows the duration of the audio, so it can make a guess as to whether this is a narrated version of the blog post. If it is, it skips some features such as adding a link to the transcript of the audio. (Because the blog post text you wrote is already the best transcript.)

Note that to turn a blog post into a podcast episode or narrated post, all that’s needed is the audio tag. This is because Micro.blog natively thinks about posts as HTML. Photo posts have an img tag, audio posts have an audio tag, and so on. When Micro.blog publishes your blog post, it parses the HTML and sets up any metadata that is needed, for example to access from within Hugo.

When you write a new post and include audio at the time of posting, not later, Micro.blog handles managing the audio tag for you, including the CSS to hide posts that are audio narration. Later, we plan to improve the editing interface so this is more seamless too.

This feature went from idea to implementation quickly because it turns out we already have full podcast hosting in Micro.blog! How convenient. I’m going to use this post to break it all down.

AI is everywhere, including some places it probably shouldn’t be. If you’ve been following my blog you know that I see huge potential in generative AI. We’re using it in Micro.blog to improve photos search and accessibility text for photos. But like many tools, AI is going to be overused before we all find the right balance for what it’s good at.

When Jean and I were talking to Christina Warren at Micro Camp, I asked Christina about a talk she gave at Çingleton about 10 years ago. I actually blogged about it at the time. What struck me as particularly relevant now as we’re about to be swamped with AI-generated content is that there’s no substitute for the human voice. I don’t just mean that an actual recording is better than a synthetic voice. I also mean that things that are created by humans will increasingly be sought out.

We want to see the personal side of someone, not just the polished brand. We want to see the imperfect, the creative, the emotion. We want authenticity.

In Micro.blog, you can now upload an audio recording of one of your blog posts. Use the audio icon in the new post form on the web, which is available to everyone starting today, even at the standard $5 plan. Your blog readers can listen to the audio narration of the post if they don’t feel like reading the post. Of course it’s especially great for the visually impaired.

Here’s what it looks like on my blog, next to the posted date. Shout-out to Medium which I drew some inspiration from.

I’m also adding audio narration to this very blog post, so you can click over to the web to try it out.

When there’s audio attached to a post, Micro.blog attempts to check if it is probably the narration for a post. If the number of words in the post and the audio duration is roughly comparable to how long it would take a human to read the post, it assumes it’s narration and not a podcast. Podcast episodes are more likely to be longer with very short “show notes” in the actual blog post text.

Micro.blog checks this so that it can hide the default audio player and transcript link. These would add clutter to normal blog posts.

Blog themes will still need to be updated to support the play button. I’ve already updated the Alpine theme and will update others later. Themes can use a new API called Narration.js. Just plop this JavaScript anywhere you want the play button in your template, likely the layouts/post/single.html file. (Note that this currently needs to be on the permalink page. It won’t work correctly on the home page with a list of blog posts yet.)

{{ with .Params.audio }}
  <script type="text/javascript" src="https://micro.blog/narration.js?url={{ . }}"></script>
{{ end }}

If you’re using Micro.blog Premium, the audio narration will also be included in the podcast feed. Any blog can effectively be a podcast, even if you don’t think of it as a traditional podcast. Some of my favorite writers have had great success with a dual model of email newsletter plus podcast version of the same content, like Ben Thompson and Molly White.

I can’t wait to see how people use this. It’s totally optional. It’s more work, and not everyone is going to want to do that extra work. I’m imagining this would be used for selective, special blog posts, rather than everything. I’m also interested in working this functionality into our companion app Wavelength, which should cut down on the technical steps.

In some ways, this feature isn’t actually about what is possible. This feature is a statement: we make things for humans, so they can make the web a little better. Along the way there will be plenty to automate, plenty of AI tools that will be important shortcuts, but we’re not going to lose our voice.

Just finished listening to this interview on Stratechery with Satya Nadella and (separately) Kevin Scott. Some really thoughtful points about how Microsoft sees things around AI.

I liked this segment from Kevin especially, after talking about how humans can no longer beat computers at chess, yet we still love to watch humans play chess against each other:

I don’t think the AI is going to take over anything, I think it is going to continue to be a tool that we will use to make things for one another, to serve one another, to do valuable things for one another and I think we will be extremely disinterested in things where there aren’t humans in the loop.

I think what we all seek is meaning and connection and we want to do things for each other and I think we have an enormous opportunity here with these tools to do more of all of those things in slightly different ways. But I’m not worried that we somehow lose our sense of place or purpose.

Tonight the Washington Post has what looks like an exclusive story on OpenAI’s Sky voice. I didn’t want to keep writing about this, but here we are. Some quotes from the article:

…while many hear an eerie resemblance between “Sky” and Johansson’s “Her” character, an actress was hired to create the Sky voice months before Altman contacted Johansson, according to documents, recordings, casting directors and the actress’s agent.

The actress’s agent spoke to the Washington Post:

The agent, who spoke on the condition of anonymity to assure the safety of her client, said the actress confirmed that neither Johansson nor the movie “Her” were ever mentioned by OpenAI. The actress’s natural voice sounds identical to the AI-generated Sky voice, based on brief recordings of her initial voice test reviewed by The Post.

And from Joanne Jang, who worked at OpenAI with the actors:

Jang said she “kept a tight tent” around the AI voices project, making Chief Technology Officer Mira Murati the sole decision-maker to preserve the artistic choices of the director and the casting office. Altman was on his world tour during much of the casting process and not intimately involved, she said.

There was also a statement from the actress who voiced Sky:

In a statement from the Sky actress provided by her agent, she wrote that at times the backlash “feels personal being that it’s just my natural voice and I’ve never been compared to her by the people who do know me closely.”

Maybe we haven’t heard the last of this story and more news will drop. Even if it wasn’t intentional, there may be a legal case against OpenAI. But it appears that my initial take was correct.

I’ve been rolling this whole saga over in my mind since I first blogged about it. People are clearly concerned about AI generally and OpenAI specifically. There is also too much misinformation and divisiveness on social media, and a loss of nuance. When the narrative turns against a company, everything that follows will be viewed through a different lens, as if slightly distorted.

I posted a series of microblog posts yesterday with a common theme of trying to understand what is going on with OpenAI. This is a company with a lot of drama, nearly imploding last year with the board and CEO shakeup, and more recently alternating between amazing demos and dumb mistakes.

I got a lot of pushback about one of my posts in particular. I’m even seeing people want to leave Micro.blog because of it. This is disappointing to me, especially since I think I’ve gone out of my way to have a balanced approach to AI. We have a global setting to disable everything that uses AI in Micro.blog, for people who are against the technology on principle.

Here are the relevant posts from yesterday so you can see them more in context:

When your company becomes the enemy, all that matters to people is what feels true. OpenAI’s Sky voice shipped months ago, not last week. We hear what we want to hear. OpenAI mishandled this, no question, but most likely Her is ingrained in Sam’s head vs. intentionally ripping off Scarlett.

In the last 35 years, there have been a tiny number of truly revolutionary technologies that change everything: the web, mobile, and artificial intelligence. We can fight it, or we can guide it. But trust has eroded. To succeed we have to rebuild it. Move fast and break things will be a disaster.

Any chance that WWDC will have a live keynote this year? In the last couple weeks, we’ve had… OpenAI: live. Google I/O: live. Microsoft: live. To balance AI we need to lean in to human creativity, and a pre-recorded 2-hour advertisement will never feel as alive or engaging as a human on stage.

As someone who usually supports OpenAI, I’d still welcome an actual lawsuit from Scarlett Johansson about the voices. For one, I’m a huge fan of hers, but also I’d genuinely like to know if anything shady happened at the company. Dishonesty will cast a shadow over everything the API touches.

I also tried to clarify a few things in replies on those blog posts to other people’s points:

Sam was clearly inspired by and obsessed with Her. I don’t think it was subconscious, but that also doesn’t mean they sampled her voice explicitly.

The board firing Sam Altman is looking more and more rational. Which is why I think this should be an “all hands on deck” moment for OpenAI.

You’re right on the “total” lie, I shouldn’t have phrased it that way, because anything misleading in the OpenAI post would be dishonest. I was trying to respond to folks who are saying that when Scarlett declined to lend her voice, OpenAI copied it anyway. I don’t think that’s true. If I’m wrong, I’ll stop using any tech from OpenAI.

They already have the technology to actually clone someone’s voice, which I assume they didn’t use here because it would be an even closer match.

Did I get it wrong? For reference, here is OpenAI’s blog post about hiring actors for the voices, and Scarlett Johansson’s letter.

Perhaps I shouldn’t have blogged about this, but it’s my personal blog where I explore a range of topics. I do not run my blog posts through a PR department, and I think most people appreciate that blogs should feel authentic and human, even when they disagree.

I’ll admit I’ve only skimmed the recent “is iPadOS holding the iPad back?” posts from Federico Viticci, Jason Snell, John Gruber, and others. The iPad isn’t part of my routine now that I’m back to using the Kindle for e-books.

Apple has had a decades-long battle with window management generally and the Finder specifically. At Ease, Simple Finder, Launchpad, Stage Manager, iOS Files… But it turns out the Finder is great. You could go a long way just by replacing Files with a touch-optimized Finder.

I wrote the above and then went back to Federico’s post, where he actually highlights this same point:

After seven years, I’m starting to wonder if maybe it’s time for Apple to scrap the Files project and start over with a new app based on the strong foundation of Finder. We’re well past the point of excusing the Files app for being a young file manager; when you’re spending $3,000 on a high-end iPad Pro with plenty of storage, you want the app to manage that storage to be flawless.

Apple could do this even without turning iPadOS into a true fork of iOS. Boot the iPad into a new Finder that mostly obsoletes Springboard and Files.

Excited to announce that @kimberlyhirsh is joining the Micro.blog team. She’ll be helping part-time with curation and community. We’ve been talking to Kimberly for a while and I’m happy she can join us as @jean moves on.

I’m looking forward to working with Kimberly, and seeing what new ways we can expand the team from here. As I mentioned in my post thanking Jean for all her work on Micro.blog, I think everyone can bring something different to the company. Vincent has also been at work behind the scenes to improve the admin features in our platform, with the hope that some of it can be available to more community members.

We know the long-term vision for what we want Micro.blog to be, but exactly how we get there can still be a surprise. Thanks Kimberly for wanting to be a part of this!

This interview with Jack Dorsey provides some closure to his part of the Twitter and Bluesky story. On leaving the Bluesky board:

So I just decided to delete my account on Bluesky, and really focus on Nostr, and funding that to the best of my ability. I asked to get off the board as well, because I just don’t think a protocol needs a board or wants a board. And if it has a board, that’s not the thing that I wanted to help build or wanted to help fund.

Jack says that he respects Bluesky CEO Jay Graber, just that what they each wanted went in different directions.

Jay herself responded this week on Bluesky:

With all due respect to Jack for having the vision to invest in decentralized protocols, we’ve carried out the work in a way I don’t think he fully understands. Bluesky is structurally open in a way Twitter has never been, but the design of atproto allows it to feel familiar and easy to use.

There was also this defense of Jay from Bluesky developer Paul Frazee:

I’ve been watching Jay make consistently strong strategic decisions under incredible pressure, and watching her get dogged by this 2nd rate nonsense is too much. That guy isn’t the story. The fact Jay charted her own path is.

Personally, I still really like what Bluesky is doing. We’re continuing to add Bluesky features to Micro.blog, like being able to see and reply to Bluesky posts within Micro.blog. For the foreseeable future, the social web is not going to be a single protocol (except of course HTTP).

It’s hard to believe it has been seven years since Jean joined me to work on Micro.blog. After a few emails back and forth in early 2017, Jean and I met at Fairlane Coffee while I was up in Portland. I showed her an early version of Micro.blog and we talked about how we could work together.

Reflecting back on that day, it was a pivotal moment because it helped accelerate Micro.blog growing into its own company that could become my focus, instead of just one of several projects I was working on in my indie software company Riverfold. Micro.blog was going to need more of my time, and then some!

Jean has been an integral part of everything we’ve done since then. She created the Micro Monday podcast, organized in-person and online Micro Camps, and ran the photo challenges for the community, all on top of managing the Discover section of Micro.blog and working through community issues with me. This is perhaps the most rewarding part of working with someone else — seeing new things happen that I couldn’t have done on my own, and in some cases new ideas I had never considered.

Thanks Jean! As you move on from Micro.blog, wishing you the best of luck with your long-form writing, hopefully a little microblogging too, and whatever else is next.

In college in the 1990s, I joined the socialist student organization. I saw every issue in stark contrast — a measure of fairness and justice. If I was young on campus today, I might be protesting the war in Gaza. But even in college, truthfully I wasn’t a great activist. I remember our organization leader calling me about a protest for workers’ rights and I was too lazy that day to go.

I’m still for peace and equality today, but now I know that the world is fucking complicated. I’m less certain about things I felt so strongly about before.

Seeing everything in black and white is a mixed blessing. Seeing only the extremes leads to passion and action. But it can also blind us to more nuanced arguments. It can make us more susceptible to manipulation, caught up with TikToks and retweets that reinforce what we already believe.

Taking a step back from the protests specifically, liberals advocate for the less fortunate. We want people of all backgrounds to be treated with respect. We push back against laws that further redistribute wealth to those who don’t need it.

I think this instinct has run into problems in Gaza. War is terrible. More humanitarian aid is needed, and more military restraint. Palestinians have been struggling for decades, now they’ve been forced from their homes, children have died in bombings, and there’s a risk of famine. We want to side with them because we always default to supporting the people who most need support.

And yet polarization has twisted everything. On social media, we use the worst words possible. No words on any topic seem to go far enough, because everyone is angry about everything. Innocent people dying in war — it just doesn’t sound terrible enough for our outrage. So we reach for even more extreme words, calling to mind atrocities that have rightly been judged by history as indefensible.

Pick a side, protest, use all the hashtags, get angry, go viral. In a social bubble, everything is amplified.

I’m going to be honest, the brutality of the Hamas attack on October 7th changed my opinion on the Middle East, possibly forever. Hamas cannot stay in power. But how to remove Hamas without risking innocent life and creating a new generation of terrorists is an impossible challenge that I don’t have a solution for.

Peaceful protests are an important part of a democracy. Most of the protests have been peaceful. Unfortunately some of the protesters at a few campuses like Columbia University and UCLA have lost the plot, seeing injustice everywhere, creating chaos, justifying vandalism. I hope we haven’t become so tribal that we support that.

There is a bit of hope in the news. Earlier this week, Antony Blinken said:

Hamas has before it a proposal that is extraordinarily generous on the part of Israel. And at the moment, the only thing standing between the people of Gaza and a cease-fire is Hamas.

I hope Hamas accepts it. The hostages need to be released and even a temporary ceasefire will make it easier to ramp up more aid.

Amplified by social media outrage, it has become difficult to see the war clearly. I’m not sure how as a society we get through this. All I know for sure is that it’s going to take a long time, and we need social platforms that don’t feed on division.

✌️

I’m 48 years old. If you start counting with my paid internship in college, I’ve had a roughly 30-year career in the software industry, give or take a year. I feel extremely lucky that the web came along just as I was getting my feet wet as a developer. World-changing technologies are rare.

Timing matters. This is part of what Malcolm Gladwell’s book Outliers is about.

As I get older, I’m increasingly aware of how easy it is to become bitter and set in my ways. There are many episodes of Core Intuition where I complain about Swift or SwiftUI. Why do we need a new programming language when the old one is still perfectly fine? 🤪

The tech and startup world has had no shortage of over-hyped sidetracks. Blockchain is the most recent flop. Just because a technology is novel, doesn’t mean a practical purpose and business model will emerge.

I almost never jump on trends because you can waste so much time chasing productivity gains that you actually end up going backwards. I run my servers with old tech. I use tried and true programming languages and frameworks. I am not cutting edge.

Some people think generative AI is in the same line as other problematic new technologies, fads that come and go, leaving a string of wrecked businesses and broken apps in their wake. I understand the hesitation. We have been inundated with tech companies that don’t care about data privacy, don’t care about how energy use affects the climate, and don’t care as much about user control as they do about profit.

It is with this backdrop that I get to the point: this AI shit is real. It will change almost everything. I’m not expecting to see another truly game-changing technology for the rest of my career. This is the one.

That doesn’t mean we should move fast and break things. I’m trying to be thoughtful about this. The new photos search and accessibility feature we introduced in Micro.blog today is a first step, and perhaps we won’t take the next step for another year or longer. It’s useful today, as a tool to help people do more with their time, and that’s enough for now.

I wasn’t sure whether I felt that strongly about the TikTok bill until I read this blog post by Ben Werdmuller. I usually love Ben’s posts but I disagree with him on TikTok and the open web, so let me respond to a few points:

Ironically, banning a service from the open internet nationwide is exactly the kind of thing that China has done again and again through its Great Firewall. Rather than protect American users through the kinds of far-reaching privacy legislation that we need, government chose to address TikTok alone on the basis of what amounts to xenophobic protectionism.

I’m not convinced American privacy legislation will have much impact on a company based in China. TikTok has also long promised to host data in America — “Project Texas” — and according to recent reports the effort is largely cosmetic.

This is not a ban of TikTok. This is a focused effort to force ByteDance to sell the company, so that it can be controlled by a company with more transparency and accountability. If ByteDance refuses to sell TikTok, the app will be removed from distribution by platform gatekeepers, but there’s nothing to stop TikTok from continuing to operate and be available to Americans via the web, as long as it’s hosted somewhere else.

From HR 815, now signed into law:

Providing services to distribute, maintain, or update such foreign adversary controlled application (including any source code of such application) by means of a marketplace (including an online mobile application store) through which users within the land or maritime borders of the United States may access, maintain, or update such application.

It might even be a positive outcome for the open web by shedding light on Apple and Google’s tight control over app distribution, and showing users why Progressive Web Apps can be a good alternative solution. TikTok would potentially be slower with a poorer user experience, or maybe it wouldn’t, but the open web is not going to fall apart so easily.

It’s true that some US Senators have shown themselves to be ignorant, xenophobic, and racist, on not just this bill but a range of issues. And yet a broken clock is right twice a day.

Ben writes sarcastically:

There’s a possibility that TikTok will be used to spread propaganda, unlike every other social network

I will be the first person to criticize massive social platforms. Significant portions of my book are about exactly that. It’s a very real problem to have so much concentrated power. But as much as we might dislike how Mark Zuckerberg runs Facebook, we can be pretty confident he is not going to undermine America on purpose, quietly putting a foot on the scale with propaganda to amplify political chaos.

Scott Galloway, co-host of the Pivot podcast with Kara Swisher, was on MSNBC’s Morning Joe this week:

What might sound paranoid, but that doesn’t mean I’m wrong: I think we are being manipulated, specifically youth, who their frame for the world is TikTok. If you look at TikTok, there are 52 videos that are pro-Hamas or pro-Palestinian for every one served on Israel. I think that we’re being manipulated. I think Americans are easier to fool than to convince they’ve been fooled. But if I were the CCP, I’d be doing exactly the same thing. I think social media is sowing division and polarization in our society.

We just can’t be sure whether the algorithm is only giving people what they want or whether there’s any influence being fed into it. Ben Thompson wrote on Stratechery years ago that there is evidence that Americans should be concerned:

TikTok’s algorithm, unmoored from the constraints of your social network or professional content creators, is free to promote whatever videos it likes, without anyone knowing the difference. TikTok could promote a particular candidate or a particular issue in a particular geography, without anyone — except perhaps the candidate, now indebted to a Chinese company — knowing. You may be skeptical this might happen, but again, China has already demonstrated a willingness to censor speech on a platform banned in China; how much of a leap is it to think that a Party committed to ideological dominance will forever leave a route directly into the hearts and minds of millions of Americans untouched?

Wondering about China’s influence on the TikTok algorithm isn’t xenophobic. It’s not about the people. It’s about the leadership. In the same way we can blame Putin for the war in Ukraine and still be sympathetic and trusting of the Russian people, we can be skeptical of the motivations of the Chinese Communist Party and still respect people in China, admire their culture, and welcome Chinese immigrants to America with open arms.

And what if I’m wrong? What if it turns out there’s zero influence from the Chinese Communist Party and only pure intentions with the TikTok algorithm, as far as making a bunch of money on ads can be considered pure? TikTok is still probably a net negative for society, and I’m not going to lose sleep if their business stumbles or the bill leads to more competition in short video social networks.

I read some good blog posts this week about AI, from a range of perspectives. Micro.blog won’t be for everyone, but I do want it to appeal to folks who can’t wait for the AI-powered future and to folks who don’t think the benefits outweigh the potential harm. (And the majority who just want to blog and don’t follow the tech closely.)

Molly White has a post today about many of the good things AI can do, along with the costs and consequences of getting too wrapped up in the hype:

I’m glad that I took the time to experiment with AI tools, both because I understand them better and because I have found them to be useful in my day-to-day life. But even as someone who has used them and found them helpful, it’s remarkable to see the gap between what they can do and what their promoters promise they will someday be able to do.

Many of the most useful capabilities are actually not very exciting. As an example, for years Apple and Google have used machine learning to improve photo search, so you can find photos that include pets or buildings or concerts. Today, AI can take that kind of feature and super-charge it, with remarkably accurate photo summaries.

AI is not going to fizzle out like the blockchain. More and more software will embrace AI, in some cases going too far, sprinkling it throughout apps without any transparency into how it’s used. I could start to feel the temptation to go down that path too, which is why I took a step back to add the global AI setting this week, before we even have anything new that uses the setting.

No major feature should be so intertwined with AI that it can’t be clearly documented and controlled by the user. Humans are the ones who think, write blog posts, share photos, and join conversations. Some developers will push the limits, but not Micro.blog. AI will be a tool to help us, in narrow, practical ways, and I’m not interested in going much beyond that.

There is a lot happening around generative AI. With the continued improvements from OpenAI, expected AI features from Apple coming up at WWDC, and new devices like the Rabbit R1, we’re all going to be swimming in AI this year. Some people feel (understandably!) like they’re drowning already.

I like writing blog posts by hand, but I think AI can be a powerful tool. Micro.blog Premium currently has two AI-related features:

• When you host your podcast on Micro.blog, we’ll automatically generate a transcript of each episode, which you can edit.
• When you bookmark web pages in Micro.blog, we’ll automatically generate a short summary of the web page, which you can show on the web under the “…” button → Show Summaries.

As we add more features that are powered by AI, we need a comprehensive way to tie them together, especially for anyone concerned about privacy. To be clear, there are no plans to use AI except on public data that is already on the web, like podcasts or photos. We aren’t going to suddenly start sending your private Micro.blog notes to OpenAI for processing. (And because they are end-to-end encrypted, we couldn’t anyway.)

This is all a long introduction to announce a new, simple setting to globally control whether AI is used for anything in your account. You can find it on the web under the Account link:

For existing users, this is turned off by default unless you have previously used one of the AI features mentioned above. For example, if you have a podcast that generated transcripts, the setting is on so that the feature will continue to work. For new users who join Micro.blog starting today, it’s turned on by default. I think it’s simple and clear, but obviously we’ll be listening to feedback.

I recommend toggling the checkbox on for your account if you are at all interested in the potential for AI around things like helping with photo alt tags, search, or categorization. No new features to announce today, though.

Pretty devastating but not surprising review of Humane’s AI Pin by David Pierce at The Verge. It wraps up with some hope that this can be the first step:

I hope Humane keeps going. I hope it builds in this basic functionality and figures out how to do more of it locally on the device without killing the battery. I hope it gets faster and more reliable. I hope Humane decides to make a watch, or smart glasses, or something more deliberately designed to be held in your hand.

Brian Chen at The New York Times was a little more positive, but still pointed out the many shortcomings:

I liked the chic aesthetic and concept of the pin. It was occasionally helpful, like when it suggested items to pack for my recent trip to Hawaii. But as I wore it for two weeks, it presented glaring flaws.

Ken Kocienda has a good blog post about working on the AI Pin, how no tech product is without trade-offs, and what things might be like in the future:

I think that LLMs are an advance on par with CPUs. Decades ago, the development of the first CPUs inspired people to make operating systems and programming models and, eventually, personal computers that allowed people to take advantage of the technology without being technologists themselves. We are at a similar moment now with LLMs, and the rate of change in Ai is far beyond what we saw decades ago with PCs. We built the Ai Pin with this historical perspective in mind.

There are interesting ideas here but it feels like NewtonOS 1.0 — just a little ahead of its time. If Human has the money to iterate, it could be something. My unsolicited advice: drastically simplify, scrap the laser projection, and focus on speed. A smaller, cheaper, AI “button” that was nothing more than ChatGPT available everywhere would be really fun to use.

I’m still excited about receiving my Rabbit R1, too. I was late in the pre-order queue, so likely won’t know what the device is like until much later this year. This is the time to experiment, and I don’t think companies like Humane or Rabbit should be judged too harshly on their first attempt. We’ll see where this goes.

Lots of improvements in this release. Full release notes:

• Added new logs window to show current blog publishing status and other errors.
• Added keyboard navigation for the timeline. Up and down arrows to select posts, return key to view conversation, and command-R to reply.
• Added View menu → Go to @username command to show your profile.
• Added keyboard shortcut command-[ for back button.
• Added right-click option to delete selected upload.
• Added “…” button for selected books in a bookshelf, same options as right-click.
• Improved book cover caching.
• Improved icons and other little layout fixes.
• Fixed Markdown header color when writing a blog post.

Here’s a screenshot of the new logs window:

Perhaps the biggest change is finally some keyboard navigation for the timeline. Use the up and down arrow keys to select posts, the return key to view a conversation, and command-R to reply to a post.

Some folks on Micro.blog who also actively use Bluesky have noticed something new we’ve been rolling out over the last couple of days: Micro.blog will now look for replies on Bluesky to your blog posts, bringing them into the Micro.blog timeline. This transforms Micro.blog into a base platform to manage even more of your social interactions.

How does it work in practice? Here is the basic flow:

1. Post to your blog. With Bluesky cross-posting enabled, Micro.blog will automatically copy your post to Bluesky.
2. Someone on Bluesky sees your blog post and replies to your post. Their reply is copied to Micro.blog, showing up in the timeline and in the Mentions section just like replies from Micro.blog and Mastodon.
3. Now you reply to the Bluesky post directly within Micro.blog. Micro.blog copies your reply back to Bluesky seamlessly.

Micro.blog is effectively a universal timeline for not just Micro.blog but also ActivityPub, Bluesky, and other services. We want to make the web a little better by encouraging people to post to their own blog while still being connected to friends. That means embracing open platforms wherever they are.

Micro.blog’s timeline is not limited to just Micro.blog accounts. You can follow blogs with a domain name, Bluesky users, Threads users, and of course Mastodon users. Micro.blog has always been a sort of mashup of blogs and social networks, and as the post-Twitter world starts to take shape, you can expect Micro.blog to also become a more powerful feed reader.

It’s still early days for the next phase of the social web. I’m going to keep working on this, improving our support for Bluesky, including the eventual push toward making Micro.blog a personal data server with the AT Protocol. We’re not quite there yet but we’re getting closer.

One of the discussions at FediForum this week that was the most valuable for me was the session by Nic Clayton for FEP-9fd3. The goal is for servers to advertise what features of the Mastodon client API they can support, such as creating a poll or boosting a post. Clients could recognize if a server didn’t support a feature and hide it from the UI.

I’ve been holding off adding Mastodon client API support to Micro.blog until we have some kind of convention for this. As the fediverse grows, we’ll naturally see a wide range of servers and clients, and not all of them will exactly match the features that Mastodon supports. Micro.blog does not include public likes or boosts, for example. It would be confusing for a boost icon to just show an error message when clicked.

FEP-9fd3 attempts to solve this by listing “operations” for a server, with a versioning system. There is also the related FEP-6481 that lists “extensions” to the standard suite of ActivityStreams types. BookWyrm, for example, supports most of the standard types but also adds a book “Review” type.

I don’t think either of these is quite right for what is needed. Instead, at FediForum we discussed an idea to describe the activity and object types a server supports by name. I’m imagining the format to look something like this, in NodeInfo:

{
  "types": {
    "activities": [
      "Create",
      "Like",
      "Announce",
      "Question",
      "Move"
    ],
    "objects": [
      "Note",
      "Article",
      "Image"
    ],
    "properties": {
      "Question": [ "oneOf" ],
      "Move": [ "object", "target" ],
      "Note": [ "summary", "content", "published", "inReplyTo" ],
      "Article": [ "name", "content", "published" ]
    }
  }
}

Specifying properties would be optional. An empty array would indicate that a server supported all common properties for that object. If the “types” field was missing from NodeInfo, clients could assume a server supported everything, just as they do today for Mastodon servers. I’m not tied to this format, although I like that it’s fairly clean. There are many ways to describe this sort of thing.

Another issue is that we’re sort of mixing ActivityPub types with the Mastodon client API. The client API has its own name for things, like “statuses” instead of “notes”, and “polls” instead of “questions”. While the goal is to adapt API clients, defining this based on an existing standard makes some sense to me, and would naturally translate to the ActivityPub Client to Server API, which really should be used more often.

If there’s interest, I’d be happy to work with someone to formalize this in a FEP. It feels like an important missing piece.

I’m reading through the lawsuit document intro and skimming the rest. I only have strong opinions about the App Store and developer aspects of the case. Some of the arguments in the case about messaging apps and watches seem more flimsy to me, but perhaps good things will come from the broader scope.

Here’s a small section about the App Store:

Rather than respond to competitive threats by offering lower smartphone prices to consumers or better monetization for developers, Apple would meet competitive threats by imposing a series of shapeshifting rules and restrictions in its App Store guidelines and developer agreements that would allow Apple to extract higher fees, thwart innovation, offer a less secure or degraded user experience, and throttle competitive alternatives.

This is basically true. I don’t think Apple is obligated to make iPhones less expensive, of course, but switching costs away from iOS are significant, for developers and users, helping maintain the status quo. Competition across iOS and Android platforms is important, but competition just within iOS is important too. My complaints have always been about Apple’s exclusive control over app distribution, regardless of Android.

An antitrust lawsuit is about size. The government isn’t suing game console makers even though they control game distribution (and charge too much to developers) because game consoles are not general-purpose computers, and they sell in a small fraction of the numbers that Apple sells smartphones. For many people, an iPhone is their best computer. The scale and impact to society is on a completely different level.

Even though there is a smartphone duopoly with iOS and Android, iOS alone reaches so many hundreds of millions of people that it is effectively a market on its own. If you want to build and distribute for the most commercially viable smartphone platform, you have no choice but to follow Apple’s rules. Until Apple lets developers route around that monopoly through external payments and sideloading, there will be pushback.

Apple leadership might still see the company as the upstart, but the rest of the world sees size and power. Apple should settle the lawsuit, accept App Store changes similar to those required by the Digital Markets Act, and move on. There is no winning this once the tide has turned against you.

As Threads rolls out support for ActivityPub, Meta’s approach is to require each Threads user to manually enable fediverse integration. This was demoed yesterday at FediForum. It’s a perfectly reasonable way to start, and I think the UI that Threads has come up with looks good.

There are problems with opt-in, though, particularly around account migration. Adam Mosseri has spoken about Meta’s long-term goal to use ActivityPub to let users move away from Threads:

…this is an open protocol for social networks so that they can talk to each other, and so you can actually even move eventually your followers from one app to another…

Migrating followers will only work if the followers have enabled fediverse support. Why? The way ActivityPub account migration works, the server holding the user’s account essentially sends a “move” activity to each follower. The follower’s server then updates their reference to point to the new, external server. For Threads, this will presumably do nothing if the follower has not enabled the fediverse, because there will be no way to follow and interact with a user outside of Threads.

So if someone has 100 followers, and only 5% have enabled the fediverse, when that person migrates away from Threads to Mastodon or Micro.blog, for example, only 5 of their followers will automatically follow the new account. This will be quite a big decrease in followers and discourage Threads users from migrating.

It is still early, and I think Threads has been very thoughtful about their approach. Account migration is an area that I hope they will consider more fully. There are ramifications for mixing accounts — some with fediverse support and some without — and long-term it becomes very complicated unless Threads goes all-in on the fediverse.

Today we’re introducing a new feature: blog recommendations. This was inspired by recent interest in bringing back blogrolls, including posts from Dave Winer, his service FeedLand, the recommendations feature in Ghost, and feedback from Micro.blog users asking for new ways to discover people to follow. It’s a way to curate a list of favorite sites to link to from your blog.

Here’s a screenshot showing my current blogroll. I’m still adding people, but generally expect most blogrolls to be more limited than someone’s complete social following list.

To get started, click on Design → Edit Recommendations. By default, there is a single blogroll named “Recommendations”, but you can create additional blogrolls, for example to organize blogs in topics like “Favorite Authors” or “Technology”.

Your blogroll will be available in a few places within Micro.blog:

• Profile pages on the web will get a new “Recommended 5 blogs” link. This list can include any blog no matter where it’s hosted, and Micro.blog will attempt to link to the Micro.blog profile where possible for easy following.
• Hugo gets a new blogroll shortcode. You can use this to include your recommendations on a web page. It’s provided by a plug-in that will be automatically installed if needed.
• There’s also a plug-in for the Marfa and Alpine themes to show a blogroll in the sidebar on your home page. Check out my home page for an example. (Currently this is only visible for wide browser screens, not on mobile.)
• There’s data in Hugo for each blogroll, like .Site.Data.blogrolls.recommendations, with a name and url.

Like other features in Micro.blog, recommendations are built in an extensible way to give you control from Hugo themes, and with open file formats to connect with other platforms. Micro.blog manages updating OPML and JSON files. It also sends a webmention ping to the linked site when you add a recommendation, compatible with Ghost’s support for webmention.

I’ll be working on help pages with more examples for how this can be used. Happy blogging!

When we simplified our pricing, some folks asked if it was such a good deal for customers that we would be losing money as a company. I calculated what the initial revenue hit would be before making the decision. We decided it was worth it to make Micro.blog Premium more appealing. It would pay off in the long run.

I’ll share a couple more details for folks who are curious. Monthly recurring revenue was down about 2% as soon as the change rolled out. As I blogged about, some people who might be paying $15/month would see their cost go down to $10/month. This was in line with expectations.

The old pricing was optimized for people who might want to pay for lots of blogs, but the reality is that almost no one wants to do that. Micro.blog is for normal people, not enterprise customers. The new pricing better fits the customers we want to have. People who have a main personal blog and might want to experiment with an extra blog or two later. People like us!

Now that it has been a couple weeks, I’m even more confident that this change has been great. We’ve already seen more people upgrade to Micro.blog Premium, making up for most of the initial revenue loss. The interface for upgrading and downgrading is much easier than before. Less friction means we can nudge more people to give Micro.blog Premium a try for a month.

There are still a couple lingering glitches with trials and upgrades that I’m working through this week. Overall, couldn’t be happier with the change, and I think Micro.blog customers are happier too.

Bluesky has a couple new blog posts and info around the production deploy of federation. From their main blog post:

The ability to host your own data, just as you might run your own website, provides the fundamental guarantee that social media will never again be controlled by only one company. Even if Bluesky were to disappear, if the data is hosted across different sites, the network can be rebuilt. The fact that it requires no permission to set up a new website is what has made the open web such a dynamic and creative force.

If you’re mostly familiar with Mastodon’s view of the social web, keep in mind that Bluesky’s AT Protocol is very different than ActivityPub. Both specs solve different problems. If you thought ActivityPub was complicated, just wait until you go down the rabbit hole of AT and Merkle search trees! It is wonderful and terrible. 🤪

For Micro.blog, today we support cross-posting to Bluesky, so we’ve already dipped our toes into the XRPC API. I blogged last year about what I learned with sending posts to Bluesky.

The long-term plan for Micro.blog is to fully support AT’s PDS — Personal Data Servers. Any blog hosted on Micro.blog would plug into Bluesky seamlessly, with data portable to other AT Protocol hosting providers. However, we are going to go slowly with this. I would say it is several months away.

Micro.blog has always had per-blog pricing. Hosting one blog was $5, two blogs was $10, three blogs was $15, and so on. On top of that, Micro.blog Premium added additional features either to a specific blog (like podcast hosting, video, and email newsletters) or across the platform (like our new notes feature).

The reason this pricing appealed to me is that by charging for each blog, we could keep the standard plan as low as possible for most people who only have one blog. If you needed multiple blogs, upgrading added on to the subscription in a way that seemed fair to us and customers.

Over the years we’ve had problems with this pricing, though. It was confusing to keep track of. There have even been billing mistakes because the code for subscriptions was too complicated. Instead of obvious tiers on your account, each blog was effectively its own tier, with tricky scenarios when trials and yearly pricing are mixed in.

Today that’s changing. We are getting rid of the per-blog pricing. Instead, there will be three simple plans, and Micro.blog Premium will now include multiple blogs.

• $5: one blog with all the basic features
• $10: Micro.blog Premium, all the advanced features and up to 5 blogs included
• $15: Micro.blog Family, same as Premium but up to 5 users can post to any of your blogs

Additionally, there will continue to be no charge for hosting extra single-page web sites and test blogs. The new “up to 5 blogs” count is for normal, full blogs.

Most people only have one blog. If you do already have multiple blogs, this pricing change may mean you’ll be paying less. By the time you read this, your subscription should have been updated to reflect the change.

For example, if you had two blogs, one standard blog and one using Micro.blog Premium, previously that would have been $5 + $10 = $15. Now, having two blogs is covered in Micro.blog Premium, so your cost goes down to $10. Or if you had two $5 blogs already, you’ve been upgraded to Micro.blog Premium automatically because it’s the same price you were paying before.

Micro.blog has been updated throughout to reflect this pricing change, including a redesigned Plans page to upgrade or downgrade your account. Creating new blogs is simpler too.

I’m biased, but I think Micro.blog hosting is one of the best values on the web. Nothing else comes close to the depth of features. Hope you like Micro.blog as much as we like building it.

I don’t want my whole life to be writing blog posts and podcasting about Apple’s changes for the EU’s Digital Markets Act, but this latest developer update from Apple feels like an insult to developers, playing us for fools.

Let’s start with how Apple keeps mentioning all the new APIs that are part of this rollout:

To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union — including more than 600 new APIs and a wide range of developer tools.

They said the same thing in the initial news announcement:

The changes include more than 600 new APIs, expanded app analytics, functionality for alternative browser engines, and options for processing app payments and distributing iOS apps.

Apple repeatedly talks about these “600 new APIs” as if it is a favor to developers, but it was Apple’s choice to handle it this way. For example, to comply with the DMA’s requirements on sideloading or marketplaces, Apple could’ve chosen a system similar to installing apps from TestFlight. This would require zero new APIs for developers, just as TestFlight itself has no new APIs when building a beta version of your app.

Apple created the new APIs — a significant number in MarketplaceKit alone — so that they would have control over distribution. By both reviewing marketplaces and requiring that marketplaces use new APIs to install apps, Apple can track app install numbers, allowing them to invoice developers the new €0.50 Core Technology Fee. The new APIs help Apple, not developers.

Moving on to the web browser update, there is going to be universal concern from web developers about Apple disabling PWAs in the EU. On letting web apps use browser engines other than WebKit, Apple writes:

Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent.

Was this statement from Apple written by a hallucinating AI? All mainstream web browsers have a strict security model for JavaScript. Cookies and local storage cannot be accessed across web apps. It’s even difficult or impossible to make certain web requests from JavaScript because of cross-site scripting and CORS limitations. The only way this could be circumvented is with a rogue web browser engine that did away with these standard constraints, but Apple already has this scenario covered because they approve every browser engine:

To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.

Users want to run Firefox and Chrome, popular browsers that are trusted by users. The DMA was created to allow this kind of choice. No one is asking Apple to blindly let browser engine malware take over home screens.

Some have argued that the DMA is poorly written, or at least too vague and open to interpretation. It actually gives gatekeepers like Apple significant leeway when it comes to security. Quoting from section 6.4:

The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.

Apple has clearly jumped on this to give themselves an out, ignoring the spirit of the law. When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.

Wrapping up, Apple writes:

EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.

It is hard to take this seriously after Apple’s bad-faith effort to comply with the DMA. I’m sure WebKit engineers regret this change, but Apple leadership doesn’t. By limiting PWAs just as PWAs are starting to be competitive with native apps, Apple ensures that native apps have no real competition on iOS, strengthening Apple’s hold on app distribution.

I’ve been thinking about Mastodon and the fallout from Bridgy’s plan to connect ActivityPub servers to Bluesky. For a snapshot of how this blew up, see this GitHub issue discussion, now thankfully closed after it devolved into personal attacks.

It often feels that (some) Mastodon folks care more about Mastodon as a platform than they care about the open web as a platform. I’m not sure if that’s a completely fair framing, but thinking about it this way has helped clarify my view of debates around public posts.

When I post to my blog, my posts are on the web, and so hopefully make the web a little better. I’m contributing to sort of a larger purpose, something I can refer to later myself, and maybe something others will find value in too. It’s a subtly different mindset than posting to a specific platform where I mostly expect my followers to see it.

My blog is connected via ActivityPub to Mastodon, and via cross-posting to Bluesky, Nostr, Threads, and elsewhere. But I could disconnect those platforms and it wouldn’t change much about how I post and what I write about.

That’s not to say there aren’t great reasons to prefer a smaller, more controlled audience. We have Mastodon post visibility to limit who can see posts. We have robots.txt to discourage search engines. We have settings to make posts ephemeral. As Bridgy developer Ryan Barrett said himself in an article on TechCrunch, this level of control is one thing that has made Mastodon a good online home for many people:

A lot of the people there, especially people who have been there for a while, came from more traditional centralized social networks and got mistreated and abused there, so they came looking for and tried to put together a space that was safer, smaller and more controlled. They expect consent for anything they do with their data.

I respect this view. It’s not how I approach my own blog, but I would never argue that someone shouldn’t be able to protect themselves. There should be a variety of approaches in between sharing everything online and sharing nothing.

And we do have additional solutions already. Mastodon server administrators can block other servers that are causing problems. Users can mute or block other users. These solutions apply equally to Mastodon servers and to a potential Bluesky bridge.

If there are no technical differences between blocking a rogue Mastodon server and a Bluesky bridge, what are people truly concerned about? It often appears to get back to identifying with Mastodon and its principles, and inherently distrusting other companies, fearing a return to the worst of massive, centralized platforms.

If this sounds familiar, it’s not unlike the reaction many had when Threads was rumored to support ActivityPub. I blogged about this last year, hoping more people would see it as a positive step forward:

Meta adopting ActivityPub has the potential to fast-forward the progress of the social web by years. Ever since I grew disillusioned with Twitter a decade ago and started pushing for indie microblogs, then writing a book about social networks and founding Micro.blog, I could only dream of a moment where a massive tech company embraced such a fundamental open API.

Smaller social networks are an important part of finding our way out of the social network mess of larger, especially ad-based platforms. Mastodon deserves enormous credit for making federation and smaller servers actually work. I can’t overstate how significant it was for Mastodon to be a mature platform that could welcome users leaving Twitter X.

Federation is just one part of the progress we can make, though. We also need to embrace the open web again, encouraging more people to have their own blog and identity online. Bridgy has been working toward these goals for years, helping people connect their blog to other social networks.

My concern with some Mastodon users (again, not everyone!) pushing back against interoperability with non-Mastodon platforms is that it moves Mastodon away from the open web, which is surely at odds with the original purpose of Mastodon and many of its features, from an open client API to federation itself. We can already see some signs of Mastodon putting up slight roadblocks to open web access. For example, permalink posts on Mastodon require JavaScript — you can’t view HTML source and get the post details, making it a little more difficult to build tools that understand Mastodon pages. At the API level, some servers also require signed ActivityPub requests, making it a little more difficult to look up user profiles.

The developer community for Mastodon is free to make any of these decisions they want. To play this out to its most extreme version, they could even disable RSS feeds, treating Mastodon servers more like protected, mini silos.

But moving away from openness will not only limit the potential of the fediverse, it risks holding back the larger social web. If there’s a knee-jerk reaction to interoperability with other platforms, Mastodon may find that its head start as the largest federated platform becomes eroded, eclipsed by Bluesky and other platforms. I would ask the folks on Mastodon who are so strongly against bridging to Bluesky if that’s the future they really want.

Today we’re launching a major new feature for Micro.blog Premium subscribers. Micro.blog notes are a new way to save content in Micro.blog when you don’t want to use a blog post or draft. Notes are private by default, end-to-end encrypted across all platforms, with a special companion app named Strata for iOS. (Android coming soon.)

Notes are great for:

• Jotting down ideas or brainstorming future blog posts. Notes use Markdown, so it’s easy to move the text into a blog post draft later.
• Sharing content with a smaller group of friends or family, without that content being linked on your blog. When a note is shared, it is given a unique, random-looking URL on your blog that you can send to others.
• Journaling within Micro.blog, so you can use the same platform whether you’re writing something just for yourself or sharing it with the world in a blog post.

From the launch of the platform, Micro.blog has been about public blog posts. We want to make the web a little better with thousands of new blogs, where the user owns their identity and content. Some people want private posts too, but we’ve delayed adding that because it doesn’t fit perfectly into the public web. With the wrong implementation, it would turn Micro.blog into more of a closed silo, with some features only available when you’re signed in.

Notes will be Micro.blog’s initial solution to private posts, a foundation we can build on. By default, notes really are private. They are encrypted and we can’t see them. But any note can be shared with others. When sharing a note, it’s decrypted and published to a corner of your blog, accessible only by direct URL.

This level of encryption adds a new wrinkle to how Micro.blog usually stores data. We’ve tried to keep it simple, but honestly it can be confusing, and we expect a few bumps along the road. We will continue to make it as seamless as possible. There are options to download a copy of the “secret key” used in Micro.blog, as well as saving a copy to iCloud. I recommend both.

In the future, notes will make their way into more Micro.blog features. For example, you can imagine attaching notes to bookmarks, web page highlights, or a book you’re reading. We are very excited about the potential for this in Micro.blog.

Here’s a screenshot from the web. Enjoy!

I’ve always liked how Bluesky uses a domain name for your handle. Starting today, Micro.blog has built-in support for verifying these! If you’ve signed into Bluesky with Micro.blog, it will automatically return your AT Protocol “DID” from the .well-known URL for your blog. No DNS fiddling.

In more detail, it looks something like this:

• Your blog is (for example) myblog.com hosted on Micro.blog.
• Your handle on Bluesky is @myuser.bsky.social but you want it to be just @myblog.com.
• Sign into Bluesky in Micro.blog under Account → Edit Sources & Cross-posting.
• Go back to Bluesky and change your handle to @myblog.com. You’ll want to choose the “No DNS Panel” option.

That’s it! Bluesky will check with Micro.blog to verify that it’s your blog. After everything is set up, you may need to go back to your cross-posting settings and update to use your new Bluesky handle too, if you want Micro.blog to send blog posts over there automatically.

Rolling out bookmark improvements in Micro.blog Premium today. Two things:

• Micro.blog will now try to summarize the text of a web page that is bookmarked by sending it to our future robot overlords at OpenAI. This is hidden by default, but can be enabled by clicking Bookmarks → “…” → “Show Summaries” on the web.
• There is a new web browser extension to make bookmarking the current web page easier, initially available for Firefox and Chrome, with Safari to follow. You can find it by searching “Micro.blog” in the Firefox and Chrome extensions directories. After it’s installed, you can pin it to your toolbar.

The AI summaries are still experimental. I’ve found them useful to get a quick glance of something I want to read later. In the future, I hope we can use them to improve search too.

Here’s a screenshot of a bookmarked web page with the summary shown:

It’s going to be a busy week. We have another new feature set to launch this month, with a new app that I’m submitting to Apple today. Thanks for your support!

Steve Troughton-Smith asks an interesting question on Mastodon:

“Why would anybody use my app in VR?” isn’t the right question to ask yourself. It’s “do I want my users to have to take off their headset to use my app?”

His post is clearly intended to have the obvious answer “no”, but I’m not sure there is a universal answer. I decided to opt-out of visionOS for my iPad apps, for now. I’m not sold on the device yet, and I have a bunch of other things to work on anyway.

It got me thinking about Apple’s own apps. For example, Books. Would you want to read a novel inside VR? You aren’t going to want to have Slack and other apps floating in space to distract you. An iPad seems like a better device for reading. Maybe if the book is surrounded by a virtual environment from the book within visionOS, adding a sense of being there? Apple seems to think so, because it does include the iPad version of Books with the Vision Pro.

Through the history of technology there are many “just because we could do it” moments. TikTok has swiping through an infinite feed of limitless content and users are probably worse off for it. I think the Vision Pro is going to be the same way, as developers feel out what makes sense on the device, and consider what is right for users. If some apps require taking off the headset, that might even be a good thing.

Early reviews for the Vision Pro dropped this week. This device is technically amazing, with well-considered solutions to the problems of VR. My takeaway from the reviews is that I want to try it, but I’m okay waiting before I need to own a bit of this future that Apple is promising us. I’d like to see something closer to true AR, not mixed reality, in a more lightweight, affordable form factor.

When the pre-orders ship later this week, early adopters will unpack the headset, post to social media about how amazing it is, and then largely go back to using their MacBook Pro for real work. We are already too isolated from our fellow humans, and there are too many environments — coffee shops, libraries, and other public spaces — that are not suitable for the Vision Pro.

Apple has an incredible track record since Steve Jobs returned to the company, and continuing with Tim Cook. Very few misses, and some of the controversies like Antennagate were overblown. As long as I have been using Macs, going back to the early 1990s, Apple’s dedication to great design and putting the user first has served them well. There is a lot to be proud of, including initiatives alongside products, such as their commitment to the environment.

But increasingly, it feels like this success has inflated Apple’s view of themselves, twisting their perspective of what matters. They’ve become arrogant, as if entitled to future success too. As I posted in the context of their response to the EU’s Digital Markets Act:

Because of their decades of truly great products, Apple thinks they are more clever than anyone else. Because of their focus on privacy, Apple thinks they are righteous. Because of their financial success, Apple thinks they are more powerful than governments. The DMA will test whether they’re right.

Maybe we’re at a crossroads for the company. Apple was great as the underdog, when they were humbled, fighting to out-innovate the competition. What came after the Lisa? The Macintosh. After almost going bankrupt? Think Different and the iMac. After the butterfly keyboard? Some of the best MacBooks ever made.

Apple is now so powerful, with so much control over computing… They need a failure. They need to see a new product stumble in the market. They need to remember what it feels like to realize something isn’t working, to take a fresh look at their priorities, and to reflect on how they treat users and developers. They need to be more focused in what they do, leaving a little room for the rest of us to build something too.

I don’t wish a flop on the Vision Pro product team. They’ve put an extraordinary amount of good work into it. But we all have a mix of successes and failures in life and business. It keeps us grounded. It helps us set priorities. We learn from it and move on to the next thing.

And if the initial Vision Pro doesn’t find a mainstream audience, that doesn’t mean there isn’t a revolutionary interaction model there. Maybe spacial computing is part of the future. Maybe if Apple sticks with it, we’ll look back on how they pushed the idea forward even when the first generation product didn’t pan out.

Trillion-dollar companies need to make trade-offs too. Because Apple has been working on the Vision Pro as the next big thing, what have they missed that needed their attention?

We should hold Apple to a high standard because they’ve earned it. I just don’t believe in the soul of the company the way I used to. As Brent Simmons reminds us, corporations are not people. Apple does so much — Macs, iPhones, iPads, watches, headphones, ads, video services, movie production, cloud storage, news, fitness, the App Store, platform fees, goggles — that I’m not sure there is still a cohesive story around what they stand for, other than money.

Today we’ve added a brand new option for manual cross-posting from Micro.blog to other services, including Threads. This new option is great for services that don’t yet have an open API, so Micro.blog can’t automatically post to them, or for when you want to edit and preview your posts before sending them elsewhere.

This feature is for blogs hosted on Micro.blog, so it’s available in the Posts page where you manage your blog posts:

This brings support for Threads for the first time. When choosing Threads, Micro.blog will reformat your blog post as plain text, truncate it if necessary, and copy the text over to Threads where you can finish sending the post. You will need to be signed into Threads in your web browser, or in the Threads app on mobile.

Twitter X is also now back in a more limited form with this new cross-posting option. We still can’t automatically post to Twitter X because of their API changes. There’s also the usual suspects like Mastodon, Tumblr, and Bluesky.

This feature doesn’t work exactly like Micro.blog’s existing, automatic cross-posting, so be sure to check out the help page for the details. In future updates, I expect that the two different ways of cross-posting will look more similar.

Last month we teased that a major new feature is coming to Micro.blog soon. Whenever we add something new, folks ask if the new thing is the major feature… Nope, this cross-posting improvement isn’t it either! You’ll know when we ship it next month because it comes with its own section of Micro.blog, a new companion app for iOS and Android, and an update to the macOS app. Stay tuned.

In a blog post from 2020, I suggested four changes to fix the App Store for developers: 1) allow sideloading; 2) don’t require in-app purchase; 3) keep curating the App Store; and 4) lower the cut to 15%. I described each of these in more detail in that post, so I won’t repeat the reasoning here.

With this week’s App Store changes for the EU’s Digital Markets Act, let’s revisit how Apple is doing with those four points:

• Allow sideloading? Not really. Instead, there is a new type of marketplace app that can install other apps. There are hurdles to jump through to become a marketplace app. For Micro.blog, I was imagining that I could have a marketplace app just for our suite of iOS apps, thus bypassing app review going forward, but this doesn’t seem like it is going to work in practice. Furthermore, there is a new Core Technology Fee that would still apply.
• Don’t require in-app purchase? Sort of. If you opt-in to the new rules, you can use your own payment system, or link to external payments on the web. The problem is Apple still wants 10% (for small developers), so there is little to no savings, and it creates new bookkeeping problems. The only way to avoid the fee is to have an app on a third-party marketplace. Even then, you’re still subjected to the Core Technology Fee.
• Keep curating the App Store? Yes. Isn’t very relevant here, though, and Apple is no closer to adopting my vision for how to run the App Store.
• Lower the cut to 15%? Yes. It can be as low as 13% now. But again, there’s the Core Technology Fee to offset any savings if you have more than a million installs.

This is all pretty disappointing. I have been bitter about the App Store for years, but yesterday I tried to keep an open mind. I was initially excited about the potential for marketplaces. I blogged that it seemed like a good-faith effort to comply with the DMA. Apple had put a bunch of work into this, in documentation and new APIs. The more I understood it, though, the less compelling it became. In some cases it will be worse than what we had before.

My opinion from way back in 2011 hasn’t changed. The problem is Apple’s total control over app distribution, and so the only permanent fix for the App Store is removing that control with true sideloading:

Apple, want to charge 30%? Go for it. Want to make the submission rules more strict? Fine. Want to adjust how you run the App Store to reflect what’s happening in the market? No problem. Just give developers an out. We are going to be back here year after year with the latest controversy until exclusive app distribution is fixed.

I wrote that thirteen years ago and it has proven correct every single year since. The DMA attempted to address this, but Apple’s response comes up short. Instead of fixing the root problem, Apple has added an even more complex set of bandaids to preserve their control over the store.

(As an aside, see that quote from Steve Jobs about free apps in my blog post? The Core Technology Fee is a major departure from Steve’s framing. Apple now wants to charge free apps for the first time based on installs alone.)

So, is Apple actually in compliance with the DMA? Rick VanMeter, from the Coalition for App Fairness, says no. There’s also a thorough post by Damien Geradin on The Platform Law Blog that reaches the same conclusion:

As to whether the reduced commissions comply with FRAND. The answer is an unequivocal no. These commissions are not fair and reasonable for the reasons described in the preceding paragraph. But they are also discriminatory. The reason is that app developers whose apps sell digital goods and services and those whose apps don’t, effectively use the same app store services, but are treated differently.

I don’t know where we go from here. It always feels like two steps forward, then back. The EU must stand firm. I’m tired of ending up in the same place, over and over.

Micro.blog can be thought of as a mashup of a Twitter-like social timeline and a WordPress-like blog posts admin interface. Some parts of the interface are designed for interacting with the community, some parts are designed for managing your blog, and some parts are kind of in limbo between both sides of the platform.

One example of this is on the Posts screen, where there hasn’t been a link from one of your blog posts to any of its replies. Today I added that:

I have mixed feelings about this interface. We try to avoid “counts of things” across the platform. There are no follower counts and no like counts. We want to discourage the popularity contest mentality that can come from comparing statistics across users.

In this case, these are just links to replies on your own view of your posts. If a post has no replies, there is no indicator. I decided to roll this out so we can live with it for a little while and see if we like it. I consider if somewhat experimental and based on feedback, we may change it to be less prominent, or deemphasize the count. It could also fade away if there are no new replies recently.

Still thinking about this, but wanted to share it now. We update the platform on a near-daily basis, usually small fixes and tweaks. Check out news.micro.blog for a log of recent changes.

There has been a long-standing issue in Micro.blog where blog category names had to be ASCII characters. No more! Today I rolled out a few major, related improvements to categories:

• Category names can now contain special characters. This is important for non-English languages.
• Category URLs can be customized. So if a category is “Café”, the category slug can be “cafe” without the accent.
• Category URLs can even be outside the usual “/categories” path. So instead of “/categories/books”, you can just use “/books”.

These customizations are available with a new field on the edit category page. I hope folks enjoy this extra flexibility. Also note that it’s possible to create new conflicts, such as the same path being used for standalone pages and categories… Just be mindful of this when creating pages.

Micro.blog supports importing from a lot of different services: Twitter, WordPress, Medium, Tumblr, Ghost, Markdown, Substack, Write.as, Foursquare, Goodreads, and others. For each one we want to add, I download an archive from a test account on the external service to figure out what the format looks like, then write custom code to handle it.

None of these formats look anything like one another. Just a few examples:

• WordPress uses an RSS file with extra fields for WordPress-specific info. No images are included, although they can be downloaded separately.
• Ghost includes a JSON file with their own fields. There are some weird quirks like the placeholder string __GHOST_URL__ being used in image URLs.
• Substack has a ZIP file with a CSV file inside and individual .html files for each post.

Some services have an even less stable format. Both Twitter and Instagram have changed their format after it was widely used, requiring us to retool our import. And Glass’s export file does not include post dates or text captions.

One of the great things about indie microblogging is owning your own domain and so being able to move between services. But without a common format, it can be very difficult to migrate posts.

This is why I proposed the Blog Archive format (.bar) back in 2017. It’s essentially a ZIP file with all the posts and images for your blog. It uses JSON and HTML. There is nothing in it that is specific to any one blog platform, but it’s easy to extend with your own data if needed.

Micro.blog for macOS even supports previewing these .bar files. Double-click the file and it will show a list of the posts that will be imported. And because it’s really just a .zip file, you can rename it and use it anywhere. Or treat it as a single file that can be backed up.

In the years since I started using .bar, I’ve still yet to see any competing file format that solves the same problem. I’d love to see it become more widely supported.

Today I sent the following update to Kickstarter backers about the ePub version of Indie Microblogging. Note that the link to download the book is disabled below. This is for Kickstarter backers first, then we’ll sort out how to get it to everyone else.

Today I’m making a near-final draft of my book Indie Microblogging available to Kickstarter backers in ePub format. You can load this up on a Kindle, Apple’s Books app, or your favorite e-book reader. The latest version is also available on the web at book.micro.blog.

Over the last year, I’ve updated the book for recent events that affect blogging and social networks, such as Elon Musk acquiring Twitter, Meta’s Threads launch, and the latest with Bluesky. There’s also a new interview with Om Malik. I’m still planning to go through the book one more time and refine what is there before we officially call this done.

If you aren’t ready to jump into the book, I suggest skimming the version on the web to get a feel for the content, but wait to download the ePub until later, to make sure you have the latest draft.

The ePub file is [available for download here].

What about the PDF and print edition of the book? I’ll be sending another update to Kickstarter backers with more information about that. It has been years since the original Kickstarter campaign, so I expect many of you have moved, and I want to make sure that we have everyone’s correct shipping address.

Thanks as always for your patience and support! And especially to everyone who is using Micro.blog. The platform has come a long way, and there’s more to come in 2024.

Here are the books I finished reading in 2023. I thought I might finish another one this weekend, but it’s not going to happen, so might as well post this today. Happy New Year!

Blogs and social networks talking to each other is still kind of magic. If you’re on the latest version of Micro.blog’s Alpine theme, replies from Bluesky can now flow into Micro.blog via Bridgy. We’ll be updating all the blog themes to support this, or you can modify your theme.

This works by signing into Bridgy so that it knows how to link your blog and your Bluesky account. Then if you have cross-posting enabled to copy blog posts to Bluesky, Bridgy will look for replies and match them up to the canonical version of the blog post. It then sends a webmention to Micro.blog.

In the Alpine theme, I’m telling Bridgy about this relationship using the u-syndication microformat. I have it hidden for now, but it can just as easily be an icon or text link to Bluesky:

{{ if .Params.bluesky }}
  <a class="u-syndication" {{ printf "href=%q" .Params.bluesky.url | safeHTMLAttr }} style="display: none;">Also on Bluesky</a>
{{ end }}

Eventually this will all be more automatic. Replies back to Bluesky aren’t possible yet, so you’ll still need to click through to Bluesky to reply. But even now if you don’t mind tinkering, a lot is possible. It’s cool to see replies from Bluesky just show up like normal replies in the Micro.blog timeline. Because Bluesky uses domain names for usernames, they fit naturally into the way Micro.blog thinks about the web.

“I just had this weird feeling that my money wasn’t safe here anymore.” — Sneakers

Some people wondered about my vague microblog post last week. I didn’t post the details because I didn’t know everything about the situation yet, but now I do.

After 16 years in the same house, we moved this year, putting our old house on the market. The kids had all moved out. It was a good time to downsize, move a little closer into town, and maybe simplify. We had accumulated so many things, including thousands of books which I didn’t want to part with. The easiest way to solve this seemed to donate everything we could and then just box the rest up and rent a storage unit somewhere, to give us time to move and go through things more slowly.

This mostly worked out great. We recently downsized the storage to a smaller unit, because almost everything had been moved.

Fast forward to last week, I got a message from the storage facility that the lock on our unit needed to be replaced. No other details. We went up there and discovered a new lock on our door. The metal around the door was a little bent out of shape. I was able to point my camera into the grate at the top to look in. Someone had clearly broken in and messed everything up. Boxes were moved and at first it looked like half of our stuff was missing.

I often reflect on how lucky I’ve been in my life. Very few regrets, only a couple true setbacks to complain about. No one has ever robbed me! (Except identity theft to go on a shopping spree in my name, which was annoying and a huge waste of time, but fixable.)

What hit me hard about this was the irreplaceable stuff. I was imagining photos that were never scanned, family videos on VHS from my grandparents, my kids' old artwork from school, random documents, some stuff I’ve never even seen because I kept putting off digitizing it. I don’t worry about losing laptops, tech gadgets, or books. It’s the stuff that money and insurance can’t fix that hurts.

The next day I got to meet with the manager and get inside our storage unit. Turned out someone had made a run on multiple locations. They rented a unit to get an access code for the gate and elevator, then I guess cut locks or used a crowbar to open whatever they could. Other renters were there like I was, trying to understand what in their stuff was missing.

This is where the story ends with good news. Sorting through our stuff, I think everything actually important remained, just tossed around, boxes ripped open. The thief even skipped over old MacBooks and iPods. Maybe they were looking for guns? TVs to pawn? Who knows.

I’m still trying to understand what is missing, but even worst case now it might be a few inconsequential things or nothing at all, not what I had feared. Mostly a happy ending, and lessons learned. Please make copies of everything that matters.

This weekend I added limited support for following Bluesky users in Micro.blog. This isn’t federating with Bluesky yet. Instead, it uses a combination of Bluesky’s RSS feeds and the AT Protocol.

To follow a Bluesky user who has an account username in the form username.bsky.social, just search for the username in Micro.blog. It doesn’t work for custom domain usernames in Bluesky, because Micro.blog will think you want to follow the user’s blog instead.

Here’s a screenshot showing a search:

Note that Bluesky’s RSS feeds are brand new, and there are a few missing pieces. Photos in posts are not included and inline links may not work perfectly. Still, I expect Bluesky to improve this over time, and already it’s a useful way to follow many Bluesky users.

I’m planning to improve the Micro.blog side of this in the coming months, such as supporting replying back to Bluesky users. Bridgy can also take Bluesky replies to your blog posts and send them back to Micro.blog via Webmention. (I’ve updated the Alpine theme in Micro.blog to include the IndieWeb’s u-syndication microformat, so services like Bridgy can more easily map Bluesky posts with the canonical microblog post on Micro.blog.)

Happy holidays! 🎄

Yesterday, Meta started enabling limited support for ActivityPub in Threads, mostly around following Threads users from platforms like Mastodon and Micro.blog. Adam Mosseri had an excellent video update on Threads that gave the most detailed look into their roadmap:

This work is taking longer than we thought given our safety work, given our compliance work, and given all the scrutiny on our company. But over 2024 we’re going to be adding the ability to post from Threads to these other servers. We’re going to eventually also support the ability to show replies in Threads natively, and eventually allow you to even follow accounts on those other servers from the Threads app itself.

I made a transcript of his video because it contains more than his text posts on Threads. I transcribed it with Audio Hijack and Micro.blog and then double-checked it with the subtitles on Adam’s video. You can read the full thing in this Gist.

Sometimes people ask for link preview cards in the Micro.blog timeline. Maybe eventually we’ll add them, controlled with a preference. But so often they are in your face, cluttering the timeline, overshadowing perfectly good content. Here’s yesterday’s post on my blog, displayed as intended:

There’s a subtle link on the text “a brand” because I thought people might be curious about the shoes. But that wasn’t the point of the post. I almost didn’t include the link at all.

And now here’s how the same post looks on Mastodon:

What the…? Did I write a short post about serendipity, or did I post an ad for a shoe company?

(Now there is a secondary issue, especially on mobile, where inline links can be confusing or even abused with spam links. There are other ways to solve that.)

So much of social media feels like a show, where everyone is outraged or promoting their own content, the timeline itself just a collection of billboards along the highway, one after another getting your attention. I don’t want that experience. Not having ads is a strength we should lean into.

Nice approach in iA Writer 7 for pasting ChatGPT output into your writing and tracking your edits to make it your own. There is also a Markdown extension for attribution in a range of text. However, I found this part of their blog post a little puzzling:

While the format is open, avoid cloning our work. Draw inspiration from what we made. Change it. Improve it. Design it yourself. Work on it until it is substantially better. If you can’t beat our design, then let it be and do something else.

There is a long history with text editors of drawing inspiration from features in competing products. What iA Writer has built here is not easy technically. If someone eventually copies it, I would chalk it up as praise and move on to the next thing. (Admittedly that’s easy for me to say as an outsider, though.)

Also, a reminder that iA Writer supports native publishing to Micro.blog! It’s a great writing app with elegant support of Markdown. Despite my nitpick above, I do like their thoughtful take on AI integration, and I think version 7 is going to be well received.

One year ago today, ChatGPT was released. It’s not that often that products truly change things. Whether you think artificial general intelligence is just a few years off or that it will remain a pipe dream forever, there’s no question that some form of AI is going to be part of so many products going forward.

AI is a tool. Even imperfect, it is incredibly useful. Looking back, I can’t believe I was so skeptical of its impact. I ignored ChatGPT for months.

This week I was creating a web page to show a grid of Micro.blog feature names, experimenting with different ways to highlight all of the things Micro.blog can do. I turned to ChatGPT to help me get started, like asking it this question:

Can you generate 10 colors that look kind of like #f80 and go good together?

Or this one:

Let’s say you have 87 HTML spans with id attributes 1 to 87. Write JS that randomizes the numbers 1 through 87, then loops over each one and sets it’s background color from an item in a list called colors.

And then:

Add a random delay before setting each color, from 1 to 2 seconds?

And so on. It probably saved me an hour. I’m still working on it, but you can see the result so far in this video.

This kind of functionality is why Microsoft’s “Copilot” branding is so good. AI is the little assistant that helps you with random tasks. Coding, brainstorming, writing. In the above examples, it didn’t replace my job. I still needed to take the output and tweak it, move things around, add my own code, think about the design.

Earlier this year when we added Twitter import to Micro.blog, I used AI to help make an illustration for the web page. I combined the output with my own sketches, compositing things together, adding color. AI was my junior artist assistant, helping me create something that I couldn’t dedicate enough time for on my own.

And in Micro.blog, we now use OpenAI to automatically transcribe podcasts for all Micro.blog Premium subscribers. I’m interested in finding more use cases like this: not using AI to replace our creativity — Micro.blog will always be about personal blogs, written by humans — but to automate tedious work.

I have no idea where AI will be in another year. I won’t obsess about it too much, and I won’t follow where it leads blindly, but I’m fascinated to watch it evolve, waiting for the opportunities that bring clear benefits to our work.

Today we’re rolling out some major improvements to domain name support in Micro.blog. We’ve had domain name registration for a while, but it was fairly limited. Now you can transfer domain names to Micro.blog hosting and let Micro.blog handle all the details. We also have a better management interface for adding custom DNS records.

Here’s a screenshot:

To register or transfer a domain name, in Micro.blog on the web click Account → Get a Domain Name.

There’s no requirement to use Micro.blog for domain names if you want to keep your domain name at another hosting provider. Some people like to keep domain name registration separate from their blog hosting. But if you’d like everything under your Micro.blog subscription, now it’s easier.

There have been a bunch of “what apps am I using?” blog posts recently, inspired by an episode of Hemispheric Views. Robb Knight has a page with links to other people’s posts.

Here’s my list:

• 📨 Mail Client: Hey
• 📮 Mail Server: Fastmail and Hey
• 📝 Notes: Ulysses
• ✅ To-Do: Basecamp, GitHub, and Ulysses
• 📷 iPhone Photo Shooting: Apple Camera
• 🌅 Photo Management: Apple Photos and Dropbox
• 📆 Calendar: Fantastical (iOS) and Apple Calendar (macOS)
• 📁 Cloud File Storage: Dropbox
• 📖 RSS: NetNewsWire and Feedbin
• 🙍🏻‍♂️ Contacts: Apple Contacts
• 🌐 Browser: Safari
• 💬 Chat: Messages and Slack
• 🔖 Bookmarks: Micro.blog
• 📑 Read It Later: Micro.blog
• 📜 Word Processing: Pages and Google Docs
• 📈 Spreadsheets: Numbers and Google Sheets
• 📊 Presentations: Keynote
• 🛒 Shopping Lists: none
• 🍴 Meal Planning: none
• 💰 Budgeting and Personal Finance: Numbers
• 📰 News: Safari and YouTube TV
• 🎵 Music: Spotify
• 🎙️ Podcasts: Overcast
• 🔐 Password Management: 1Password
• 🤖 Code Editing: Nova and Xcode
• 📚 Books: Kindle
• 🌎 Blogging: Micro.blog

I added a few at the end that I’ve seen other folks use even if they weren’t in the original list. There is scoring too, but I don’t understand how it works. 🙂

Marlin from Finding Nemo:

I just can’t afford any more delays and you’re one of those fish that cause delays. And sometimes it’s a good thing. There’s a whole group of fish. They’re delay fish.

I think about this when I’m trying to get something done and not making progress. What is slowing everything down, making simple tasks more complicated than they need to be? Or is it my fault, overthinking something that should be simple?

Not everyone has the same priorities. That doesn’t mean everyone else is necessary wrong, but they don’t have the same urgency. Meetings might have people with good intentions. Emails might have good counter-points to consider. But they are delay fish, getting in the way of accomplishing anything.

After the OpenAI fallout this weekend, I’m pretty confident that Satya Nadella gets this. Friday afternoon he was probably looking forward to the weekend without a clue of the crisis unfolding at OpenAI. Then by Sunday night he had announced that Sam Altman, Greg Brockman, and other folks from OpenAI were joining Microsoft to lead a new AI research team, while preserving Microsoft’s relationship with OpenAI. Lemons to lemonade.

You can be sure there were meetings in those 48 hours. I bet there were delay fish, urging for a pause, time to reflect on what Microsoft should do. There was chaos and so also a moment to act and Satya took it.

Sometimes you need Dory. You need to be innocent, joyful, thoughtful, creative, brainstorming, slowing down. But sometimes you just need to get shit done and move on.

Kudos to Matt Mullenweg for making public the internal memo about the future of Tumblr. It seems they’ll pivot to a smaller team, acknowledging that maybe Tumblr can’t be competitive with other massive social networks, but could do just fine as a more niche platform:

We are shifting from the mode of “surging” on Tumblr with tons of people to get it to exciting growth, to working on how we can run Tumblr in the most smooth and efficient manner. Pretty amazing things in the social and messaging space have been accomplished with small teams, so I’m actually quite curious to see a smaller and more focused Tumblr’s performance in 2024.

I’m a little confused about what Tumblr has been up to in the four years since the acquisition. Automattic had ambitious plans both for ActivityPub and to rebuild the foundation of Tumblr on WordPress. But there are a lot of smaller things they could do, like add support for IndieWeb standards Micropub and Webmention, simple protocols that are straightforward to implement.

Even so, Automattic is a great home for Tumblr. Social networks come and go, but I expect Tumblr to be with us in some form for years. It still has a lot of potential.

I posted a photo the night of the concert, purposefully picking something simple at the beginning in case people were planning to see the show and wanted to be surprised. Lately I’ve been trying to avoid spoilers for movies, books, and concerts as much as possible. Don’t tell me the setlist; I just want to experience it.

But let me share a little more about the concert. First of all, my bias is that I’m a U2 fan. I’ve seen them live several times. I bought tickets for Vegas a few months ago without a clear idea of who could go with me or how I would get there.

This is where you can stop reading if you are planning to go to the Sphere no matter what and don’t really need to hear my opinion or see more photos.

Over the last month, I concocted a plan to drive to Vegas, where my kids would fly in and meet me for the concert. Then I would continue on to California before heading back through Utah to see whatever I can see. I would work every day from the road. More about all of that later.

A lot could’ve gone wrong with all of this. Honestly, sitting in our seats at the Sphere, I reflected on how I wouldn’t have been at all surprised if none of this had panned out. Someone gets sick, can’t make it, or countless other problems.

The venue is unlike anything I’ve ever seen before. Photos don’t do it justice. Such a ginormous screen allows them to create scenes that are stunning. They can play tricks with movement that make it so immersive and new.

In a way, it’s an experiment, a spectacle. This is balanced by some quieter moments too, where the band plays without any fanciness on screen to distract you. I think this kind of show could continue to be tweaked as the producers better understand what works in the venue.

If you’re a fan of U2 or like visiting Las Vegas, I highly recommend it. I’ve grown to love and hate different parts of the city. For me, it’s best in moderation. Come for a couple days, have a great time, spend too much money, and then it’s time to get back to the real world. Roller coasters on the top of New York New York, a recreation of the Eiffel Tower, a pyramid… the Sphere is unique and amazing and fits in perfectly.

Even though we now share most code across iOS and Android, I wanted to keep the version numbers separate so that each platform can evolve as it needs to. Today we are bumping Micro.blog for Android to 2.0 because of a big addition: a system share action from other apps to Micro.blog.

Now when you’re in another Android app, you can start a new blog post or save a bookmark. Here are a few screenshots showing text selected in Chrome and then shared to Micro.blog to create a new post with the quoted text and URL.

Thanks as always to Vincent Ritter for developing this. Meanwhile I’ve also been tweaking things for iPad, so there will be another iOS release not too far off.

This one ended a little more quickly than I expected:

Our goal was to build a kinder, safer, public square. We grew from 6 users on the first day (Dec 9, 2022) to a community of 20k by October 2023. But we weren’t growing fast enough justify additional investment, and we also underestimated the number of new competitors with a similar vision who would enter the field.

I liked the name Pebble. From their about page:

From our early days as T2 to our evolution into Pebble, our ethos is consistent: creating an inviting space for genuine dialogue. The name “Pebble” signifies that even small interactions can leave profound impacts.

The company was founded as Twitter started to implode under Elon Musk’s leadership. The Pebble folks seemed to have good intentions and they started building a nice product, with maybe more polish than the usual Twitter competition.

But when I signed up several months ago it struck me that they had built another data silo without either a client API or integration with other platforms via ActivityPub. Without any changes to embrace the open web, Pebble was probably always going to fail, it was just a matter of when. This is a lesson we should have learned years ago, going back to App.net’s rise and fall.

In 2023, no one wants a centralized, closed microblogging service. We already have Mastodon, Micro.blog, Bluesky, and Nostr, and even Threads will be embracing a more open approach. This is also part of my criticism with Glass.

It also might be a story about the erratic success of VC-backed companies. Pebble received $1.1 million in funding earlier this year. That seems like a lot of money to me, but I guess it provides too short a runway for a company that needed to get very big before turning a profit. I believe the future is smaller, more open platforms, and that means we can’t lean on ad-supported models. That strategy has served us well with Micro.blog and blog hosting.

Most small businesses fail and most Twitter clones fail. It has always been this way. Hopefully we can learn from Pebble, and I wish the founders good luck on the next thing.

The last big upgrade for my Honda Element was to build a bed platform to use for car camping. I worked on this a little bit at a time over about a month. I was inspired by designs from other people, but ended up just sketching out something that I thought would work for me.

I wanted it to be exactly the size of a twin mattress. Also wanted enough space for storage underneath, but not so much that I would feel cramped with limited space from my head to the roof. I got a trifold, 4-inch mattress on Amazon. The platform itself would be in two sections, with one section folding down over the front seats when set up as a bed.

First building the basic structure:

Not pictured, later I ended up adding little metal braces everywhere for more support. Screws alone did not hold the legs in well. It was too wobbly and would even come disconnected. In hindsight, I might’ve been too worried about minimizing weight. I used pretty thin pieces of wood, mostly pine.

I sanded everything, stained it, and added hinges:

Testing it in the car, fully extended and folded up:

I plan to do another coat of polyurethane later. By the time I was ready to use it, I felt like it was really only about 90% done. You can also see some screws poking out from the hinges, which I covered up with several layers of tape after these photos were taken.

Here’s the final bed set up, plus a shot inside at night from camping at the Davis Mountains State Park:

Overall, very happy with my little micro camper. I learned a lot during the first trip and there are some obvious things to improve for next time. I’ve collected the posts in this series in a category on my blog here.

Another upgrade I made to my car is to add the weBoost Drive Reach Overland antenna on top. It essentially takes whatever cell signal it can find and rebroadcasts it inside your car. The antenna can rise several feet over the top of the car, picking up distant signals that the iPhone’s built-in antenna can’t reach.

I knew I needed something like this after my trip to Colorado earlier this year. I still needed to work but I was sometimes without any cell coverage. Starlink would be great but it’s a pricey $150/month. The weBoost is just a one-time cost without an ongoing subscription.

I attached it to my roof rails, keeping it rotated so it’s parallel with the roof and turned off most of the time. It’s easy to flip it up when needed at a campsite. The wires are a little all over the place right now. I’m considering drilling a hole in the roof but not ready to make that leap yet.

It works as advertised. I first tested it in the city where I had 2 bars. I turned it on and right away had 4 bars. Out in the Davis Mountains, I had 0-1 bars and with the weBoost that jumped to a reliable 2 bars.

Of course, it’s not magic. If you are too far away from a cell tower, there’s nothing it can do. But I’m amazed by it. It’s a game-changer when you’re just a little too out in the middle of nowhere.

Evan Prodromou had an important post a few days ago, arguing for backwards compatibility with future ActivityPub work and discouraging competing protocols. I found some things to agree with in his post, but I’m less certain that there is a single path forward. On Bluesky and others, Evan writes:

We get exponential growth based on having one protocol, not a half dozen. I think Blue Sky, Nostr, and others are a threat to ActivityPub breaking out and becoming ubiquitous. There can’t be multiple winners. I often reference Metcalfe’s Law in this regard; one big connected internetwork is much better than 3 or 4 disconnected ones.

Maybe. But the web has always been more muddled than that. We have multiple feed formats, like RSS, Atom, and JSON Feed, and it’s okay. We have multiple blog APIs, like MetaWeblog, AtomPub, and Micropub, and it’s okay. We have multiple social web notification mechanisms, like ActivityPub, WebSub, and Webmention, and it’s okay.

What makes it all work is that the web is the network. The fediverse is one aspect of that network. If we go too far elevating the fediverse as the only ubiquitous network, it risks disconnecting it from the blogosphere (!) and the rest of the web. Already I’d argue that some Mastodon decisions have isolated the platform, such as loading content via JavaScript so there are no longer basic HTML web pages for post permalinks.

ActivityPub is a huge success story. Yet there are still good ideas to pull from competing protocols. For example:

• Bluesky is using domain names for user identity. I’d love to see the fediverse adopt this in addition to email-style identifiers.
• Nostr is less verbose than ActivityPub. I’d love to see cleaner ActivityPub responses without JSON-LD.

If we never let other protocols get off the ground, there would be fewer experiments to help push ActivityPub along. It’s also curious that with Mastodon so well established, Bluesky recently hit 1 million users as an invite-only beta. How? Answering that may help Mastodon and ActivityPub adoption too.

Between trying to sell our house, moving to a new place, and keeping up with actual work, I’ve managed to squeeze in some time here and there to work on my car. I recently put new OEM cross bars on it and our old rooftop box. The Element’s roof has a really nice design that makes this easy, with bolt holes under a little plastic panel.

Here are some photos:

I’ve also finished building the bed platform that’ll go in the back to make the car a micro-camper. That’ll be the next blog post in this series.

We’ve updated Micro.blog for iOS to version 3.2.1 with some additional improvements. One change you’ll notice right away is that the formatting toolbar now has more traditional “b” for bold / “i” for italic buttons. In previous versions I thought that showing the Markdown syntax on the button titles would help educate people on how Micro.blog worked, but it just created more confusion. I like the simpler buttons.

For Micro.blog Premium subscribers, you’ll also see a new audio icon for attaching an MP3 (or any file) to a blog post.

Full release notes:

• Updated new post toolbar to use b, i, and link icons.
• Added audio attach icon to new post for Micro.blog Premium subscribers.
• Added new notifications pane when receiving new mentions.
• Added link to Indie Microblogging book and Markdown reference in help.
• Fixed remembering last selected blog when using multiple blogs.
• Fixed scrolling to allow more room for accessibility text on photos.
• Improved some minor layout and styles in other parts of the app.

Enjoy!

There are a bunch of things I want to add to my Honda Element to make it my own. I just finished the first upgrade: CarPlay. I didn’t really know what I was doing but somehow stumbled through it. It is a huge improvement compared to the 15-year-old factory radio.

Documentation online is a little inconsistent for this kind of upgrade. I wasn’t totally sure if the parts were correct until they arrived. In the end I used these:

• Sony XAVAX1000, 6.2-inch media receiver. Simple, clean design with an actual knob. I think it’s discontinued but Best Buy had one.
• Metra 70-7863, stereo wiring harness. With RCA cables that go to the Sony unit. Ordered the wrong kit at first, then found the right one at Custom Sounds in Austin instead of waiting for shipping.
• Metra 95-7863, plastic dash kit. I was honestly shocked when this arrived and it was the right shape. It was hard to tell from the online photos.

If you are reading this in the future to upgrade your own car, note that I have a 2008 Honda Element SC. I don’t know if these parts would work perfectly with earlier or later models, or the EX or LX trims.

First step, disconnect the negative on the battery. Finding the right socket wrench in our garage took nearly as long as anything else.

With a little plastic removal tool, I popped up the faceplate around the radio. After that it’s easy to unscrew the old unit and take it out.

I stripped the wires on the new Sony unit and connected them to the appropriate wires on the Metra wiring harness. I didn’t have any fancy wire connectors so just threaded them together, twisted them, and wrapped in electrical tape. I went very slowly and think it turned out fine.

Finally, all that was left was to install the unit. I screwed everything in and popped on the new plastic covering. Some of the original wires from the car weren’t used so they are just dangling hidden inside. Hopefully they weren’t too important!

I also fed the microphone wire down to the floor so it can attach on the dashboard or behind the steering wheel. Haven’t totally figured out the best place for it yet.

Very happy with this upgrade overall. I probably should’ve had a professional do it, but I learned a lot. My car feels like it belongs in this decade now.

Two years ago this week, Glass launched for iPhone. I had subscribed right away because I wanted to support their work and saw potential in it, even if I will always default to posting photos to my own blog first. Since then, Glass has added an Android version and a web version, along with other improvements like tags and appreciations.

Not long after Glass launched, we added special support in the Micro.blog iOS app for it. You can see a video of how it works in my blog post here. Unfortunately in the rewrite for Micro.blog 3.0, we had to temporarily remove the feature, although it’s slated to come back in version 3.3.

In that post about supporting Glass in 2021, I wrote:

Glass is so new that it remains to be seen where the app will go, and how it might expand in the future. It shares some of the same principles as Micro.blog — no ads, no algorithms, no likes — but Glass lacks important open web features like domain names and IndieWeb APIs.

Glass still lacks those features for the open web. After a couple years, if having an open API was at all on the radar, it probably would have happened by now in some form. The founders seem more interested in creating an Instagram alternative — another silo without an API or federation with other networks. And in 2023, I don’t think that works.

There is now mainstream pushback against big centralized platforms. We have Micro.blog and Mastodon. We have free photo platforms like Pixelfed. It is a harder sell for customers to spend $5/month for a photo service that is mostly disconnected from the rest of the social web.

I was thinking about Glass while looking into their export format, in case we wanted to support importing it into Micro.blog. I don’t plan to cancel my subscription, but I would not be surprised if many Glass customers have slipped away. The latest big announcement from Glass — an optional $99/year Patron membership — is geared toward increasing revenue from existing customers rather than growing the customer base.

We’ve been running Micro.blog for 6 years. I know how hard it is to balance marketing to new subscribers, keeping churn down, and offering new features regularly, including upgrades to higher subscription tiers. We barely have it figured out now and we were certainly a long way off after only 2 years. The default for SaaS platforms is the slow ramp of death.

There are effectively no success stories for Glass’s current business model. Small clones of Instagram and Twitter usually fail. To break out, there has to be something fundamentally different. For Micro.blog, the answer is simple: we are a social network but our business is blog hosting, a proven model. For Glass, the answer is less clear: they care deeply about photography, community, and design. I think the founders deserve a lot of credit for creating something beautiful. Is that enough?

I don’t know what the right model is for Glass, but I’m confident that it should include a strong foundation for open web standards. I hope that can be part of their vision. It might even be critical to the future success of the service.

It has been a great summer for movies. We’ve wrapped up seeing most of the “big” movies, so here’s a mini review of each.

Spider-Man: Across the Spider-Verse. I love the art style in these movies. When the big animation studios moved from 2D to 3D, we lost some of what made hand-drawn animation so beautiful. Getting a little bit of that back now.

Mission: Impossible 7. So much fun. The driving off the cliff scene might’ve been a little over-hyped leading up to the movie. Super dangerous but I think scaling the skyscraper (in 4) and hanging on to the side of a cargo plane (in 5) were both more stunning. Still, some great action.

Barbie. Really enjoyed this. It’s the kind of movie that you wouldn’t think would work. In the hands of a less-capable director, could’ve walked the line poorly between bad and brilliant. Still listening to What Was I Made For? by Billie Eilish.

TMNT: Mutant Mayhem. Pushing the boundaries of 3D animation again like the Spider-Verse movies. I remember reading my friend’s original black and white TMNT comics back in the day, but the new movie doesn’t require any previous knowledge to enjoy it.

Oppenheimer. Possibly a masterpiece. I was expecting great visuals, which is why we waited to see it on 70mm IMAX, but the pacing and acting and everything else also blew me away. Lots to think about afterwards. The best movie I’ve seen in years.

I enjoyed the conversation on the latest ATP about text editors. Lots of deservedly good praise for BBEdit. I’m sure the hosts have gotten feedback about this already from listeners, but surprised there was no mention of Panic’s Nova.

Feels like a good time to give an update on what text editors I’m using these days.

Xcode: This is obviously still the only reasonable way to go for Mac development. In the last few weeks I’ve shipped some updates to Micro.blog for macOS. Always fun to fire up Xcode, hammer out a feature, and ship it without much fuss. A couple things seem slower than they used to be, like debugging and auto-complete, but otherwise no complaints.

Nova: This is my go-to text editor for web projects now. Ruby for the Micro.blog web platform, JavaScript for the React Native app. Nova is arguably the most modern, native Mac text editor, and regularly updated. Lots of depth and I haven’t even scratched the surface with extensions.

Ulysses: This is essentially my note-taking app. I sync to a Dropbox folder with thousands of little text files. I prefer Dropbox instead of iCloud so I can edit more easily in any app, with backups and restoring old versions. I put draft blog posts here, notes about projects, upcoming trips, and anything that isn’t code-related.

BBEdit: This is for everything else. Looking at JSON and XML. Processing large text files, find-and-replace, grep. As a quick scratchpad for code or notes that I’m going to throw away. I haven’t totally customized it like John Siracusa, but I do have a couple shortcuts and scripts that I depend on. Rock-solid app that has withstood the test of time.

Today we added Pixelfed cross-posting to Micro.blog. This joins our existing set of cross-posting services like Mastodon, Tumblr, Flickr, Bluesky, Nostr, and others.

Now you can post photos to your own blog, at your own domain name where you control your identity, and have Micro.blog send a copy elsewhere automatically. When posting, you can optionally select which services you want to include:

Because Micro.blog has built-in support for ActivityPub, your friends on Mastodon can also follow your blog directly without you needing to copy anything, or without you needing an account on any other platforms. There’s a lot of flexibility in how you want to configure this and which services you want to use. Some people even like to create a separate microblog just for photos.

As with all Micro.blog features, we’re looking forward to hearing how people use this. Photos are special, and there’s always more we want to do with them. We’ll continue to tweak the Pixelfed cross-posting based on feedback. Enjoy!

Today we are shipping a new feature for Micro.blog Premium subscribers: bookmark tags. This is a big improvement for using bookmarks, and it touches several parts of the platform and apps.

There is updated documentation for bookmarks with new screenshots. There is a new version of the Mac app: version 3.0, with not just bookmark tagging but also a new interface for seeing recent highlights.

Wait, highlights? Yes, a little-known feature in Micro.blog Premium is that you can bookmark anything, not just short microblog posts. When you bookmark web pages, Micro.blog downloads a copy of the text so you can read the web page later without all the clutter. In this reading mode, you can select text and save highlights to your Micro.blog account, making it easier to find passages of important text or blog about them later.

I recorded a screencast video here on YouTube with a demo of bookmarks and highlights. It’s 8 minutes long. 📺

We’ve been thinking a lot about how to improve bookmarks. One seeming disconnect is that your hosted blog uses categories, not tags. This was deliberate: categories are generally simpler and more obvious as a navigation aid on your blog for readers. In other words, categories were chosen as an optimization for your readers, and deciding to only have categories and not tags keeps the interface in Micro.blog streamlined.

You’ll need different tools to organize bookmarks, and you may eventually have thousands or tens of thousands of bookmarks. Micro.blog imports existing bookmarks and tags from Instapaper, Pocket, and Pinboard. The ad-hoc nature of tags is more flexible and optimized for quickly adding bookmarks, compared to blog posts where you may want to put a little more thought into where readers expect a blog post to live within a shorter list of categories.

We’ll continue to improve bookmarks as we hear from folks who are consolidating their data to Micro.blog. I expect there will be feedback about different workflows people are used to.

A note on pricing. Micro.blog Premium is our $10/month subscription, with the bookmark features plus podcast hosting, video hosting, and email newsletters. While nearly every other service in the world has increased their prices in the last few years, Micro.blog’s base subscription remains at $5/month. We can do this because we have customers who have upgraded to the optional $10 plan.

If you’ve been wondering about Micro.blog Premium, I hope these new features give you a reason to check it out. You can upgrade or downgrade whenever you want. We never delete your data when downgrading, so it’s always there if you want to come back to it.

Happy bookmarking! 🏷️

Dave Winer posted a 12-minute audio recording on his blog, addressed to me but applicable to everyone who is creating tools for the social web. Listening to it, I have a bunch of thoughts. In this post, I just want to start with server-to-server ActivityPub, and leave some of the other technologies Dave brings up for later.

A few days ago I was revisiting the ActivityPub code in Micro.blog because we have some interoperability problems with Calckey, now called Firefish. Firefish is a Mastodon-like platform with a few unique design twists and features. To narrow down where things were going wrong, I read through the ActivityPub spec again and also looked at JSON responses from other platforms like Mastodon and Bridgy Fed.

To frame this blog post I’ll put forward this question, at the heart of interoperability on the fediverse:

Is it possible to implement a social web platform by reading the suite of ActivityPub specs, and have that new platform be compatible with Mastodon?

I would argue no, it is not possible. A new project would only be compatible with Mastodon by accident because there are some things that are not spelled out in precise detail in the specifications, and no JSON examples that exactly match what any server sends or expects. The specs have all the pieces, but not how to fit those pieces together.

In addition to the specs, Mastodon’s own documentation is very good, and it has improved even in the last year. But again, if you ask a developer to implement ActivityPub, they will naturally start at the W3C.

I hope this doesn’t sound overly critical. The fact is, ActivityPub is complicated, and by design this kind of architecture can only be simplified so much. A lot of great work came out of the W3C’s Social Web Working Group, including IndieWeb standards, and I don’t think the authors had enough time to get consensus on some parts of ActivityPub before publishing, nor could they predict everything a platform like Mastodon or Micro.blog might need. Recently, Evan Prodromou has been leading the effort to address GitHub issues and move things forward.

I said “suite” of ActivityPub specs above because ActivityPub is not really one thing. There’s the ActivityPub spec itself, but also ActivityStreams, HTTP Signatures, WebFinger, JSON-LD, and the working group note on authentication.

And there are other features, such as account migration between instances, that are not documented outside of Mastodon. This is why the IndieWeb principles warn of monoculture. We are lucky that Mastodon cares deeply about the open web, because other dominant platforms might have less incentive to make their extensions work outside their own ecosystem.

The current fediverse is impressive. It’s further along than most people would’ve guessed possible a few years ago, largely thanks to Mastodon’s polish and Twitter’s implosion. The next step should be getting to the point where the answer to my question above can be “yes”. How can new developers add support for ActivityPub without feeling like they are reverse-engineering every existing server?

We don’t necessarily need a new spec, although it would be helpful to have a single document that ties everything together — a guide that a developer could use to build something and be confident that it has a chance of being compatible with other platforms. I also think we should consider further simplification, such as making JSON-LD optional (!) and drafting a streamlined version of ActivityStreams with only the bare minimum object types that most servers need.

There is a lot of work to do, even outside of ActivityPub. As Dave mentions, we also need a common posting API. The most popular Mastodon client apps do not support either ActivityPub or Micropub. But a lot of progress can be made focusing on interoperability for the server-to-server part of the API. That should be the top priority with Threads set to join the fediverse.

I’ve been blogging short posts this week about Meta’s launch of Threads, but I think it’s worth a slightly longer post with a quote from this interview with the head of Instagram, Adam Mosseri, on the Hard Fork podcast. Adam has a couple answers to why ActivityPub. The part that is most revealing to me is that he sees the industry going this way already:

I do think that decentralization — but more specifically or more broadly — more open systems are where the industry is getting pulled and is going to go over time. And for us, a new app offers us an opportunity to meaningful participate in that space, in the way that it would be very difficult to port an incredibly large app like Instagram over, and so to lean into where the industry is going.

This didn’t happen by accident. Many developers have been working to bring awareness to the problems of massive, centralize platforms — and bloggers and journalists have been doing the same — so much that users increasingly understand the value of decentralization and content ownership. Not everyone has jumped into Mastodon for various reasons, and not all smaller platforms have taken off, but it still helps get to where we are today that one of the most closed platforms ever (Facebook) is on the verge of rolling out support for an open protocol.

Eugen Rochko also blogged about this as an important milestone:

The fact that large platforms are adopting ActivityPub is not only validation of the movement towards decentralized social media, but a path forward for people locked into these platforms to switch to better providers. Which in turn, puts pressure on such platforms to provide better, less exploitative services. This is a clear victory for our cause, hopefully one of many to come.

What’s next? Imagine if later this year or early next year, Tumblr is able to follow through on their goal to support ActivityPub. Having such large platforms be even halfway interoperability was only a dream a year ago.

Meta is working on a Twitter-like platform called Threads, codenamed Project 92 or P92, rumored to support ActivityPub soon after launch. Some Mastodon instances are committing to proactively block it. I’m here to take the opposite view.

Meta adopting ActivityPub has the potential to fast-forward the progress of the social web by years. Ever since I grew disillusioned with Twitter a decade ago and started pushing for indie microblogs, then writing a book about social networks and founding Micro.blog, I could only dream of a moment where a massive tech company embraced such a fundamental open API.

I get the concerns. I’ve never trusted Facebook either. I don’t post to Facebook and in Micro.blog we had to disable cross-posting to Facebook after they burned us with API changes. But this is an opportunity with Threads that I’m going to celebrate because it could have a significant, mostly-positive impact on growing the fediverse.

Johannes Ernst raised an important question: will the fediverse grow faster organically, cut off from Threads, or faster with the chance to bring Meta users over to the larger fediverse? And I’d zoom out from that to the big picture: do we really want to be a community that discourages for-profit companies from adopting open APIs?

To succeed with mainstream users, the fediverse should encompass many types of platforms and business models. Not just open source. Not just volunteer-led instances. Micro.blog charges $5/month for blog hosting so we can keep doing this and growing for the next 20 years.

Let’s talk about data privacy. My blog is public already and Meta is free to crawl it and its connections to other blogs. Admittedly, there are problems… For example, Mastodon direct messages were a concern in SciComm.xyz’s decision to block Meta:

Federation would allow Meta to cache non-public data too, such as followers-only and direct messages, which pass through its servers as part of the normal workings of ActivityPub.

This is valid. It’s effectively a design flaw that direct messages can leak out in plain-text to Meta’s servers. The good news is that people are already thinking about how to handle encrypted direct messaging in future revisions of ActivityPub. There have been a couple recent discussions on the SWICG mailing list about this.

Unfortunately, it’s likely that Threads will implement only the parts of ActivityPub that serve Meta’s business, ignoring features such as account migration that would allow users to move their followers from Threads to Mastodon or Micro.blog. Before we judge Meta too harshly, I don’t think most non-Mastodon servers support account migration either, and even Mastodon itself doesn’t support post migration.

In other words, maybe we get our own house in order, so that if larger platforms come on board there are clear best practices for doing things the right way. There is still a lot to do. As impressive as the ActivityPub adoption has been over the last year especially — and kudos to Eugen Rochko and the Mastodon community for ramping up so well to welcome Twitter refugees — it’s still early days compared to where we can go.

I don’t worry about Meta embracing ActivityPub and then extinguishing the fediverse as we know it. I worry that all this pushback will force Meta to reconsider whether they should even bother. Maybe they give up and Threads is yet another silo, cut off from the rest of the web. Then the current fediverse will have to compete directly for users instead of collaborating on a more open vision where the walls of closed gardens are finally starting to break down.

Tim Chambers blogged about how we can react to Threads. Perhaps most important is to prioritize our existing communities:

And remember we only have to protect the 1.3 million monthly active users inside the Fediverse. And we do that now every day. Spammers and toxic accounts inside the P92 network we or our social graph don’t follow is their problem. Our problem is protecting our people.

For Micro.blog, we will not proactively block Meta. We will, however, build tools for users to choose how they want accounts to federate with Threads.

Our users are passionate about indie blogs. They often support small companies and distrust big corporate-y platforms. There could be an account setting to effectively opt out of Threads, just as someone can disable ActivityPub in Micro.blog and only participate in conversations with other Micro.blog users.

I can’t predict how Threads and ActivityPub will play out. Meanwhile, Twitter continues to melt down. Back in 2018, I chose to implement ActivityPub instead of trying to compete with Mastodon. And just this year, we added Bluesky and Nostr cross-posting to Micro.blog, to make it easy to get microblog posts out to these emerging networks.

Let’s build stronger connections across platforms. I don’t want a monoculture where a single platform dominates, whether it’s open or closed. The web will be better if we have a variety of platforms that can interoperate, and users have the power to choose where to host their content, what their web identity is, and who can connect to their posts. The default should be open.

I listened to the latest Core Intuition again to see if my initial take on Apple Vision Pro was way off or unfair. I think it holds up. Here’s a transcript of the conversation with Daniel, lightly edited.

Daniel: Hello, this is Daniel Jalkut.

Manton: And this is Manton Reece.

Daniel: And this is Core Intuition. “Something wrong about this product.” This week’s show is sponsored by RevenueCat.

Daniel: All right, Manton, as so many people are this week, you are traveling, of course, because it’s the most important week of the year for Apple ecosystem developers. So you are in…

Manton: Colorado. Haha, not California. I think I mentioned this a couple weeks ago that I had thought about going to Cupertino and planned a road trip around California again. And it kind of changed to Colorado.

Manton: So totally missed out on all the in-person stuff at WWDC. I did watch the keynote and I did watch some sessions. It was a big WWDC, really big. I’m still wrapping my head around everything and what it means.

Daniel: Yes, me too. A lot of podcasts, a lot of people commentating on WWDC start from the beginning of the keynote and progress through. I really enjoyed the ATP recap along those lines. I don’t think we have time for that.

Manton: No way.

Daniel: I think we jump right to the headset. Because the headset is… That’s the part that I’m still having trouble wrapping my head around. That’s the only thing, quite frankly, that I’m having trouble wrapping my head around. Everything else more or less about WWDC and the announcements made there makes perfect sense.

Manton: Yep. Lots of good announcements, lots of good OS updates.

Manton: Before we get into the headset, I think a lot of people have been lost in the reality distortion and have forgotten to follow up on the fact — I don’t know if ATP mentioned this because I haven’t listened yet, I haven’t listened to a couple of podcasts — but have forgotten to follow up on: did Apple do anything with AI?

Manton: I think the answer is no. Although they did mention transformer-based language models and machine learning, but they skirted around it. I don’t think they did anything significant with AI.

Daniel: Yeah.

Manton: And I don’t think they did anything significant with Siri. They dropped the “hey” from “hey Siri”, but I don’t think that counts. So I just want to point that out because we are so distracted with the headset, rightly so. I don’t want to give Apple a complete pass on totally missing the big story of this year.

Daniel: Agreed. And I was frankly a little surprised by that. I thought that they would… And as you know, I wrote an article about it a couple of weeks ago. I knew that my specific take on it, that they would announce something called Apple Intelligence and that would be their way of kind of owning the initials AI without having to join the pack, so to speak. I didn’t think that was necessarily going to happen. I would have been thrilled if it did.

Daniel: But I thought the minimum was going to be some, especially at a developers conference, something like, we’ve made a arrangement with Microsoft so you can run Copilot at native performance in Xcode. Something like that.

Daniel: It didn’t have to be Apple has reinvented AI. It just had to be: we we can see the elephant in this room.

Manton: No. They had a lot of good updates to Xcode. I mean, I watched sessions. I was really lucky, I was able to hang out with some of the other Colorado iOS developers up in Boulder yesterday. Watched some sessions with those guys.

Manton: And yeah, good updates to Xcode. No problems. But yeah, totally ignored anything with code generation as far as I can tell.

Daniel: Yeah. And real quickly, I’ll just say, I also said something about this. I said, oh, well, you know, sounds like they didn’t say anything about AI.

Daniel: And a few people chimed in, of course, with: well, of course they did. Like you said, the whatever mechanism transformer, blah, blah, blah.

Daniel: That’s not what we mean right now when we say AI. Right now, when anybody in this world we live in, who is not like an AI researcher says AI, they mean large language models and the way that they provide chat or completion based services to users.

Manton: Yeah. Assistant-like stuff and the way Apple is using, I think the transformer language model they were talking about, of course that is part of like chat GPT and whatnot. But I think they were talking about better auto-complete and behind the scenes, seamless stuff. Great. Fantastic.

Manton: But that is just not the same thing as assistants that help you and that feel intelligent, even if they aren’t.

Daniel: Right.

Manton: All right, headset. Vision Pro.

Manton: I was simultaneously blown away by this, and also I still really question the strategy. But from everything I can tell — I was listening to Dithering and Ben and John were just like, this exceeds our expectations of how technically good it is.

Manton: And so I’m trying to take a step back and kind of separate, did they nail this versus should they have bothered to build this?

Daniel: I’ve been joking for a while now, and I mean, the joke has totally come to a head with this idea that the reality distortion field is actually the product now.

Daniel: It’s hard to know, and I agreed with you, I was watching the keynote and everything is so stylized because obviously they can’t show you, or maybe they could, they definitely could show you what it looked like just from the point of view of the wearer. I’m sure there’s like a screen capture recording released in their debug builds right now.

Daniel: But obviously the way they presented it was kind of like giving you an idea by showing you video of a person who’s allegedly looking at the stuff.

Daniel: I actually had the thought during the keynote, wouldn’t it be cool if the way they made those videos was one person wearing a headset looking at a room that happened to have another person wearing the headset in it?

Manton: Welcome to the future, everybody’s wearing headsets, even when they’re in the same room with real people.

Daniel: Well, and that gets at the real… To be honest, when I say my version of wrapping my head around things has a lot to do with the social implications of what such a product means.

Daniel: I had the same gut reaction with Google Glass 10 years ago. You know, products that draw the user inward do not make me feel comfortable about them as social interactive products. You know what I mean?

Manton: Mmm hmm.

Daniel: And I mean, I guess to be honest, I wear my AirPods all the time everywhere. And I know there are people out there still who believe it is rude to be in public and to have headphones on, which I don’t agree with that assessment.

Daniel: And so that might be like kind of an instructive example of people have different takes. But my take is if you’re going to block your eyes out to the world, do not talk to me. Do not talk to me.

Manton: Haha. Yeah.

Daniel: And even with my AirPods, I have social standards, I take my AirPods out when I’m going to like a retail counter.

Manton: For sure. Yeah.

Daniel: And I find it very rude if people don’t do that. I forgive it if they at least turn off the volume and the person doesn’t know that, you know, I kind of forgive it. But the case of something literally covering your face, I don’t want anybody interacting with me like that.

Manton: No…

Daniel: And I definitely do not want anybody interacting with their kids during like pivotal moments of their childhood.

Manton: Yeah. And people will push back maybe on that and say like, well, at the birthday party, we all have our phones out anyway, taking video. It’s just not the same thing. It is not the same thing.

Manton: And I have missed things because I’m looking at my stupid screen. It’s just not the same as covering your face.

Daniel: I think it’s so instinctive to us that covering your face is a way of, I mean, like we do it as humans. We do it when we’re scared of something or we don’t want to engage with something.

Daniel: And I think there’s a lot of instinctive, like animal response to this idea that somebody’s face is covered. And the eyes showing through is very impressive, but very not enough for me.

Manton: Yeah. It was really impressive in the keynote, but I do wonder in real life if it’s just creepy.

Manton: And I wanna acknowledge that we’re judging a product that we haven’t seen. Like some people have actually tried it, friends of ours have tried it, and their opinion goes a long way. We’re just reacting based on what we’ve seen in the keynote and heard people talk and blog about.

Manton: But even putting that aside, I kind of went into the keynote thinking, if it’s technically amazing, would I still want to use it? And would I still develop for it?

Manton: And it turns out like it’s even better than I thought. Even my wildest like expectations of Apple just completely getting this right for what they’re trying to do, it’s even better than that. Super impressive.

Manton: And yet there’s something wrong about this product. And we’ve talked about like AR versus VR, mixed reality, etc. And I even more strongly feel now that I’ve seen it that the number of years I have in my head is 20 years.

Manton: It’s gonna take 20 years for this product to be more seamless with actual glasses-looking things that you can actually see through and people can see your real eyes. More like real AR, at least 20 years, if it ever happens.

Manton: And so it’s certainly a bet on the future, but it’s so far away. It’s so far from being a product that I could use in public, that I could use anywhere that there are people.

Daniel: Yeah.

Manton: I think that is an issue for me.

Manton: I was thinking about this last night, so I’m in Colorado. I’m going to campsites with this van that I rented and just seeing nature and whatnot. And last night I made dinner. I sat at my like picnic table at my campsite and I pulled out my laptop, popped open a can of wine and I caught up on some work.

Daniel: Haha.

Manton: I’m chilling out, kind of in nature, but there are other people around. And I thought, I’m working on my Mac. Would I put a headset on here? No, I wouldn’t. It would be so weird.

Daniel: Even in a fairly remote like.

Manton: Yeah. Because people might walk by, drive by, it would just be weird.

Daniel: You would be so self-conscious.

Manton: Yeah, I wouldn’t be able to concentrate. It wouldn’t matter how much better the virtual screen is than my 16-inch, old-fashioned screen.

Manton: And I think there are areas like that. I work in coffee shops every day. I was working at a coffee shop here outside Denver this morning for a couple hours. I just can’t imagine this product ever being used in that environment.

Manton: Like I said, in 20 years, maybe it’s more like AR and more like real glasses, but this device is so powerful. It’s more powerful than my own Mac. To get it to the point that it can be seamless around people, man, it just seems so far off. I don’t know.

Daniel: I think I’m not quite as pessimistic about the timeline that this technology stands a chance.

Daniel: It’s funny because if you compare it to some Apple products, the chances are not great that it advances very quickly. For instance, the iPad was released 13 years ago. So if it advances at the rate, and just to be clear, the iPad today is an amazing device, so much more advanced than the original, but on the whole, it hasn’t changed that much.

Daniel: The usage is the same, basically. And I think a lot of people expected a lot more development on that front.

Daniel: On the other hand, something like the iPod is about 20 years old and is now essentially something that you wear in your ear. And that is the kind, so just to say, yeah, 20 years, maybe you’re right in that respect. But I could see it happening a lot faster because the unique technological angle here is going to fund this thing.

Daniel: I think even with a very modest amount of buyers, even as a loss product, even if Apple were losing money, I think staying ahead of the pack on this type of product is going to pay dividends for Apple. And the saving grace for me is that I do think there is a point at which it’s kind of the difference between the AirPods being a helmet you wear over your head or the little device you pop in your ear.

Daniel: I still feel a little self-conscious sometimes about my AirPods, but if it were a helmet that I had to wear, you know? Like, this is the helmet, and we’re going to see, you know, assuming everything goes the way I expect, we’re going to see, I think, a lot sooner than 20 years, the equivalent of the AirPod of this.

Manton: Yeah, I dunno. Okay, but let’s think about that, though. The technological leap from wired headphones to the AirPods, I mean, it is significant. There’s, you know, cool chips in the AirPods that allow it to do what it does, but it’s not the kind of leap we’re talking about from a $3500 headset that has 12 cameras to something that looks more like glasses that you could wear in public, even if they’re awkward, bulky glasses.

Manton: I’m really having trouble with that leap. I don’t see how you can do it. And think about how far the iPhone has come from gen one, couldn’t take video, to today. The iPhone’s great, it has come a long way, but even that is not the leap that we’re talking about, or I’m talking about.

Manton: That is a very natural year-by-year evolution, and that’s their core product, where they sell hundreds of millions of these things. They’re not going to sell very many of these. They’re not going to update it every year. I’d be surprised if they update the headset more often than every three years. So we’re talking five or six generations. I don’t know.

Manton: Man, I hate to be so negative. I just don’t think this is a product that Apple needed to build, or that I personally am gonna be into. I don’t know. It’s cool, though. It’s really cool.

Daniel: It is, well, and like you, me hearing the dithering, John Gruber and Ben Thompson describing it as not being able to distinguish the edge of the quote-unquote screen. That kind of was a wake-up call for me.

Daniel: There is no product, I think, I think even all the other VR headsets, I don’t think there is a product in the world. The combination of like, whatever Apple did to make the thing sit so close to your eye, and the fact that it’s such a high resolution, there’s no product in the world where you can kind of fool your mind into thinking you’re looking at reality.

Daniel: And that’s why the whole reality kit, whatever, sort of all makes sense now.

Manton: And really, every time they say, “only Apple could combine blah, blah, blah”, I always kind of roll my eyes a little bit. It’s totally accurate in this case. There is no company that could have built this.

Daniel: Nobody else has the money to do the research and the social influence to make it, you know, even vaguely. Like some random little like company headed by a billionaire could have come up with something like this, and it wouldn’t have gotten traction because it wouldn’t have captured the public’s imagination.

Manton: Right, and only Apple, they have all the right skills to pull this off. And they don’t have a great track record of hobby products improving. I would say none of their hobby products have really improved very quickly, which makes sense. Their business is built around the iPhone and the Mac. Apple TV is more or less the same as it was, you know, a dozen years ago.

Manton: And that’s fine, but they obviously care a lot about this product and they could change that reputation. They could have this fringe side product that they pump millions and millions, billions of dollars into, and they’re patient.

Manton: Again, they wait 20 years and then you have the Vision Pro and you also have the Vision Air or the Vision Lite or whatever you want to call it, a more mainstream device that is not as bulky, not as powerful, something that more like normal people maybe would be into. That could totally work. It feels really far off. I’m gonna be old or dead by the time this happens.

Daniel: I think there’s two things that are remarkable about this product. One that struck me right away was how much of an amalgamation of other Apple technologies it is in one unit. And you think about all the things they’ve been working on.

Daniel: The little digital crowd is just like the Apple Watch. The cameras actually remind me of whatever research they may have been doing into self-driving cars. You have super high resolution screens. The audio playback in the device is also using that kind of room reading, LIDAR type stuff.

Daniel: That’s one aspect of how “only Apple” could do this because they had all these other products in the works that sort of contributed to this device. But I also think this device is, regardless of its commercial success, it is a technological test bed that can easily spin off other devices that benefit from the advances they make with this.

Manton: Yep. And I can definitely buy the argument that someone had to build this. That’s not true, but there’s value in building this purely for the research and technology and just to see what’s possible. Because if no company pushes the edge and tries new things, we don’t get anywhere. There is a role for pushing, just seeing what we can do, whether it’s a compelling product or not.

Manton: So yeah, I totally respect that. And I think the people that worked on this should be very proud of what they’ve built. It really does look incredible. It’s just a question of, strategically, is this something that Apple should do? Is it good for humanity? And then secondarily, for developers, is this something that should be part of our strategy or not?

Daniel: Right.

Manton: If this is the — again, 20 years in the future — this is the replacement for the Mac, is this something that we should be fiddling with and paying attention to and watching all the WWDC sessions and playing with the simulator. I’m curious what you feel as a mostly Mac developer, how much are you going to pay attention to this?

Daniel: Yeah. I mean, it’s so much to take in because as you saw during the keynote, there’s like elements of how it, how it stands to just like integrate with your Mac and show you your Mac desktop apps on like virtual monitors within the device.

Daniel: And then there’s the other angle of native apps for this thing, maybe subsuming the uses of traditional Mac software, iOS software, all the above. So I’m going to keep an eye on it. I do, my instinct is to mostly ignore everything, especially since there’s no SDK yet. And I find it kind of awkward to even consider jumping into WWDC sessions about this when there’s no hands-on opportunity to do anything, even with a simulator. So I’m going to keep a cautious eye on it.

Daniel: I think there is something to what, I mean, you know me, like both of us have been pretty dismissive of AR VR the past several years. And I think the way we’re talking about this still reflects our skepticism about it, but it brings it into the real world in a way that I don’t think is going away.

Daniel: Having a point your iPhone at a table AR experience never felt compelling beyond the slightest novelty. But let’s just assume that this thing didn’t cost $3,500 and it costs $350, which might be the case in five years, 10 years.

Manton: 20. I’m sticking to 20 years.

Daniel: Haha. Well, the situation will be different when there’s a massive market of people who have these things.

Daniel: And I just want to say one more like slightly optimistic thing. I think my reticence and spooked-outness about this device is somewhat to blame on Apple’s presentation of it during the keynote. The way that they tried to frame it as something in particular that you would wear, like I mentioned, like when you’re engaged with your kids during special moments, that’s the opposite of what I think this type of device should be used for.

Daniel: And if I focus on the things that it’s good at… I won’t fault any parent for wearing a welding helmet while they’re building, you know, a rocking horse for their kid. That’s a special moment in a family’s history as well.

Daniel: But let’s not try to conflate the wearing the welding helmet with spending special time with your kids. Likewise, I think there are a lot of parallels actually with this to a device like a television, because televisions are famously attention absorbing. You can’t really talk to somebody who’s watching a television. And frankly, in my opinion, having a television on in any kind of social environment, unless you’re like watching a sports game with somebody is not conducive to sports or to social interactions.

Daniel: But I think if I try to look at this more generously, as like, it’s another kind of TV, or it’s another kind of welding helmet. You use it on your own time for your own purposes to either entertain yourself or achieve specific productivity goals. Then a lot of my negativity about it goes away. It’s just the idea of it being integrated as an everyday piece.

Daniel: It’s the same idea as if I envisioned everybody walking around with a television hanging off their forehead. No, we, nobody really wants to live in that world. So don’t highlight that as the use case for this device.

Manton: Yeah, I agree with you. I think that was a bit of a miss. Overall, I think the keynote will go down as the best in years, but I feel like some of those parts of the, you know, advertisement video that we watched, basically, we’ll remember them a little bit like the watch Apple Watch introduction. There was a lot of sort of gimmicky features. You know, texting your friend in class or sending pictures.

Daniel: Sending your heartbeat to somebody.

Manton: Exactly. I think some of these things will go down in that light. I love the Apple watch. I’m wearing mine now, I wear it all the time. But I think they were a little bit confused about their message when they introduced the watch and they sorted it out.

Manton: And I think this is going to be the same way. I think we’ll look back on some of those and be like, no, we’re not putting this headset on for a birthday party. That’s not going to be right.

Manton: And really, that’s why I kind of think about just strategically. I mean, we already have this problem that we didn’t have 15 years ago, which is that the family is sitting around TV, watching a movie or something and all the kids are on TikTok. This is already an issue.

Daniel: Yeah.

Manton: I’m not interested in it getting worse by actually having people close their whole face off from the world. So I think there are really legitimate uses for this, but in my life, they are very small.

Daniel: Yeah.

Manton: I like to work out of the house, I like to go places. I mean, I’m kind of an introvert. I don’t meet a lot of people and hang out with people in person. But when I do, when I’m around other people, it feels good to be around humans. We need that.

Manton: And just strategically, I guess I’m really pessimistic about it. I think maybe it’s okay for us to have those two thoughts in our head of just technically and pushing the envelope, this is a huge breakthrough. On the other hand, as a human and as a developer, I’m fine. Zig when they zag. If everybody else is obsessed with this and WWDC over the summer, I’m fine focusing on other things and just continuing working on Micro.blog and working on these other aspects of social networking.

Daniel: Yeah, I agree. In a sense, I am kind of relieved that I don’t feel like I’m going to have my work cut out for me in terms of new Apple technology over the summer. None of this is like, oh, drop everything.

Daniel: The one product that I think might have a little bit of a compelling case is like Black Ink with the idea of maybe like solving a puzzle on a virtual sheet or something. Even that’s a little bit of a stretch, but you know, maybe against a flat desk or something. But I don’t know. Obviously I have other Black Inks to ship before I get to that.

Manton: Yeah. I want to ask you, because I don’t know if you saw Apple News+, I think has some crossword thing.

Daniel: Oh yeah. Yeah, I did see that.

Manton: We’ll probably have a whole show next week about everything non-headset related. There’s really a lot at WWDC and we’ll have to tackle that next week. Because the headset is just the obsession right now.

Daniel: Yep, agreed. All right. Well, I hope you continue to have a great trip. I’m glad that this time around we’re recording, you’re in your van again. If folks remember the last time Manton recorded in his van, it was like a rainstorm.

Manton: Yeah. And unfortunately… So I bought a new mic. That’s a whole ‘nother story about going to three different Best Buys, trying to find something that I could take with me. I did a test recording and there’s a lot of background noise still. So apologies, everybody. Hopefully it turns out okay.

Manton: But thanks everyone for listening this week. Enjoy WWDC, and we’ll see you in the metaverse. I dunno.

Daniel: See you in my glasses.

Today I sent the following email to everyone who had Twitter cross-posting configured on their Micro.blog account. We’ve got about one month left on our commitment to support Twitter cross-posting. We can’t justify paying Twitter for API access beyond that. Tweet while you can, the feature shuts down July 15th.

Hi @your-username,

You’re receiving this email because you currently have cross-posting to Twitter configured in your Micro.blog account. Twitter has been changing their API and we want to let you know how this affects Micro.blog.

Micro.blog has committed to support Twitter cross-posting until July 15th. After that date, cross-posting will be disabled. We hope this gives you plenty of time to wind down how you’re using Twitter.

Note that you may need to disable and then re-enable Twitter cross-posting if your blog posts are not currently being posted correctly after recent Twitter API changes. In Micro.blog on the web, click on Account → Edit Sources & Cross-posting.

If you’re curious why we had to make this decision, please see Manton’s blog post about it.

If you’re looking for other options for automatic posting to Twitter, you’ll find that most services have already stopped working soon because of Twitter API changes. We currently recommend looking into Buffer, which may be able to sustainably offer this feature in a way that smaller companies like Micro.blog cannot.

However, there’s good Twitter news too! We have launched a new import feature for importing an archive of all your tweets to Micro.blog. This is a great way to browse and search old posts, keeping a copy of tweets outside of Twitter.

For more details about the tweets import, check out this YouTube video.

Thanks for your support!

P.S. We also support cross-posting to Mastodon, Medium, Tumblr, Bluesky, Flickr, LinkedIn, and Nostr.

I’ve migrated the App.net posts archive to S3, to simplify hosting the archive. I’m not going to do any more work on this. No import feature for Micro.blog. The data files are there if anyone needs them.

Please only download your own posts, not everything. There are about 44 million posts in total. I’m happy to keep hosting this archive indefinitely as long as the costs are flat. I think it’s important to have an archive of as much of the web as possible. But at the end of the day, App.net was not my platform, just something I cared about, to help bridge the gap between the early days of Twitter and newer, more open platforms.

Don’t remember App.net? I wrote a chapter of my book about it.

Similar to my announcement last month about supporting Bluesky, we’re adding Nostr cross-posting to Micro.blog starting today. You can enable it under Account → Edit Sources & Cross-posting:

Nostr might have the most uncertain future among recent up-and-coming social web protocols. I’m fascinated with the architecture because it’s so different than ActivityPub, RSS, and IndieWeb protocols. I think it’s interesting and worth tinkering with. I’ve been personally using it through Micro.blog for about a week, so why not let other folks play with it too?

Nostr is quite technical. If you don’t want to be on the edge, feel free to wait. It’s so early that using Nostr feels like testing a prototype, letting your blog posts loose into the wild west of the internet to float between Nostr “relay” servers.

To get started, you will need a Nostr account. Unlike every other social network, in Nostr you don’t actually register on a specific server. Your account is just a private key, which you will paste into Micro.blog. For iOS, I suggest using Damus or Nos. For the web, check out Coracle.

These apps and others will create your private key, name, and profile photo. Make sure to save your key in a password manager. If you lose it, you lose access to your account.

Micro.blog’s support for these emerging protocols is essentially one-way, pushing your blog posts out to people on other platforms. Later we will consider federation, where posts and replies from other platforms and brought into Micro.blog, like we already do for Mastodon and ActivityPub. I’d like to see how much traction there is before we do more.

Micro.blog Premium includes an email newsletter feature, so readers of your blog can subscribe to receive posts by email. It’s designed around microblogs. For example, Micro.blog can gather up lots of short posts over the week or month and collect them into a single email.

Today we’re launching a revamped template system for these emails, bringing much more control over what the emails look like. You can edit the template to add a header or footer, or change the HTML tags completely.

Because emails are generated outside of blog publishing, we can’t really use Hugo directly for this. I’ve written a new helper app in Go to process the templates, so they feel as familiar as possible to people customizing their blog theme. (Hugo also uses Go’s templating language.)

You can see what the default email template HTML source looks like here on GitHub. Micro.blog plug-ins can also override this template! So you could have a plug-in that provided a new email design. There’s a help page here with more details about variables you can use in a template.

This is a major improvement. A couple things to keep in mind:

• The template is responsible for assembling posts together. Because it produces HTML, you can no longer edit the Markdown of the previewed email. Instead, you can add intro text, edit specific posts, or remove posts from the newsletter.
• The template could fail if there are syntax errors you’ve introduced in edits. Make sure to test your changes by sending a copy to yourself.

You can edit the template under Newsletter → Settings. If you edit the template and then install a plug-in with a custom newsletter design, it will still keep your changes. You can clear your custom template to revert back to the default template or a plug-in’s template.

If you’re not comfortable editing HTML, that’s okay. You can continue to use the email newsletter feature and ignore the custom templates. It’s just a little more power under the hood for folks who want it, and for plug-in developers.

A random conversation today made me curious about what countries I’ve visited in Europe. I got lost looking at maps and thought I might as well try to make a list.

Apparently 9 countries in the world:

• United States 🇺🇸
• Canada 🇨🇦
• Mexico 🇲🇽
• England 🇬🇧
• France 🇫🇷
• Germany 🇩🇪
• Italy 🇮🇹
• Greece 🇬🇷
• Switzerland 🇨🇭

And 29 states:

• Texas
• Louisiana
• Oklahoma
• New Mexico
• Arizona
• California
• Oregon
• Washington
• Idaho
• Utah
• Wyoming
• Colorado
• Mississippi
• Alabama
• Arkansas
• Georgia
• Florida
• North Carolina
• Virginia
• Maryland
• New Jersey
• New York
• Massachusetts
• Vermont
• Tennessee
• Indiana
• Illinois
• Missouri
• Alaska

Not counting cities I’ve just flown through without leaving the airport. Might’ve missed some, but still feels kind of low. As anyone who has followed my 30 days lists knows, I like collecting visits to places. Now a little inspired to finish seeing all 50 states.

Jean and I have been talking this week about what’s next to prioritize around the Micro.blog community. I often focus on technical improvements to blogs, but we’ve had some good momentum recently with community features too, such as rolling out profile pronouns, user blocking, and encouraging alt text in Discover. Starting today, Jean is also hosting monthly office hours to talk to folks on Zoom.

Halsted’s post about creating a safe and inclusive community is also on our minds, and there are a few points in particular that I think we can run with.

• Expanding community guidelines to demonstrate what we want to see, not just what we don’t want to see. The first step with the guidelines was to set a foundation for behavior that we would need to address with blocking posts or banning users. The next step could be to also summarize what kind of posts work well to keep the timeline safe and welcoming for new folks.
• Elevating voices in Discover. Jean is planning to write a post about how we approach curating Discover. There aren’t strict rules for this, and our own guidelines should and do evolve, but sharing our thinking will help the conversation. We are fully aware that Micro.blog is not as diverse as it can be. Improving this will touch many parts of the platform, including marketing.
• Maintaining a new community roadmap. We know the larger vision, but we don’t usually track every little feature request because it can be overwhelming and inevitably become out of date with current priorities. What we want to add, though, is making sure there is a public list of community features so important tasks aren’t lost.

Thanks as always to everyone who uses Micro.blog and has given us a chance to build something unique on the web. I know everyone has high expectations, and we do too.

At last weekend’s Micro Camp, we had a panel session with me, Jean, and Vincent where we answered questions from the live chat. We didn’t have time for all the questions, so I wanted to try to answer a few more that we missed. Here we go…

Re: long posts and how they get truncated in the timeline. Are there thoughts or plans for letting us control where that truncation happens? Using a tag in the feed or something. The way truncation works now seems rough.

No current plans, but it’s something that comes up from time to time and has been discussed on the Help Center. We use Hugo under the hood and it supports marking an intro paragraph summary by using the <!‐‐more‐‐> HTML comment. It’s possible that some form of summaries could be used in the timeline. In my experience, though, the more exceptions we add to the timeline, the more confusing it is. That’s why we’ve mostly stuck to a few very simple rules.

Is it likely that the success of updating the iOS and Android apps will influence development of the Mac app?

It will influence it only in that there will be more time for native Mac development using App Kit, because there will be less time trying to port features back and forth on iOS and Android. There are no plans to use the React Native code base on the Mac. The mobile UI doesn’t generally fit on the Mac, although there may be a few features we can borrow from Micro.blog 3.0 on iOS such as easier bookmark saving and the quick bar to switch between blogs.

Who is the best rock guitarist?

I just bought tickets to U2 in Vegas, so I’m inclined to say that The Edge has always been a favorite. Actually picking a single top guitarists is outside the scope of my skillset as the founder of Micro.blog. 😛

What are some of the features you can say “no” to?

One point I tried to make in the panel is that while we move quickly and often change priorities internally without much warning, the long-term vision for Micro.blog hasn’t changed. We want to make it easier for more people to use blogs, encouraging domain names and content ownership, and wrap that together with a safe, welcoming community. Every feature has some connection to one of those fundamental goals. So anything that goes against that is an easy “no”, like making posting more complicated with extra fields, adding ads, or turning the platform into more of a closed silo.

When we added muting to Micro.blog, there was a discussion about whether user blocking should be added at the same time. My feeling was that Micro.blog is built around public blog posts on the web, so blocking didn’t seem particularly useful, and might even give someone a false sense of confidence that a specific user wouldn’t see their posts. After all, the posts are available to RSS readers and just reading on your blog for anyone.

This is the kind of opinion a programmer would have, though. “Well actually, the post is available anyway if you just drop down to the command-line and type curl and…” I was thinking about this again watching Bluesky scramble to add blocking a few weeks ago. We try to be thoughtful and not reactionary, so this was really something we should have taken care of earlier.

This is all a long way of saying that our initial support for blocking is rolling out this week on the web and the API, and in other apps to follow. Blocking someone will prevent your posts from showing up in their timeline. There may be tweaks and other options added to this later.

I’d like to update our terms of service to add a note about reclaiming old accounts, so we finally have an official policy. In a nutshell:

• If you’ve ever had a paid subscription, we will host your blog indefinitely, even after you cancel. You can always export or delete your data, or resubscribe later and all your data will be there.
• If you’ve never paid and your account has been inactive for one year, we may clear it out so someone else can use the name. You will be notified before this happens.

I say “may” because I think there needs to be some wiggle room for unique situations. There won’t be any automatic deletion of accounts.

Not content with banning native third-party apps, Twitter has continued to cripple their API and move to paid plans for very basic access. I was committed to support Twitter cross-posting as long as possible because there are still Micro.blog customers who want to keep a foot in the Twitter world. But we knew it couldn’t last forever.

July 15th will be our last day to support cross-posting blog posts to Twitter. Even though Twitter has been effectively dead to me since I stopped tweeting in 2012, I’m a little sad to finally have to cut the platform off.

I picked July 15th to give people a couple months to wind down their use of Twitter. We now have to pay Twitter for API access, and that is the longest I can justify doing so.

It’s all another reminder that centralized platforms with closed APIs can’t last. While it’s easy to blame Elon Musk, the writing has been on the wall for a decade.

For more of the Twitter history that brought us to this point, see the chapter in my book called Leaving Twitter. Newly updated for Elon.

So, what’s next?

• Updating the Micro.blog web site to remove mention of Twitter. Luckily, we can now mention Bluesky instead! (When one door closes, another opens.)
• Emailing all Micro.blog customers who currently have Twitter cross-posting enabled, letting them know that the feature will go away on July 15th.
• Hiding the Twitter cross-posting option for new Micro.blog users.
• Later, shutting off the feature and removing all the Twitter code. At least we can do a little code cleanup because of this.

End of an era. Seeya on the open web.

I’ve done a little work now with the XRPC layer of the AT Protocol, supporting cross-posting to Bluesky from Micro.blog. This post is about what I’ve learned.

(As an aside, there have been questions about whether Micro.blog supporting Bluesky means we believe in everything they’re doing. No, right now I’m mostly interested in the technology. It’s still too early for judgements on the Bluesky leadership, user experience, or ultimately how this is all going to fit together with other social web protocols.)

Bluesky authenticates with a username and password. For third-party apps, the password can be an app-specific password. I hope that eventually Bluesky will support IndieAuth, a flavor of OAuth designed for signing in to web sites that should also work well for a distributed service like Bluesky.

The HTTP POST with JSON for signing in looks like this:

POST /xrpc/com.atproto.server.createSession
Content-Type: application/json

{
  "identifier": "email-address-here",
  "password": "password-here"
}

You’ll get back an access token and refresh token. Sessions do not last very long, only a couple hours last time I checked, so it’s important to keep the refresh token. The response looks like this:

{
  "did": "did:plc:abcdef12345",
  "handle": "manton.org",
  "email": "email-address-here",
  "accessJwt": "abcdefghijklmnopqrstuvxyz",
  "refreshJwt": "zyxvutsrqponmlkjihgfedcba"
}

The DID is a unique identifier for your account that is stored with posts on an AT Protocol server. Even if you change your handle, the DID persists and helps make data portable across servers.

When cross-posting from Micro.blog, I first try to use the auth token and if it fails, I use the refresh token to establish a new session. In this case, we pass the refresh token in the Authorization header:

POST /xrpc/com.atproto.server.refreshSession
Authorization: Bearer zyxvutsrqponmlkjihgfedcba

Sending a simple text post to Bluesky looks like this. For the rest of these requests, we pass the usual access token for authorization:

POST /xrpc/com.atproto.repo.createRecord
Authorization: Bearer abcdefghijklmnopqrstuvxyz
Content-Type: application/json

{
  "repo": "did:plc:abcdef12345",
  "collection": "app.bsky.feed.post",
  "validate": true,
  "record": {
    "text": "Hello world.",
    "createdAt": "2023-04-20T16:46:32+00:00"
  }
}

It can get more complicated. To include a photo with the post, first upload it to storage as a blob. In my early testing, there were low limits for photo file size, so Micro.blog scales photos down quite a bit before sending them over to Bluesky.

Here’s uploading the photo, passing the raw JPEG bytes in the content body:

POST /xrpc/com.atproto.repo.uploadBlob
Authorization: Bearer abcdefghijklmnopqrstuvxyz
Content-Type: image/jpeg

image-data-here

You’ll get back a media CID (Content ID) in the ref field that can be used to attach the photo to a new post. The response after uploading a photo looks like this:

{
  "blob": {
    "$type": "blob",
    "ref": {
      "$link": "abcdefgh"
    },
    "mimeType": "image/jpeg",
    "size": 200000
  }
}

Then when posting, use the embed field with an array of the uploaded media CIDs:

POST /xrpc/com.atproto.repo.createRecord
Authorization: Bearer abcdefghijklmnopqrstuvxyz
Content-Type: application/json

{
  "repo": "did:plc:abcdef12345",
  "collection": "app.bsky.feed.post",
  "record": {
    "text": "Hello world with photo.",
    "createdAt": "2023-03-08T16:46:32+00:00",
    "embed": {
      "$type": "app.bsky.embed.images",
      "images": [
        {
          "image": {
            "cid": "abcdefgh",
            "mimeType": "image/jpeg"
          },
          "alt": ""
        }
      ]
    }
  }
}

Bluesky also supports inline hyperlinks in the post text through “facets” that can be added to a post, similar to attaching a photo. I don’t love this because we already have HTML as a perfectly good way to format posts. I strongly believe that the social web should use HTML and HTTP wherever possible.

In Micro.blog, I automatically convert Markdown or HTML inline links to Bluesky’s facets. An example of linking the first word “Hello” in this post would look like this, using the character position and length of the word:

POST /xrpc/com.atproto.repo.createRecord
Authorization: Bearer abcdefghijklmnopqrstuvxyz
Content-Type: application/json

{
  "repo": "did:plc:abcdef12345",
  "collection": "app.bsky.feed.post",
  "validate": true,
  "record": {
    "text": "Hello world with link.",
    "createdAt": "2023-04-20T16:46:32+00:00",
    "facets": [
      {
        "features": [
          {
            "uri": "https://manton.org/",
            "$type": "app.bsky.richtext.facet#link"
          }
        ],
        "index": {
          "byteStart": 0,
          "byteEnd": 5
        }
      }
    ]
  }
}

There is also a growing list of open source libraries for the AT Protocol. Unfortunately I wrote all my code before I realized this, so I stumbled through deciphering the API more than I needed to. Maybe this post will save you some time if you’re rolling your own thing.

Update: HTTP requests go to bsky.social, not bsky.app.

Today we enabled Bluesky as an option in Micro.blog. This adds to our existing cross-posting feature that supports platforms such as Mastodon, Tumblr, Medium, and Flickr. When you post to your blog, Micro.blog can copy the post to any of these platforms automatically.

As Twitter continues to implode, we are seeing a renewed interest in the open web and decentralized social media. It’s an exciting time. Mastodon and the larger fediverse have grown to nearly 9 million users. Micro.blog is part of that with its support for ActivityPub, so Mastodon users can follow and reply to Micro.blog users directly.

While Mastodon and ActivityPub have most of the attention, I’m not entirely sure how this next generation of open protocols is going to shake out. I like how Bluesky is focused on domain names and data portability, principles that are shared by the IndieWeb and Micro.blog. Whatever happens with Bluesky, I think there’s inspiration here that can benefit other platforms as well.

That’s why we’re adding support for Bluesky now, even before the Bluesky folks have rolled it out to everyone on their waiting list. Micro.blog has never been about a single protocol. It’s about putting your blog at the center of your online identity, the place where you can post short posts, longer essays, photos, podcasts, or whatever else you want to share.

It’s still early. I’ll be watching how Bluesky evolves. There will be challenges to potentially intertwine different approaches to federation. But now is not the time to build walls. Let’s try a few things, new ways to connect platforms, knowing some might not pan out, because that’s how the open web gets better.

Tantek Çelik blogged about Mastodon’s account migration and its post export, which is based on ActivityStreams. No other apps really import this format yet, not even Mastodon itself. He also mentions the Blog Archive Format and how useful it would be to convert between Mastodon and this format:

Such a library would make an excellent drop-in addition to any #ActivityPub implementation, allowing both export of posts, and also a browsable archive format, so you could visually double check when importing to another service that these were the old posts you were looking for.

I’ve taken a first pass at writing a Ruby script to convert Mastodon’s export to Blog Archive Format. It’s available as a GitHub Gist here. It’s not packaged as a general-purpose library but certainly could be adapted for that.

Direct posts import from Mastodon will be baked into Micro.blog soon. We already support several formats — WordPress, Medium, Tumblr, Ghost — and I learned a lot about how best to process large archives while building the new Twitter import.

I haven’t written a new React Native diary blog post in a while because there hasn’t been anything noteworthy. We’ve shipped new versions of Epilogue for iOS and Android. Micro.blog 3.0 for iOS is almost ready — also a rewrite for React Native.

We did hit one feature that I wanted to preserve from the previous version of Micro.blog: Markdown and HTML syntax highlighting when writing a new blog post. The best way to preserve this was to port the Objective-C code over to React Native. (This feature won’t be available on Android yet.)

The “native” in React Native is because it uses native iOS and Android controls, even though they are driven from a JavaScript engine. This means we can make our own native components, written in Swift or Objective-C.

There are a few pieces of code to make this work:

• MBHighlightingTextView: a UITextView subclass, but it could be any control.
• MBHighlightingTextManager: a RCTViewManager class, helping us build an interface between JavaScript and native code.
• HighlightingText: a React.Component, wrapping up the native control.

Here’s a snippet of the MBHighlightingTextView interface:

@interface MBHighlightingTextView : UITextView

@property (copy, nonatomic) RCTBubblingEventBlock onChangeText;
@property (copy, nonatomic) RCTBubblingEventBlock onSelectionChange;

@end

And the MBHighlightingTextManager interface:

@interface MBHighlightingTextManager : RCTViewManager <UITextViewDelegate>

@end

For the MBHighlightingTextManager implementation, the important bits are the macros that define what properties we care about:

@implementation MBHighlightingTextManager

RCT_EXPORT_MODULE(MBHighlightingTextView)

RCT_EXPORT_VIEW_PROPERTY(onChangeText, RCTBubblingEventBlock)
RCT_EXPORT_VIEW_PROPERTY(onSelectionChange, RCTBubblingEventBlock)

RCT_CUSTOM_VIEW_PROPERTY(inputAccessoryViewID, NSString, MBHighlightingTextView)
{
  if (json) {
    NSString* input_id = [RCTConvert NSString:json];
    // ...
  }
}

- (UIView *) view
{
  // make a new MBHighlightingTextView and return it
  // ...
}

@end

Finally, the JavaScript side that loads the native component:

import * as React from 'react';
import { requireNativeComponent } from 'react-native';

const MBHighlightingTextView = requireNativeComponent("MBHighlightingTextView");

export default class HighlightingText extends React.Component {
  render() {
	return (
	  <MBHighlightingTextView {...this.props} />
	)
  }
}

Now we can simply use <HighlightingText> in place of <TextInput> in our XML when laying out the UI. Handlers like the property onChangeText will be referenced from Objective-C so we can call them in response to methods from our UITextView delegate.

I’m leaving some code out in the above examples for readability. And I have a bunch of code still to write, working in a branch of our project on GitHub. But already the basics are working, after (frankly) a lot of trial and error and sifting through the documentation, Stack Overflow, and even asking ChatGPT, which knows a surprising amount of how this works.

Nilay Patel’s Decoder interview with Substack co-founder Chris Best is excellent. If you’ve only seen the excerpt where Chris declines to answer Nilay’s hypothetical moderation question, that clip was not taken out of context. It is exactly how the interview went, but a small part, and they cover a lot about Substack’s business and the founder’s approach to the web.

I’ve been interested in Substack since the beginning because I think they get a lot of things right:

• Writers get their own space on the open web. It’s an email newsletter, but it’s also a blog with its own domain name and RSS feed.
• Writers own their subscription list. They can export email addresses of subscribers and move to another email newsletter platform.

It seems clear from listening to Chris that this focus on identity and portability is no accident. Substack believes in empowering writers, and giving them their own “island” on the web, largely free of platform rules. There is little need for content moderation because readers are actively choosing to subscribe to a writer, not stumbling on random viewpoints that may be offensive or controversial.

Enter Substack Notes:

• Notes uses the same “social graph” as the main Substack platform. You don’t follow people in the way you do on Twitter or Mastodon. You subscribe to both their notes and email newsletter, giving the writer your email address.
• Notes is driven by algorithms. By default, the first thing you see is an algorithmic timeline (“Home”) that shows you notes from both people you subscribe to and whatever Substack thinks you should see. You can then switch to an alternate timeline (“Subscribed”) with people you’re following, but even there you will see “restacked” notes or replies from other people.
• Notes has post permalinks at Substack, not at your own domain name. This is a major shift in identity and ownership.

This is a very different design than the rest of Substack. As it grows, Notes will have much more power to amplify viewpoints and be central to how users discover new writers. It will need to be moderated like a traditional social network. It will need some kind of lightweight following model instead of jumping straight to giving a writer your email address.

In the Kickstarter video for Micro.blog in 2017, I talked about how I viewed the distinction between the Micro.blog timeline (the social network) and the blogs we hosted (or that you can host elsewhere):

If we start to separate the publishing from the social network, it unlocks something. It empowers writers to feel like they own their work, even if that’s short posts. And it frees social networks to build a safe community, without worrying about censorship, because no matter what the networks do you can always post to a site with your name on it.

This has guided our approach to moderation all along. I expanded on it in several chapters of Indie Microblogging, especially the one called Open gardens. It remains a unique part of how Micro.blog works compared to pretty much every other platform.

Substack could adopt a similar philosophy with Notes. Instead, they seem stuck on… something. I’m honestly not sure why they haven’t thought this through in a little more detail.

I’m not rooting for Substack to fail, but I do think Notes needs changes. And while I’m offering unsolicited advice, they should drop the “building a new economic engine for culture” tag line. It means nothing. Forget about the VC money, the drama, whatever is happening with Twitter, and get heads down to build something that makes the web better.

It’s not all about Elon Musk. Ben Thompson has made variations of this argument on Stratechery and Dithering, but I wanted to quote this segment from the Sharp Tech podcast where I thought Ben particularly nailed it:

Part of the irony of everyone getting upset about Elon Musk killing all the third-party Twitter apps is that that’s what Twitter’s management should have done a decade ago. If you’re going to go in that direction, go in that direction. Instead they didn’t have the guts to sort of follow through in their strategic decision to its logical endpoint.

I stopped posting to Twitter in 2012 exactly because of this strategy. I’ve said that Elon has greatly accelerated what was already the path for Twitter fading into silo irrelevance. I wish I could come up with a less violent analogy, but what comes to mind is Twitter leadership in 2012 loading the gun and pointing it at third-party apps, but it wasn’t until 2023 that anyone pulled the trigger.

Elon deservedly gets most of the blame for Twitter’s recent chaos. But I don’t think Twitter was going to last forever under any version of its clown car leadership over the last 15+ years. In the long run we will be thankful that Elon is effectively putting the company out of its misery. We’re going to see innovation on the open web as third-party developers realize they are the ones who have actually been given new life.

Today we launched a new feature: importing an archive of your tweets to Micro.blog. This is available to all paid subscriptions and can be accessed on the web under Posts → “…” → Import.

Very early Micro.blog customers may remember that we used to have a Twitter import feature alongside our traditional blog import from WordPress, Tumblr, and other platforms. We disabled this years ago because I kept hearing from people who realized that it was a mess importing tens of thousands of tweets into their new blog. I’ve taken that feedback to build this new feature into something that I think works much better.

There are a few unique twists with how this works:

• When you import your tweets, we create a new blog in your Micro.blog account just for the tweets. This is in the format username-tweets.micro.blog. There’s no extra charge for this blog.
• This new blog stores all your tweets as blog posts. Micro.blog also copies any photos in tweets to this tweets blog.
• A new plug-in is installed that links your existing blog with the tweets blog. This plug-in provides a streamlined interface for browsing tweets by month or searching across all your tweets.

You can see my own tweets on my blog here: manton.org/tweets

Structuring the tweet storage this way means we can leverage many of the powerful features built in to Micro.blog:

• There’s a new API that the plug-in uses. You can make your own version of the plug-in from GitHub by copying its HTML and JavaScript. You can even access the API of tweets from apps and blogs outside of Micro.blog.
• The separate tweets blog is a full Micro.blog-hosted blog so you can use custom Hugo templates to make your own web interface for browsing tweets, or add your own domain name to it.
• If you have multiple Twitter accounts, you can create additional blogs for those accounts. The trick is to name the blog with a “-tweets” suffix. (We only include one extra tweets blog for free. The rest will be added to your subscription just like any additional blog.)

Because the storage is just blogs, you can use existing apps to manage the tweets and photos. For example, you can use MarsEdit to download and search all your tweets. It’s also easy to zap all your tweets and start over without touching your actual blog.

Some limitations: I’ve decided to only copy photos from the archive, not other types of media. If you have a lot of photos, expect this to take a long time as Micro.blog extracts the photos from your archive and uploads them to our servers. You can keep an eye on what it’s doing on Account → View logs. I expect we may tweak this as we get feedback from more people.

Enjoy! I hope this makes it a little easier to say goodbye to Twitter.

When I started building Micro.blog, I tried to limit dependencies on external platforms. The main connection is via cross-posting, which is an optional feature and not what I consider the core platform. So for example, I resisted integrating tweets into Micro.blog’s timeline, even as many people asked for it.

We are seeing now with Twitter’s implosion why that matters. I didn’t think Twitter was going to last forever, but Elon Musk has greatly accelerated Twitter’s fall beyond what I expected even when I was most pessimistic about massive, centralized platforms.

Even so, I find myself this week investing time into keeping Twitter cross-posting in Micro.blog going for a little longer. I’ve rewritten the API from version 1.1 to 2.0. Auth has to change to make that work, and an unfortunate side effect is that photo upload also has to change. I’m forced to simplify tweets so that they link back to your blog for photos.

Twitter’s paid API rollout have been chaotic. Bridgy developer Ryan Barrett found that Bridgy’s API access was shut off already, weeks ahead of the expected April 29th deadline:

The silver lining is, after all the chaos and destruction and flight to the fediverse, Twitter doesn’t feel nearly as important now as it did half a year ago.

Back in 2012 when I stopped using Twitter, I would never have guessed that 10+ years later I might be paying Twitter $100/month for the privilege of using the API. But I don’t like shutting off a feature without warning. The compromise I’ve come up with is to continue supporting Twitter cross-posting for a limited time.

Here’s where I see things going from here:

• After I finish testing the new Twitter code, I will deploy it to Micro.blog. This will happen within a few days.
• I will email every Micro.blog user who currently has Twitter cross-posting enabled, letting them know they will need to sign in to re-enable Twitter posting, and that the feature is winding down.
• We will update the documentation and provide some tips for moving away from Twitter.
• After 2-3 months, the Twitter feature will be turned off.

In a bit of “lemonade from lemons” good news, I’m working on something new for Twitter users that we can control. Tweet archive import! We had a version of this feature a few years ago in Micro.blog but had to disable it because it wasn’t quite right. I’m taking those lessons and also my experience building Tweet Library to make something that will last.

We’ve launched a new feature for Micro.blog Premium customers: automatic podcast episode transcripts, powered by OpenAI’s Whisper model. I’m excited about this because it’s one of the more practical, time-saving solutions coming out of the rise of AI. The automatic transcripts are so accurate they can be used as-is, or edited by hand as you have time.

I thought it would be clever to ask ChatGPT to write a blog post announcing this feature. You can see the result here. But I threw it out because I like writing my own blog posts!

At Micro.blog, we don’t usually reach for automation first. We curate the Discover section by hand, looking for posts that will provide a snapshot of activity on Micro.blog to help you find new people to follow. We don’t have trends and don’t have public likes or retweets. AI is going to reshuffle many tech products, but we’re never going to have an AI-driven algorithmic timeline. AI is a tool that we’ll only use when there is real benefit that aligns with our principles.

The new transcripts feature is available to anyone hosting their podcast on Micro.blog. When you upload a new MP3, Micro.blog will process it to generate a transcript. You can then edit the transcript or link it from your podcast page.

There is also a new Micro.blog plug-in to add a list of transcripts to your blog, as well as control options to disable transcription and link to the transcript from blog post. Search in the plug-in directory for “Transcripts” to install it.

There’s no extra charge for any of this. Micro.blog Premium has always been $10/month and it will continue to be priced that way. It includes podcast hosting and also email newsletters, bookmark archiving, web page highlights, and much more. We think it’s a great value.

In 2014, as I was starting work on Micro.blog, I blogged about the properties of a microblog post, including the character length:

I picked 280 characters instead of App.net’s 256 characters because it’s slightly less nerdy, and feels right at exactly double Twitter’s 140. This should be thought of as more of a guideline than a rule, though — just something to shoot for.

After that, Twitter also doubled their character limit to 280 characters. Mastodon launched at 500 characters. In the years since, it has felt less symbolic for Micro.blog to stick to 280 characters. Thinking about a post-Twitter world, 280 actually now feels kind of wrong.

Micro.blog is based on real blogs, so you can have full-length blog posts with a title, categories, photos, inline links, podcasts, and anything else you’d expect blogs to have. Those full posts don’t have a limit. It’s the Micro.blog timeline that encourages the 280-character limit to make the timeline as readable as possible, not cluttered with long posts or “read more” links.

Today we’re making the next big change to how the timeline works: we’re “rounding up” the character limit to 300, and for short posts that contain a block quote, we’re doubling it to 600.

Unlike some social networks, Micro.blog’s character counter is for the text you will see in the final post. It strips out any Markdown or HTML tags when calculating the length, so there’s no extra cost to italic text or links. And with the 600 limit for quotes, it’s more consistent to use Micro.blog’s “Embed” link to paste in someone else’s post from the timeline and know it won’t be truncated.

This gives posts a little more room to breathe. The posts are still short enough that it’s not a significant change to the reading experience in the way that bumping it all the way to 500 would be. It feels right for Micro.blog.

Micro.blog on the web, the Mac app, Android app, and beta of Micro.blog 3.0 for iOS on TestFlight have all been updated with this new limit.

There’s still more to do. We plan to adopt this change for Micro.blog replies as well, which have always been treated differently than regular posts. Because that’s a more disruptive change, we’ll roll it out separately in the coming months. We have some ideas for improving the UI for long replies to tie replies back to your blog. That will take longer to get right.

Enjoy the extra 20 characters! Happy blogging.

Today we updated the web version of Micro.blog (and the Mac app) to provide better control over how new posts are routed to external services like Twitter, Mastodon, LinkedIn, etc. Just like showing blog categories, you can show checkboxes and uncheck which services you don’t want Micro.blog to cross-post to. This setting is remembered only for the current post and by default posts go out everywhere.

This is a fairly big change. I expect we’ll learn more as people actually use it. I wanted to get it out for the web and Mac first because we can ship those without waiting for approval from Apple and Google. Mobile versions will follow.

Some of the gotchas you might run across:

• This is designed for setting on new posts. There’s no interface for changing it when editing a draft post yet.
• Micro.blog will only show the cross-post services you have enabled in Account → Edit Feeds. If you have multiple feeds, things might be a little weird if there’s no obvious mapping between feeds and your blog.
• This is for blogs hosted on Micro.blog. If you are posting to an external blog like WordPress, there’s no mechanism to customize cross-posting other than the existing global options.

We’ve also expanded our support for the Micropub API to include syndicate-to fields. This is well-covered in the spec. The Mac app is open source and uses the same public API.

Another week, another round of ActivityPub-related improvements! Over the last few months we’ve been filling in little details for Mastodon compatibility in Micro.blog. Were at the point where Micro.blog is a good fediverse citizen and has everything most people should need.

Today I rolled out initial support for setting a Mastodon profile header image. This is a feature that Micro.blog doesn’t currently have for its own profiles. Should it? I’m not sure, but in the meantime I didn’t want it to hold back anyone who likes profile headers on Mastodon.

You can upload a profile header in Micro.blog under Account → View Mastodon Details. When Mastodon users follow your account, they will see the header on Mastodon. Here’s a screenshot of part of the settings screen:

Micro.blog also does a better job of notifying followers on other servers when a profile photo updates. Mastodon generally has a different philosophy for storing images than Micro.blog does. Micro.blog loads most images as needed when they are viewed and caches them for a certain length of time, whereas Mastodon waits for a server to tell it that a profile or post has updated and then copies any images to its own server.

We could take most major features in Micro.blog and keep fine-tuning them indefinitely. Mastodon support is no exception, but I think this is a good time to pause. Next week I’m excited to revisit some pieces of the core Micro.blog platform that don’t necessary have anything to do with the fediverse.

One of the last missing pieces for Mastodon compatibility was improving DMs, which I rolled out yesterday. We don’t have DMs as a core feature on Micro.blog because I think private messaging needs to be handled very carefully, and not every social network should have its own messaging system. iMessage and Signal are better for this.

DMs just going into the void isn’t good either, though. The compromise we’ve settled on is that when someone from Mastodon sends you a DM, Micro.blog forwards that message to you in email. The email now includes a link to a form for you to send a reply back to Mastodon:

There is no message history and messages are deleted automatically after 60 days.

This is going to be the most frequent of frequently asked questions. If Micro.blog supports the fediverse, why doesn’t the new Tapbots app Ivory work with Micro.blog?

ActivityPub is a mostly server-to-server API that both Micro.blog and Mastodon support. This allows people on Mastodon to follow people on Micro.blog. When you post to your blog, the post is sent out to Mastodon folks, and they can reply and join conversations on Micro.blog all from within Mastodon. Likewise, on Micro.blog you can follow Mastodon accounts and reply to posts without needing an actual Mastodon account yourself.

For client apps like Ivory, Mastodon has its own API. It’s a completely different thing than ActivityPub, closer to the Twitter API. It’s not an open standard and Micro.blog does not support it.

Could Micro.blog implement the Mastodon API, thereby allowing Ivory to connect to Micro.blog as if it was a Mastodon server? Technically yes, but doing so would introduce a couple problems. By design, Micro.blog does not have exactly the same features as Mastodon. We left out boosts, trends, and follower counts, and added other things that are outside the scope of Mastodon.

If Micro.blog worked with Ivory, what would the UI look like when the features didn’t exactly match up? It would be confusing. Ivory would appear broken and it would disrupt the experience we’re going for with Micro.blog’s community.

As Mastodon becomes more popular, it’s important that Micro.blog stays true to its blogging roots and unique take on social media, rather than shifting to be a Twitter or Mastodon clone. We don’t need a monoculture with all apps looking exactly the same.

Micro.blog already supports multiple APIs for posting from client apps, including Micropub (which most IndieWeb apps use) and XML-RPC (which MarsEdit uses). I’m happy to add additional posting APIs like Mastodon’s, but only when we can make it fit well.

There are some obvious next steps.

I’d like to experiment with extending Mastodon’s /api/v2/instance endpoint to return Micro.blog-specific feature info. That way, clients like Ivory could in theory adapt their UI to fit the server capabilities. For example, if there are no boosts, hide the boost button. There is already precedence for this with Mastodon’s character limit and other common settings.

I’m also keeping an eye on Ice Cubes, which is open source. This app seems like a great playground to try out new features that work with Micro.blog. When those changes are prototyped, it will be easier to pitch Tapbots and other developers on supporting them.

It’s still early days in the post-Twitter world. I’m excited about what we have planned for this year. We’ll keep improving our compatibility with Mastodon and see what comes of it.

I was re-reading Craig Hockenberry’s post on the third-party Twitter apps shutdown. It’s a great post, channeling the frustration of so many developers and users. And I love that it’s on his blog, not as a tweet or toot. Ideas and writing sometimes need space to breath on the web.

Everyone had a different last straw with Twitter. It helped to have a villain in Elon Musk who could be blamed for every bad decision in the growing narrative of Twitter acquisition chaos.

But one problem with pinning everything on Elon is that it leaves open the possibility that maybe Twitter would be fine if the company was led by a different CEO who continued the Twitter API status quo. I don’t think so. Twitter wasn’t going to last forever because massive ad-based silos will always be at odds with the open web. Twitter’s recent implosion greatly accelerated what would need to happen regardless.

Today we got Twitter’s first public statement that the apps shutdown was about API rules. Remember back in 2012 they announced that apps could not have more than 100k users, even if popular apps at the time were exempted. There were other restrictions too, largely ignored. Third-party Twitter apps were living on borrowed time, strung along with false hope every few years as Twitter’s leadership drifted back and forth on whether to encourage developers or cut them off.

Craig also highlights open standards like ActivityPub in his blog post, and how the future shouldn’t be Mastodon-only:

Federation exposes a lot of different data sources that you’d want to follow. Not all of these sources will be Mastodon instances: you may want to stay up-to-date with someone’s Micro.blog, or maybe another person’s Tumblr, or someone else’s photo feed.

The sudden migration to Mastodon is going to make Mastodon look a lot like Twitter in the coming months. Don’t get me wrong: the migration is a great thing. Smaller social networks is one of the four parts I blogged about in 2018 for how to get out of the social network mess. But we need new apps and ideas too, to not recreate some of the same problems again.

Listening to Dithering this morning, which was a longer discussion following up on John Gruber’s post about the self-driving accident in San Francisco last week, I remembered a near-accident I was in a few weeks ago.

It was the usual morning traffic on the highway when cars stopped in front of me and I had to stop quickly. I watched in the rearview mirror as the car behind me narrowly missed me, moving to the side slightly, but the car behind that person swerved and clipped another car. Traffic kept moving around them and there was nothing I could do, just thankful that it wasn’t worse and that I wasn’t in the collision.

These kind of small crashes or near-accidents must happen hundreds or thousands of times a day. They don’t make the news, except as part of an update on rush-hour traffic. The same accident with self-driving “beta” software is more notable.

I guess I’m of two minds about self-driving: the technology enthusiast in me thinks autonomous vehicles will generally be safer than cars driven by humans, but I also think it’s largely a waste of resources to prioritize this effort. I’d much rather see the money and time put into better public transportation. It’s gotta be more efficient and safer to move people on a train.

Happy New Year! We shipped an update to Epilogue today that makes blogging about last year’s finished books more discoverable. If Micro.blog found any blog posts to include in your reading goal for 2022, it will show this at the top of the Goals tab:

Unfortunately I discovered after the calendar flipped over to 2023 that sometimes this button doesn’t show the right default new post text. I’m working on an update to fix that. (The button icon and spacing is also wonky.)

I’ve been going back and forth on how to expand the reading goals feature so that it can find more books. Currently it only works if you blogged about a book as you finished it. 2022 was a bit of an experiment, but 2023 is an opportunity for new habits. More blogging, less Goodreads.

We released a new version of Epilogue for both iOS and Android. I’m finally getting these platforms in sync. I think our bet on React Native is paying off.

This version adds a new post screen to your reading goals. As you blog about books you finished reading, Epilogue keeps track of them. At the end of the year, you can use the new post screen to compose a blog post with all the books you’ve read. Each book cover links to your blog post about the book.

You can see what my books post for 2022 looks like here.

This uses a new Micro.blog plug-in called Book reading goals. If you don’t have the plug-in installed yet, Micro.blog will automatically install it when publishing your blog if needed. (Epilogue works with any blog that supports the Micropub API, but this feature is only for Micro.blog because of the plug-in.)

Here’s a screenshot of the new screen on iOS. You can edit the text before posting.

With this feature, I’ve completed the transition away from Goodreads, and don’t plan on using it going forward. Good luck with your reading goals in 2023!

The year isn’t quite over yet, but the book I just started reading is going to take more than the next week to finish, so I think the books I read for 2022 is pretty much wrapped up.

During the pandemic I started to read much more than ever before. In 2021, I read 33 books, and this year I set a goal of 40 books, hitting it last week. I’m going to stick with that goal for next year too.

I’m also going to stop using Goodreads. Our Micro.blog companion app Epilogue does everything I need and it integrates with my blog, which is where I want my book reading progress.

I wrote a Micro.blog plug-in that makes it easy to add a list of books you’ve finished to your blog. So here it is below! Each book cover should link to the microblog post where I blogged about finishing the book.

The next version of Epilogue will have this feature built-in. I hope to get it approved by Apple and Google in time for the new year.

At Micro.blog we love books. We don’t love worrying about stats — no follower counts, no pressure! — but I’ve found that setting a personal reading goal helps me make time to read, and it’s fun to reflect on at the end of the year.

I haven’t been able to pin down exactly what I don’t like about AI-generated text and art, but I always got the sense that something wasn’t right about it. I like this post from Lois van Baarle, writing about artists protesting AI:

Many have compared image generators to human artists seeking out inspiration. Those two are not the same. My art is literally being fed into these generators through the datasets, and spat back out of a program that has no inherent sense of what is respectful to artists. As long as my art is literally integrated into the system used to create the images, it is commercial use of my art without my consent.

She’s an incredible artist with a very distinct style. If it was copied by a robot, you’d know. Go check out her Tumblr blog or books.

Micro.blog has always tried to put all the important URLs for your blog at your own domain name if you have one, including URLs for photos you post to your blog. I like this because it’s consistent with prioritizing content ownership, and makes migrating photos to another blog host easier in the future. We like clean, simple URLs.

Today we’re adding an option to enable serving photos from a content delivery network. This will update your photo URLs to use the CDN, while your home page and other blog pages will still use your own domain name. As your blog grows, especially with years of uploaded photos, this can really improve performance as people visit your blog from all over the world.

To enable the CDN, click on Design and look for the “ Use content delivery network for images” checkbox:

There is no extra charge for this feature, and it’s included in all plans. Happy photo-blogging!

Mastodon has a feature to move accounts from one instance to another instance. I spent some time recently exploring how this works so that we could support it in Micro.blog. I used this to consolidate my ActivityPub presence from multiple Mastodon accounts to just @manton@manton.org, powered by my blog and Micro.blog.

From what I can tell, this feature is not well-documented. It does not exist in the ActivityPub spec. The “Move” activity examples in the companion ActivityStreams spec also do not cover moving accounts. So I’ll document some of the technical bits here in the hope that it’ll be helpful to other folks.

To move accounts, 2 things are required:

• From the new instance, set up an “alias” that links your new and old accounts.
• From the old instance, initiate a migration to the new instance.

The Mastodon documentation says that aliases should be set up on both sides of the migration, but this does not seem to be required. In my testing, an alias is only needed on the new instance.

Because I wanted to move to Micro.blog, I added an alias in Micro.blog that references one of my old accounts: @manton@mastodon.social. You can find this in Micro.blog under Account → View Mastodon Details → Aliases.

Aliases are added to the ActivityPub profile information in the field alsoKnownAs. Here’s a snippet of my info:

{
  "preferredUsername": "manton",
  "name": "Manton Reece",
  "alsoKnownAs": [
    "https://mastodon.social/users/manton"
  ],
  …
}

For debugging, I often use curl on the command line to poke around at people’s accounts. To see my full ActivityPub JSON, use something like this with the “actor” URL returned from WebFinger:

curl -L -H "Accept: application/activity+json" https://manton.org/activitypub/manton

The next step is to sign into the old Mastodon instance and tell it to move to Micro.blog. Mastodon will take a few actions when this starts:

• It will verify that there’s an alias on Micro.blog, confirming that both accounts are yours.
• It will lock your Mastodon account, updating the profile to tell people about the new Mastodon instance. (In my case, actually powered by Micro.blog.)
• It will send a “Move” activity to all the instances for all your followers, telling them to update their references to point to your new username.

The “Move” activity is sent to each follower’s inbox just like other activities such as “Create”. It includes a field target for the new instance that the user is moving to:

{
  "actor": "https://mastodon.social/users/manton",
  "target": "https://manton.org/activitypub/manton",
  …
}

Mastodon won’t add alsoKnownAs to your ActivityPub profile on the old instance, but instead it will add a similar field named movedTo with the new actor URL:

{
  "preferredUsername": "manton",
  "name": "Manton Reece",
  "movedTo": "https://manton.org/activitypub/manton",
  …
}

Updating your followers can take quite a while. Likely hours and possibly over a day, if you have hundreds or thousands of followers. It makes sense that this is a very low priority background task. You can watch the progress as Mastodon essentially decrements your follower count on the old instance.

Here’s what Mastodon now looks like for my account, to tell people that I’ve moved:

This is a fairly new feature in Mastodon, and I expect we’ll need to keep refining our support for it as there is more real-world usage. If you’re using Micro.blog, also remember that Micro.blog is not Mastodon. You can follow and reply to anyone on Mastodon, but you can’t use Mastodon-only clients like the upcoming Ivory from Tapbots.

What about moving in the opposite direction, away from Micro.blog to Mastodon? We’ll be adding that later. ActivityPub is only currently enabled for new Micro.blog users, or if you’ve manually enabled it, so I want to wait until we’ve enabled it for all users. Otherwise there will be no way to move Micro.blog-only followers.

Last month I flew out to Portland and rented a van from Escape Campervans. The trip started because of meetings but it kept getting extended as I tacked on more places to visit. I posted some photos while I was on the road, which I’ll link again below, but I wanted to summarize a few thoughts now that the trip is over and I’m back in Austin.

It was a fantastic experience. I figured at the end of it, I’d either be completely burned out on the van lifestyle or ready to stay on the road. I’m glad to be home, but not burned out.

My daughter and son joined me for a few days at the beginning and end of the trip, too. It was great to share part of the experience with them and helped avoid loneliness while so long away.

Here are the main camping locations from the trip:

• Ainsworth State Park, Oregon. Literally the last night the camp was open before winter. Had the Multnomah Falls basically to myself because it was cold and rainy and kind of a miserable early morning outside.
• Fort Stevens State Park, Oregon. Loved exploring around Astoria. Planning to be back.
• Cape Lookout State Park, Oregon. Rained all night. Not good beach weather, but a good stop while heading down the coast.
• Umpqua Lighthouse State Park, Oregon. Still want to eventually visit all lighthouses on the west coast.
• Prairie Creek Redwoods State Park, California. Beautiful trees, so much to see in nearby parks. Driving through Avenue of the Giants was a highlight.
• Salt Point State Park, California. Beautiful rocky views of the ocean after the twisting turns of Highway 1.
• Courtyard at Fisherman’s Wharf, California. A hotel! Ditched the van in a parking lot for a day to explore the city. Felt luxurious.
• New Brighton Beach, California. Outside Santa Cruz, stayed here 3 nights. 10 minutes to nice coffee shops to catch up on work.
• Terminal 4, California. Interesting campground on the water, north of the Richmond Bridge. Abandoned buildings everywhere, felt like a post-apocalyptic drive to a view of San Francisco.
• Marriott at Union Square, California. Splurged on a hotel again for the final night. Saw Bono’s show at the Orpheum Theatre.

Stopped at many other parks, coffee shops, bookstores, and beaches along the way. I’m going to publish my check-in history later.

The timing wasn’t ideal because it felt like Twitter was imploding as I was on the road. There was a lot of new interest in Micro.blog. I worked a little every day, but some days not enough. Even so, having the flexibility to just pull over into a park and use my laptop on the table inside the van from anywhere was pretty great.

I can’t overstate how different it is to have a van to eat and work and sleep in compared to tent camping. It rained for a significant part of the trip, pretty much every day in Oregon, but it never ruined anything.

Feel very lucky to have been able to take this trip. I learned a lot of what to do and not do. Wasted some money on food I could never finish using. Spent a fortune on gas. Nervously navigated cities in a van larger than what I’m used to driving.

But the good days made it so worth it, and even with occasional extra stress of last-minute planning I felt that time slowed down… Awake with the sun, coffee and work, beautiful vistas, some driving, cooking dinner, popping open a can of wine, then reading and bed when it got dark. It was very freeing. I don’t think it was a midlife crisis, but I did feel a few years younger, reminding me of backpacking in Europe ages ago. After some months back at home, pretty sure I’ll be ready to get back out there.

We’re on the eve of the Elon Musk / Twitter deal closing. In his Dear Twitter Advertisers letter, Elon writes:

The reason I acquired Twitter is because it is important to the future of civilization to have a common digital town square, where a wide range of beliefs can be debated in a healthy manner, without resorting to violence. There is currently great danger that social media will splinter into far right wing and far left wing echo chambers that generate more hate and divide our society.

On first reading, this sounds pretty good. I agree that we shouldn’t be stuck in our own bubbles of misinformation. But the part Elon gets wrong is the premise that there should even be a “common digital town square” controlled by a single company. I reject that idea.

The common digital “square” should be the entire web, with a diverse set of platforms. There should be common APIs but many communities with their own rules, goals, and business models. Concentrating too much power in only a couple social media companies is what created the mess we’re in. The way out is more platforms, free to make the best decisions for their users knowing that there are options to leave and less lock-in for developers.

Twitter’s next few months or years should be interesting. Taking the company private is a good thing, to refocus the company and resources. But I expect chaos. Meanwhile, the mission of Micro.blog continues. Start a blog, get your short posts somewhere you control, and let’s get ready for a post-Twitter web.

Can’t believe it, but it has been nearly 4 years since we added ActivityPub support to Micro.blog. In that time, we’ve made some tweaks and bug fixes to it, but it has remained largely unchanged until today. If you were using a custom domain name for your blog, anyone on Mastodon could follow you, and you could follow anyone on other Mastodon servers.

Back then I blogged about why using custom domain names was important:

Sometimes in the Mastodon world your identity can get fragmented across multiple instances. You might start on mastodon.social but then move to another instance, effectively breaking the link between your readers and your posts each time you move, with no way to migrate posts between instances. By supporting Mastodon and ActivityPub in Micro.blog, you can consolidate your identity and posts back to your own blog at your own domain name.

There is a downside to this approach, though, and it has become more clear over the years. Because not everyone on Micro.blog has ActivityPub enabled, following users and replying often felt incomplete. To fix this, we are moving to enable ActivityPub by default for new Micro.blog users, and allowing it even if you aren’t using your own custom domain. We’re also improving conversations so they aren’t so disjointed, with Micro.blog now pulling in additional replies from Mastodon if needed.

If there’s no custom domain, what does the Mastodon-compatible username look like? @username@micro.blog of course! In this way, Micro.blog looks a lot more like another Mastodon instance, but an instance that also has a full suite of blogging features, IndieWeb protocols, and everything else we’ve been building for years.

It’s now easier to reset your Mastodon-compatible username too, for example when changing your domain name, or when moving from @username@micro.blog to @username@yourdomain.com. Mastodon itself has also added features to ease migration, and that’s something we’ll be looking at supporting.

In the future, we may do more to encourage everyone to enable ActivityPub on their Micro.blog account. For now, if you’d like to enable it, just head over to the Account page and click the “Set Mastodon-compatible Username” button.

Today we’re rolling out better support for attaching multiple photos to a post in Micro.blog on the web. The native apps have been able upload to multiple photos with a post for years, so it’s a little embarrassing that it has taken so long to get the web version updated too.

If you click on an attached photo, you will also see new options for removing the photo or setting a description for the photo, which is included in the HTML’s alt tag.

Attached photos are added at the end of a post. We think this streamlined approach to the UI is the best default for most people. If you want to mix the photos in between paragraphs of text, you can continue to use the “Copy HTML” button on the Uploads page and paste the img tag into your post. Our companion iOS app Sunlit also has more control over post layouts.

Note that these improvements do not change how photo posts are displayed in the Micro.blog timeline. Short posts with a single photo or a few photos are shown inline, and longer posts are truncated with a link back to your blog.

Enjoy! Happy photo-blogging.

Over the summer, Jon Hays and I started working on a new project to build a places database that can power location check-in apps. It’s based on OpenStreetMap, but focused just on places. We call it Meridian, and it has the amazing domain name latl.ong.

For years I’ve been using Foursquare to check into places like coffee shops, restaurants, and landmarks. I love having a record of places while traveling, and I’ve published many of them to a special blog. I just don’t like depending on a single company for this data.

Meridian is open source and separate from Micro.blog, but it will form the foundation for location check-in features in our apps like Sunlit and Micro.blog. You can see a little of what we have planned for Sunlit in these screenshots:

Why build something new like this? There seemed to be a missing platform for small location apps. Foursquare is increasingly interested in business customers. Google is full of ads. OpenStreetMap is a great start, but also has quite a learning curve. If all you want is nearby places, it’s too much work to bring along all the overhead of a full mapping API.

The architecture of Meridian will allow other platforms like Micro.blog to host their own copy of the data, feeding back into Meridian and OpenStreetMap. The goal is to design something as distributed as possible, where multiple people using different apps can add new places to grow the database, while still having an API that is simple to use. We’ll iterate on it slowly but there are already some pieces in place to start experimenting with. Should be fun!

Today we rolled out a new subscription option: Micro.blog Family, designed for up to 5 people with all the features of Micro.blog Premium. It’s $15/month and you can upgrade on the “Plans” page in Micro.blog.

Over 2 years ago we added a Teams plan with unlimited users, but it was never quite right. Micro.blog started around personal microblogs and it felt like too big of a jump to expect that larger companies would start using Micro.blog regularly. Micro.blog Family fits better with our mission and is a more natural upgrade for folks who want to bring family or friends together around a blog. I’m using it for a travel blog for my family, and we think it’s a good fit for photo blogs and family email newsletters too.

I’ve noticed this trend Jason Fried blogs about too, and I’m tired of it… We don’t need to be asked to rate every little thing! It generates a lot of needless busy work for everyone.

They ask me to rate my “experience”. Thing is, I didn’t have an experience. The delivery person just left the package by the mailbox and I grabbed it when I got home.

We’ve been using HelloFresh recently, and they also ask for a 1-5 rating for food deliveries. I always unpack the box first before rating. If the food arrived on time and in good condition, I give it a 5. If the food was damaged or spoiled, I call customer service. Not sure what situation I would rate something a 2 or 3 or 4, so the numbers can’t be that helpful to anyone.

All these rating prompts — from pop-ups on web sites, to text messages from my dentist asking how my appointment was — have become like noise, hardly better than ads.

Today we’re excited to announce an early preview of Micro.blog 3.0 for iOS. We are rebuilding the app to move closer to feature parity across iOS and Android. We’re updating the user interface based on years of feedback, adding a tab bar and cleaning up some screens in the app.

This is a major update, and it will take time to get right. The first 3.0 beta is missing several features from the current 2.3 release for iOS. Post editing, managing uploads, creating pages, external blog posting, and more will follow in later betas. There also is no special iPad split view yet. If you want to try 3.0, we’d love to hear what you think, but note that it may be months before the beta catches up with the current shipping iOS release.

You can join the new TestFlight beta here. You can’t have both versions installed at once. If you want to go back to the 2.3 release, just download it again from the App Store.

We have a bug fix update today for folks on Android! @vincent actually finished this version months ago but it had been hung up in Google app review for some reason. Finally got it approved.

• Fixed potential crashing bug when starting a new post.
• Fixed issues opening images in the image detail screen.
• Fixed loading latest profile photos.

Grab the update on Google Play. The next version is also coming along well, so expect more for Android this year.

I’ve used a few apps over the years for location check-ins. Gowalla, Foursquare, and Ohai, which was built on the App.net API. The Gowalla data was lost after they were acquired by Facebook. I’ve continued to use Foursquare and have imported many of those check-ins to my location site manton.coffee.

I have about a year of data from Ohai, from around 2013-2014. Before App.net shut down, I exported the data. I wanted to dust it off and import it into Micro.blog.

The data is stored in the App.net “messages” JSON. In some cases, there is annotation data that includes the location information such as place name for the check-in and latitude/longitude.

Here’s an example of one of the check-ins, cleaned up slightly to remove fields I don’t care about:

{
  "annotations": [
    {
      "type": "net.app.ohai.location",
      "value": {
        "address": "11521 N Fm 620",
        "country_code": "us",
        "latitude": 30.45419,
        "locality": "Austin",
        "longitude": -97.8271,
        "name": "Starbucks",
        "postcode": "78726",
        "region": "TX"
      }
    }
  ],
  "created_at": "2013-11-11T14:44:25Z",
  "id": "1922259",
  "source": {
    "client_id": "nymmngm43jnYP2FQ4pCvXjBpT3YyfNDa",
    "link": "http://ohaiapp.net/",
    "name": "Ohai"
  },
  "text": "Working after tacos. Hoping to get some coding done with an early start to the week."
}

I had originally used Ohai as a sort of private check-in journal, not intending it to be public in the way that Foursquare check-ins often are. But I’ve found that after nearly 10 years, semi-private data like this can usually be public without the same kind of privacy considerations that I would have worried about at the time it was first written.

So how do we get this data into Micro.blog? Micro.blog can import from a bunch of platforms, but it doesn’t make sense to add support for this file format directly to Micro.blog. It’s not something that most people would need. I wrote a custom script to handle this for my check-ins blog.

In the script, we’ll iterate over each message and look for the ones posted from Ohai, ignoring everything else. For some reason — maybe because I was offline or because of limitations in the App.net places database — not all of my messages included location information, but I still want to record the post and date because it included text I wrote about the check-in. If there is location information, we’ll pass that to Micro.blog too.

Here’s the script. If you want to customize it for your own use, make sure to set the app token and blog URL.

Micro.blog uses the Micropub API for creating posts. When there’s location information, we’ll pass a checkin field to store that with Micro.blog. We can then access that data from a Micro.blog theme, for example to show a map. See my book chapter on Micropub for details on the JSON format.

I had a lot of fun going through this old data and migrating it to Micro.blog so that it can be preserved. Eventually I want to have a Micro.blog-based client solution for new check-ins, starting with Sunlit for iOS, so that I don’t need to keep depending on Foursquare.

Last week we re-watched all the Mission: Impossible movies. 4, 5, 6, then 1, 2, 3. I think 4 is my favorite, but I can’t tell if my opinion is being influenced because I’m a Brad Bird fan.

Mission: Impossible 1 holds up. 2 is just a little over-the-top with the slow motion action scenes and doves, almost like a parody. 3 has the best villain, but is dark. 5 and 6 are really solid.

The most fun is knowing which stunts Tom Cruise actually performed. That guy is crazy.

Rewatching the full series so far, I also feel like there’s something important missing in between 3 and 4. Would’ve liked to see a 3.5 movie in there that covers Ethan Hunt’s marriage and its unraveling.

I’ve been thinking about why Apple’s decision to restrict Stage Manager on iPad to M1-based devices has caused so much controversy. At first, I was slightly annoyed that my brand new iPad Mini did not support Stage Manager. It is the latest, fastest iPad Mini you can buy, released less than a year ago!

You could argue that the iPad Mini is too small to take full advantage of Stage Manager anyway, but that wasn’t Apple’s justification. A future iPad Mini will surely be powered by an M1 and have more RAM.

I think the root issue is that when people choose a computer to buy, they don’t expect the operating system to change significantly for different computer models. You buy a more expensive Mac because it has a larger screen, or is faster, or has more ports. You buy a more expensive iPhone because it has better cameras. You buy a more expensive iPad because it has the latest Pencil support. It is a hardware decision, not a software one.

If you walk into an Apple Store today and pick out any Mac, from a $1000 MacBook Air to a $6000 Mac Pro, you can be confident that every feature of macOS will be available, and that all Mac apps will run, even if pro-level apps are going to run more smoothly on the Mac Pro.

I can’t think of anything comparable to such a major feature as Stage Manager being limited by hardware across a current, latest-generation product line. Maybe the closest is when Portrait Mode was first available. Portrait Mode is nice to have, but it doesn’t fundamentally change how you interact with apps in the way that Stage Manager does.

So I’ve adjusted my thinking on this controversy from shrug, that’s a minor bummer to now thinking that Apple’s decision should be walked back. John Gruber too, while he wrote that he understands Apple’s thinking on this, suggested that there could be a compromise in future betas:

Given the uproar surrounding this M1 requirement for Stage Manager, I wonder if Apple will reconsider over the summer, and perhaps do something like support Stage Manager on more iPads, but only on the built-in display, and make external display support the part that requires an M1 iPad.

Users on non-M1 hardware will understand if Stage Manager is slower or more limited — for example, no external display support or fewer windows open at once — and those limitations will naturally drive iPad upgrades. But it’s a unique and confusing precedent to have fundamental iPadOS features limited by hardware.

I take a lot of photos at coffee shops. For some reason this morning I thought it would be fun to create a page on my blog that just shows coffee photos. I already use Micro.blog filters so that whenever I include the ☕️ emoji in a microblog post, it assigns the Coffee category:

The next step was to create a template layouts/_default/coffee.html in my custom theme that would pull posts from this category. It grabs the latest 100 posts, then also checks if the post has a photo (“photos not equal nil”):

Finally, I created a template content/coffee-photos.md to tell Micro.blog to use that template when creating the web page:

Voilà! Looks pretty good.

We’ve come up with a new way to document changes to Micro.blog. In the past, we usually only note big changes on @news or on my own blog, so everything is scattered and small changes are rarely even mentioned. To fix this, there’s now a special category on news.micro.blog that will list most changes to the platform, both big and small.

I’ve customized the news blog home page and feed to exclude these posts, so if you’re following @news, you won’t get all the noise of the day to day changes that we roll out. And because it’s all powered by a normal Micro.blog-hosted blog, it’s something that is easy for us to maintain. If you really want to know about everything, you can also subscribe to this RSS feed.

We shipped version 2.5 of Micro.blog for macOS today. I had originally intended to just add a new Replies section of the app for this version, but it looked kind of lonely by itself, so I added Bookshelves too, with a multi-window interface for managing books you want to read or blog about. This uses our existing JSON Feed-based API for books data.

Here’s a screenshot of my bookshelves:

You can download the latest version from the help page or choose “Check for Updates” from within the app.

If you’re puzzled by why Micro.blog has all these book-related features… We have a lot of members of our community who love to read and write. If it’s easier to blog about books you’re reading, we can eventually build a distributed, web-scale alternative to Amazon-owned Goodreads. This won’t happen overnight. It’s a years-long goal and just one of many facets of the IndieWeb that we’re interested in.

Books are also great for mental health and thoughtful commentary, broadening our understanding of other perspectives, which maybe the world could use right now.

Blogging and outlining share a long history together. Userland’s Clay Basket could create a full static site from an outline. NetNewsWire 1.0 had a built-in outliner for notes and blog publishing that would later be spun out as MarsEdit.

Recently there have been new outliners that work with Micro.blog. I blogged about publishing to Micro.blog via Dave Winer’s Drummer. Maurice Parker wrote about his Zavala outliner and integrating it with Micro.blog via Shortcuts.

Bike is a new Mac outliner from Jesse Grosjean of Hog Bay Software. It has a clean interface that feels closer to a text editor than most outliners, and it can save as OPML and plain text. I’m also fascinated that the native .bike file format is just HTML.

I wired up publishing from Bike to Micro.blog with Maurice’s Humboldt that provides Shortcuts for Micro.blog. It looks like Bike has great AppleScript support. You can iterate over the rows in an outline, or you can just grab the contents as HTML like this:

tell application "Bike"
	set doc to front document
	export doc as bike format
end tell

Note that the export command requires a paid Bike license.

You can download my test shortcut here. It’s a little hacky. It strips out the HTML header/footer with a simple find-and-replace in Shortcuts. It will need a little more work if you want to clean up the outline and publish real blog posts with it.

Sometime recently, Safari’s back button keyboard shortcut ⌘← stopped working. I’ve preferred this to ⌘[ because it’s much easier to reach when my right hand is on the MacBook Pro trackpad. Unfortunately I can’t seem to reset this using System Preferences.

After a few days of unsuccessfully re-training myself to use ⌘[, I gave up and reached for FastScripts to rewire the ⌘← shortcut. I wrote the following AppleScript:

tell application "System Events" to keystroke "[" using {command down}

Then set it in FastScripts to only be used when Safari is running. There’s got to be a more straightforward way to get the old Safari behavior back — and this solution annoyingly interferes with moving the cursor if a text field is focused in a web page — but for now I’m up and running again.

Today we launched a design update for the Micro.blog web interface. Vincent has been working on this with a focus on the mobile interface especially, and it looks great on the iPad as well.

In the previous version, when viewing on mobile the sidebar would collapse and you’d get a hamburger menu that was clunky to use. Now, the most important menu items like Timeline, Mentions, and Discover will move to the header, with a new popover menu for accessing other features.

You can see the new layout even on desktop by just resizing your window smaller. Here’s what the header looks like on tablet and at small desktop window sizes:

And on the iPhone, with the new popup menu open:

We are very excited to roll this out. The iOS and Android apps will always be a great choice for posting or checking replies, but they can’t do everything the web version can do. The web version of Micro.blog is now much nicer to use everywhere.

I sent the following email to anyone who was early to pre-order the book Indie Microblogging. My main goal was to inform people who might have pre-ordered a year ago that we lowered the price, and that they can update or cancel their order if they need to.

Sidenote: We use SendGrid to send email and despite disabling all the tracking in the settings, SendGrid still appears to put tracking info in the email. I hate email tracking and have reached out to SendGrid about how to really disable this in the future.

Thanks for pre-ordering the book Indie Microblogging! You are receiving this email because you were one of the very early pre-orders, from last year or earlier. If you haven’t heard the latest news about the book, the complete draft of the book is now available here on the web: book.micro.blog

Because you were an early pre-order, a couple of things have changed. I lowered the price of the e-book from $20 to $15. I also added a print edition as an option.

What’s next? We saved your payment information securely with our payment processor Stripe, but we have not charged any orders yet while I wait to finish completing the book this month. You have a few options from here:

• If you still want the e-book, no need to do anything! You will be charged the new lower price of $15 and will receive an email with the e-book in ePub and PDF formats when it is ready.
• If you no longer want the book, email help@micro.blog and I can cancel your order.
• If you want to upgrade your pre-order to also include the print edition ($30 total for both e-book and paperback), also email help@micro.blog and let me know.

For more details about the book and current status, watch this video I recorded for Kickstarter backers.

I’m reading through Mozilla’s vision for the evolution of the web. On web sites being too difficult to create:

Building websites has gotten substantially easier in many ways, but it’s also become more complex, and there remain a number of pain points which make the experience more difficult than it needs to be. This has several negative consequences. First, it disempowers site authors by hampering their ability to express themselves. Second, it drives content to native app platforms, which diminishes the Web’s reach. Finally, it encourages centralization by tilting the playing field towards large publishers and platform providers with sophisticated engineering teams and complex infrastructure. Our goal is to reverse these trends by making it easier to build and maintain sites.

There is a lot of good stuff in this document.

Today we rolled out a few improvements to bookmarks, including an import from Instapaper and Pocket. This is meant to complement Micro.blog’s bookmark archiving, where Micro.blog archives a copy of a web page and allows making highlights in it. Like the archiving and highlights, the import feature is for Micro.blog Premium subscribers.

I’ve personally wanted to consolidate my bookmarks to Micro.blog, because I’ve had some things in Instapaper and some newer posts in Micro.blog. Micro.blog is not designed as a replacement for every feature in other read-later services, but instead a quick way to save links and either reference them later or start a new microblog post from a highlight.

To learn more about bookmark archiving and highlights, check out the video in this post on the news blog from when we announced Micro.blog 2.0.

I’ve also improved other aspects of bookmarks, like faster loading, paging through many hundreds or thousands of bookmarks, and better profile icons for domain names that are added to Micro.blog.

I designed the structure of the Indie Microblogging book knowing that most people weren’t really going to read it front to back. Everyone is busy. Even people excited about the book are probably going to skim some of it or dip in to just a few chapters. That’s totally fine and why it’s linked the way it is with 70+ short chapters.

It has only been a couple days, but even just the “this looks good!” feedback is so encouraging. Thank you. I’m inspired to edit it, fix problems, and get the final e-book and print copies out to everyone.

There have also been a couple mentions that especially made my day, and I can’t help sharing them.

Patrick Rhone:

I have to say, @manton’s Indie Microblogging book draft is really great. Reads like a manifesto. Full of “Hell Yeah!” ideas.

Jim Willis:

High schools should be building technology curriculum around @manton’s book.micro.blog Teach kids how to take action, how the Internet works, why open standards and decentralization are paramount. So good.

I’m in Portland now and my attention is shifting to Micro Camp 2022 through the weekend. But I’m hoping to make even just a little time every day to work on the book now that it’s out there, so the draft keeps getting better for new folks who are checking it out.

I posted an update to Kickstarter backers today with a video of me talking about the Indie Microblogging book and next steps. I’m including a copy of the video here, followed by a transcript.

Hello Kickstarter backers. My name is Manton Reece. It has been a while, and I wanted to give you an update.

If you’ve forgotten, the Indie Microblogging Kickstarter was for 2 things. First was a new social network and blogging platform called Micro.blog. We launched this pretty soon after the Kickstarter wrapped up, and in the last 5 years it has really improved to be a full-featured blogging platform. Photo blogs, categories, new themes, a plug-in system, team blogs, email newsletters. And I rewrote the backend recently to be powered by Hugo, so you get some of the benefits of a static-site generator but with full native apps for iOS, macOS, and now Android. There are third-party apps, and of course an API and support for IndieWeb standards.

The second part of the Kickstarter — and that’s what I want to talk about today — was for a book. And again, I’m very sorry that it was so delayed. The book has taken a back seat as I focused most of my time on Micro.blog the last few years.

Today I’m happy to announce that the complete draft of the book is available. In the Kickstarter I promised ePub and PDF versions, but as I was working on it I realized that a book about the web should also be on the web. So you can read it now at book.micro.blog.

The book turned into a much bigger project than I expected. It is divided into 6 major sections, covering older social networks and blogging platforms and what we can learn from them, the foundation for indie microblogging, how Micro.blog works, IndieWeb standards, owning our own content, Mastodon, community management, and more. There are interviews in the book.

There are about 70 short chapters, and each one is on the web so it’s easy to link to.

So what’s next. I still have improvements I want to make to the book. I will be editing it over the next few weeks. When the editing is done, I will be sending out PDF and ePub versions to y’all, and I’ll also be preparing the print copy for anyone who backed the Kickstarter at the higher tiers.

Last year I collected some of my blog posts into a book, partly to test the printing process for the Indie Microblogging book. And this is what it looks like.

The cover will be different for Indie Microblogging, of course, and it will be thicker. Indie Microblogging is about 400 pages when printed. But otherwise it will be very similar to this. I’m really excited to get it out.

So that’s the update. Thank you so much for your support. For your patience. If you haven’t checked out Micro.blog in a while, it is way better than it has ever been. If you never used your free months that you got from the Kickstarter, feel free to drop me an email to help@micro.blog. I’m happy to update your account to give you more time with the blog hosting.

And finally, this week, we are actually having a free online conference for the Micro.blog community. It’s called Micro Camp. You can go to micro.camp to learn more if you’re interested. Thanks so much. Bye.

It took longer and grew into a bigger project than I expected, but I’m happy to announce today that the draft of Indie Microblogging is now available on the web at book.micro.blog.

70 short chapters. 400 pages when printed. Interviews. Hundreds of quotes and links. I think it’s a unique look at social networks, blogging platforms, IndieWeb standards, and of course Micro.blog.

I’m traveling today, but when I’m settled in with good wi-fi I’ll also be posting a video update to Kickstarter.

What’s next? I’ll continue to edit the book this month and then prepare the final version in PDF, ePub, and print formats for Kickstarter backers. If you missed the Kickstarter, we are also accepting pre-orders for the e-book or print edition.

I heard from a user this week that some screens in Epilogue aren’t very accessible with VoiceOver. To be honest I was so focused on getting this release out, I didn’t test accessibility. Most of the buttons and views do have good defaults for accessibility, provided by iOS, but there was one pattern I was using with React Native’s <Pressable> that needed to be updated.

This is the JSX code I have for showing the profile photo in the navigation bar, which can be tapped to show the profile screen:

<Pressable onPress={() => { onShowProfile(); }}>
  <Image source={{ uri: avatar_url }} />
</Pressable>

To fix this, I first tried adding an accessibilityLabel attribute to the <Image>, but I found it works better on <Pressable>, where the role can also be set to “button”:

<Pressable onPress={() => { onShowProfile(); }} accessibilityRole="button" accessibilityLabel="show profile">
  <Image source={{ uri: avatar_url }}  />
</Pressable>

There is more I could do, but as a first pass these kind of tweaks should make Epilogue much more usable in VoiceOver. I did a quick run-through with Accessibility Inspector to catch similar problems. After I test on my iPhone, I’ll roll these into a bug fix update.

Yesterday’s IndieWeb session gave me a lot to think about, and a couple specific next things to work on:

• Micro.blog should be able to easily publish your book lists in different public formats. It now can. When you set a bookshelf to a page on your blog, Micro.blog will also create JSON Feed and OPML files with it. For example, here’s my Want to read page as index.json and index.opml.
• Micro.blog and Epilogue should move to using an API for managing books that could be supported in other platforms. I’ve now proposed a way to extend Micropub to cover this.

I’ve also submitted Epilogue 1.2 to Apple for review, with Micropub posting support and a few bug fixes. After it’s out, I’ll try to get a release for Android ready too.

Also posted to IndieNews.

I’ve been improving the profile screen in the new Epilogue to support adding external blogs via Micropub. You will still manage your bookshelves with Micro.blog, but the posts can go to another blog.

Here’s a screencast video that shows off most of the UI for searching for books, adding books to a shelf, and configuring an external blog. In this case it uses the IndieAuth and Micropub plugins for WordPress.

The goal in my experiments with React Native is to build an app that feels as native to iOS as possible. Early on I tried to use SF Symbols and couldn’t get it to work, so I dropped in some custom icons instead. But the more I used the new version of Epilogue on my iPhone, the more this compromise bugged me.

I briefly considered exporting the symbols I need as SVGs or PNGs and using them in the app only on iOS, but that’s against Apple’s license. Not worth even the small risk. Sticking to real SF Symbols also ensures the icons match other apps if Apple redesigns them slightly in future versions of iOS.

I revisited using SF Symbols today with the component birkir/react-native-sfsymbols. A default install shows a runtime error when attempting to load a symbol. Luckily there’s a work-around mentioned in one of the issues.

I copied this file from the repo and saved it as SFSymbols.tsx. Then instead of importing from the Node module, I just import that file:

import { SFSymbol } from "./SFSymbols";

It works! Here’s a quick screenshot of my navigation bar now:

Some thoughts after about a week of using React Native to rewrite Epilogue. It’s going well and has been fun to work in a new framework, knowing that it’s going to contribute to our long-term plan for mobile apps in Micro.blog. It’s not a throw-away distraction.

It’s only by diving in that I’ve realized how surface-level my experience with JavaScript really is. I’ve taken some time to experiment more with JavaScript promises and async functions. Years ago I bought the book JavaScript: The Good Parts, but I’m not sure I did more than skim it, and it’s probably way out of date for modern JavaScript.

I got pretty far into development over the last week even though I barely understood some of the React features I was using, like useState. That’s okay. After I ship Epilogue 1.1, I’m going to go back and clean up a few things.

Xcode builds are slow and spin up the fans on my Intel-based MacBook Pro every time, but iterating on the UI and features is extremely fast because the JavaScript code can reload while the iOS app is running. In most cases, the UI refreshes automatically in the iOS Simulator when I save my Styles.js file in Nova. I rarely need to run a build in Xcode.

App file sizes are bigger, but not enough to matter. Epilogue 1.0 was a tiny 0.5 MB, and my latest build of Epilogue 1.1 is 2.7 MB. A much more full-featured app, Gluon for Micro.blog, is 8.6 MB. This appears to be a non-issue.

React Native is not new. It’s nice not to be on the cutting edge, because by now every problem I’m likely to run into has been solved. Some things I thought might be hard were easy enough, like handling the epilogue:// custom URL scheme.

I’ve collected all the blog posts in this series in a category on my blog.

I’m continuing to plow ahead with the Epilogue rewrite. I’ve added a storage class to wrap AsyncStorage, making it easier to persist various bits of data. I’ve added searching for books using the Google Books API, largely copying JavaScript code from the previous version. The fetch() calls are the same between web browser-based JavaScript and React Native.

Today I’m working on adding the posting screen. This shows a modal text view with some default blog post text for the current book, so you can quickly blog about what you’re reading:

Just like the navigation controller, the modal uses React Navigation so that it looks and feels the same as any native iOS app. In the JSX, we add a group containing the new modal screen declaration:

<NavigationContainer>
	<Stack.Navigator>
		<Stack.Group>
			...
		</Stack.Group>
		<Stack.Group screenOptions={{ presentation: "modal" }}>
			<Stack.Screen name="Post" component={PostScreen} />
		</Stack.Group>
	</Stack.Navigator>
</NavigationContainer>

For this version, I’m using a simple multi-line TextInput class. This appears to use a real UITextView under-the-hood.

One thing I’d like to experiment with later is integrating the Markdown syntax highlighting Objective-C code from the current Micro.blog app, making it a component that we could use in multiple apps. It obviously wouldn’t work on Android, but we’ll need something like it when we’re ready to switch the official Micro.blog iOS app over to React Native.

Even though Epilogue 1.0 was simple, it did support Dark Mode on iOS. I always run my phone in Dark Mode, so I didn’t want to lose that when rewriting Epilogue in React Native.

There are a handful of helper utilities to access iOS-only features in React Native, like Platform.isPad . There’s also useColorScheme, which can be used to check if we’re running in Dark Mode:

const is_dark = (useColorScheme() == "dark");

There doesn’t appear to be built-in support in React Native to use different sets of styles automatically. There are, however, at least a few third-party libraries to make this easier, including various dynamic stylesheets and React Navigation’s themes. I started to go down that rabbit hole, then stopped… There’s a lot to learn and I’d rather adopt a quick “worse is better” approach to first get a feel for how painful it is to style my views manually.

I have a Styles.js source file that looks like this, controlling layout and colors for UI elements in Epilogue:

import { StyleSheet } from "react-native";

export default StyleSheet.create({
  bookTitle: {
    marginTop: 8,
    paddingLeft: 7
  },
  bookAuthor: {
    paddingTop: 4,
    paddingLeft: 7,
    color: "#777777"
  },
  ...
}

To use this style in JSX, I have something like this:

<Text style={styles.bookAuthor}>Neil Gaiman</Text>

To support Dark Mode, I’ve added a special “dark” field to the styles object. This will only have style properties that I want to override from the default light mode. In the case of bookAuthor, there’s no need to change the padding, just the text color:

bookAuthor: {
  paddingTop: 4,
  paddingLeft: 7,
  color: "#777777"
},
dark: {
  bookAuthor: {
    color: "#FFFFFF"
  }
}

Back to the JSX, I check my is_dark variable and then reference a different set of styles. JSX lets me pass an array of styles, so we’ll include both the light mode version (styles.bookAuthor) and then the dark value (styles.dark.bookAuthor) that will override the color:

<Text style={is_dark ? [ styles.bookAuthor, styles.dark.bookAuthor ] : styles.bookAuthor}>Neil Gaiman</Text>

Here are a couple screenshots showing each mode side by side:

The JSX code is admittedly a little clunky. I can see how it could be cleaned up and more readable with other solutions. But the app only has a few screens, so I’m going to run with this for now.

I’ve been programming the Mac for over 25 years, but I’m stumbling through React Native and JavaScript like a newbie. I’ve always found the best way to learn is by doing. Hit some brick walls, dig under them, and then realize later that you built the wall yourself, fighting the frameworks.

One of the benefits of React Native or SwiftUI is a formal way to manage state, letting the frameworks update the UI for you when something changes. I’ve never thought of this as a big advantage, but maybe I’ll warm up to it.

As I work on rewriting Epilogue, I’ve improved the book details screen to include a list of your bookshelves. Tap a bookshelf to add the current book to that bookshelf. A progress spinner will show while Epilogue sends the book data to Micro.blog.

In the world of UIKit, I would probably have a reference to a UIActivityIndicatorView. When I’m ready to send the web request, I’d show and start the progress spinner by calling startAnimating() on it.

In React Native, I have a boolean state that keeps track of whether the progress spinner should be animating, defaulting to false:

const [ progressAnimating, setProgressAnimating ] = useState(false);

Then when the button is pressed, I set the state to true and carry on with the web request:

function addToBookshelf(bookshelf_id) {
  setProgressAnimating(true);

  // send book data to Micro.blog
  // ...
}

In the UI, the JSX references this boolean. The UI will automatically update whenever the value changes. I don’t need to hold a reference to the actual ActivityIndicator object anywhere in my JavaScript code:

<ActivityIndicator size="small" animating={progressAnimating} />

Here’s a 3-second video of how this looks in the app:

Next up: I need to add sign-in back to the app before I can do a beta. I’ll also be working on Dark Mode and the search box.

In the spirit of Brent’s Sync Diary series from 2013-2014, I’m going to blog a little about our decision to move away from UIKit for some of our Micro.blog apps. I’m new to React’s way of thinking about UI, and I barely use SwiftUI either, but it’s just code and I’ve been able to make some progress learning React Native already.

First, to clear up some potential confusion: we are not abandoning iOS! I still love my iPhone, even if I’m very frustrated with how Apple is treating developers. We are embracing Android more fully, and limiting how much time we spend in Apple-only frameworks. Our iOS apps will still be the best we can make them.

Micro.blog for Android is a pretty big project even in beta. Vincent hit the ground running. It’s a little daunting for me to wrap my head around until I’m more comfortable with React Native, so I started somewhere simple: our app Epilogue, which I built a couple months ago for both iOS and Android with HTML, JavaScript, and a sprinkling of native Swift and Kotlin.

Epilogue 1.0 was developed very quickly. While I was happy to ship the app to customers, I wasn’t too happy about the UI. It was a little clunky, and it started to feel more clunky the more I used it regularly for my own book tracking. React Native uses JavaScript but with native views instead of web views, so I was pretty sure a rewrite would fix the problems in the UI.

I started with the placeholder JavaScript you get from running npx react-native init, then added in Epilogue elements like the book list and querying the Micro.blog API. I also integrated react-native-menu/menu to get a native UIMenu-based context menu on iOS, something I couldn’t do before with the HTML-based app.

The toolchain for React Native makes me a little nervous. It uses every package manager you can think of: Node, Yarn, Ruby Gems, CocoaPods… It feels fragile, but there are so many thousands of developers using this framework, I’m also not very worried about it breaking.

Here are a couple of screenshots of the in-progress new version of Epilogue:

It’s already better. The learning curve for me is getting used to how React shares state and React’s JSX markup, a mashup of XML for view layout with bits of JavaScript. I’m sure I’m not doing it quite right, but already I have something that works well as a foundation for Epilogue 1.1.

A few things are happening at once that together are putting some clarity on the direction we should have for Micro.blog development:

• Vincent has been working on the official Android app. It’s in public beta now on Google Play. This app is written in React Native, which uses JavaScript with native system controls.
• Apple is burning through developer trust with the App Store. This is now mainstream opinion, not just a fringe of developers complaining. Apple’s policy in the Netherlands is the latest.
• Frameworks for Apple platforms are fragmented. UIKit vs. SwiftUI vs. Mac Catalyst vs. AppKit. There are compromises with each path.

We are a small team, and maintaining so many different versions of our apps is difficult. On top of that, why invest so much time in Apple-only frameworks when Apple could upend our business with a new App Store tax or other disruptions?

Going forward, the tentative plan is to abandon most of the current iOS codebase for Micro.blog, instead sharing it predominantly with Android using React Native. This will free up development time to keep making the Mac version even more Mac-like, sticking with AppKit.

Mobile platforms like iOS and Android are much more similar to each other than either one is to the Mac. I love the Mac and don’t want to compromise the UI on macOS with a cross-platform framework. macOS also remains the only open Apple platform, so investing in it feels right.

What about our other companion apps for Micro.blog? Sunlit and Wavelength will stay iOS-only using UIKit. Epilogue will move to React Native, simplifying the number of cross-platform frameworks we use to just one.

In summary, here’s how I see our apps looking after this multi-year transition:

• Micro.blog for the web: Ruby. Built for the web, for any platform.
• Micro.blog for iOS: React Native.
• Micro.blog for Android: React Native.
• Micro.blog for macOS: AppKit.
• Sunlit for iOS: UIKit.
• Wavelength for iOS: UIKit.
• Epilogue for iOS: React Native.
• Epilogue for Android: React Native.

The official apps for Micro.blog are a baseline. There should be a rich ecosystem of third-party apps that make other choices, going all-in on SwiftUI, Jetpack Compose, or whatever else helps developers build something new for Micro.blog.

What makes the business side of Micro.blog work is that our goals as a company are aligned with our users’ goals. We make money when we provide features that make blogs better and the Micro.blog community experience better. Restructuring our development approach similarly aligns our priorities, moving just a little farther away from being dominated by Apple.

Micro.blog 2.3 is now available in the App Store, including these changes:

• Added syntax highlighting for HTML when creating or editing posts.
• Fixed compatibility with some Micropub servers.

We’ve supported color highlighting in Markdown for a while, and now this release adds HTML too. I’ve found this most helpful when editing a blog post that includes images, where the img tag was probably added by Micro.blog:

I also fixed a bug with Micropub servers, no longer requiring the me parameter from some IndieAuth API calls. There has been some related housekeeping of the IndieAuth spec recently, and I want to make sure Micro.blog can post to as many non-Micro.blog servers as possible.

After I added Micro Camp 2022 to events.indieweb.org, I wanted to send an IndieWeb RSVP to the event. RSVPs use Microformats and Webmention to let your blog notify another site that you are attending an event. I’ve been creating the markup for RSVPs manually for years, but it’s a little finicky. You need to use HTML with the right reply-to class and RSVP status.

To make this easier, I’ve created a Micro.blog plug-in called IndieRSVP that provides a Hugo shortcode you can use in a blog post. After installing the plug-in from Micro.blog’s plug-in directory, to RSVP to an event use the shortcode rsvp and pass a URL for the event as a parameter like this:

I'm going to this! {{< rsvp href="https://events.indieweb.org/2022/03/micro-camp-2022-IW2Qp3ygHike" >}}

There are more details over in the README. Happy RSVP-ing! 📅

I’m as tired of debating the App Store as anyone. I’ve been making essentially the same arguments for 10 years, on this blog and on the podcast. But the news from South Korea adds a new wrinkle that is worth highlighting.

The spirit of any law forcing Apple to allow external payments for apps is clearly twofold: give developers more control over interacting with customers, and let developers avoid paying the 15% or 30% on transactions by handling payments outside the store. Apple and Google are trying to follow the letter of the law while missing the larger point completely:

Apple said it plans to provide an alternative payment system at a reduced service charge compared with the current 30 percent charge, as the tech giant turned in its compliance plans to the Korea Communications Commission (KCC).

Ignore for the moment whether this response is legal or fair. Let’s think through how this would work in practice. Apple is developing APIs so that when using an external payment, Apple is still notified about the external transaction so they can collect their “reduced” service charge.

But iOS developers are used to paying Apple $99/year, and then getting a check from Apple once a month with 70% of the sales through the App Store. The 30% (or 15%) is taken out automatically, just like 3% is taken out for Stripe transactions. Developers don’t have to think about it.

In this new world Apple imagines, developers will be collecting all of the sales into their own bank account, and then paying Apple the 11% or whatever Apple ends up demanding. There is a huge psychological difference between these approaches, just as there’s a difference between getting taxes taken out of your paycheck automatically and having to write a big check to the government.

If this goes through, it will only underscore how ridiculous the App Store tax is. Why do developers have to pay Apple a platform fee when we’ve never had to do that for macOS? What is the point of the $99/year program?

Apple wants iOS, the App Store, and their App Review team to be inseparable as a single platform. That’s not a technical reality. If they keep pushing this approach, they’ll only run up against more regulation and more distrust from the developer community.

Last June, I was traveling with my family for a vacation to Washington DC. We had all gotten vaccinated, the Delta variant of COVID hadn’t hit the US yet, and we were feeling pretty great about moving beyond the pandemic. Maybe too optimistic, but that’s another story. For Micro.blog, what happened leading up to that trip and while in DC is that I spent some time thinking about the future of the platform and the team.

Maybe it was the stress of travel. I felt a kind of urgent need to get help with Micro.blog, ideally from someone who knew Ruby, had seen some of my code before, and had experience with mobile apps and APIs, so they could hit the ground running. I emailed Vincent Ritter right before leaving town and asked if he was interested.

Vincent had developed the third-party Micro.blog app Gluon, which runs on iOS and Android. He’s an active blogger and codes with Ruby, which we also use on the Micro.blog backend. He and I have discussed several improvements to the Micro.blog API through his work on Gluon, so I was pretty sure we had a similar approach to development and could work well together.

Vincent has been working part-time on various improvements to Micro.blog since shortly after I reached out to him over the summer. Bug fixes, backend architecture brainstorming, and new features like dark mode on the web. But he’s also been working on something big: Micro.blog for Android.

We rolled out the Android version last week as a public beta on Google Play to get early feedback. It won’t match the features of the iOS version exactly, just like the macOS and iOS versions are different from each other in their own way. The Android version has all the basics: the Micro.blog timeline, posting, replies, Discover. The design borrows from the iOS version but also tries some new things, like a tab bar.

Five years since the Kickstarter for Micro.blog, I remain as excited as ever about the potential for Micro.blog. Finally filling in this missing piece for Android users is a huge step forward.

Thinking back to last summer through to this winter, it’s easy to let bad news happening in the world dominate our thinking. I’m really proud that behind the scenes with Micro.blog we keep moving forward. I probably say something like this every January, but… 2022 is going to be great.

Today we’re releasing the first public beta of Micro.blog for Android. You can download it here on Google Play.

Vincent Ritter led the development on this and there’s a ton in it for a first beta. Some of the features in this initial version:

• Timeline, Mentions, Bookmarks, and Discover.
• Creating new posts and replying.
• Uploading photos.
• Viewing conversations.
• Emoji picker in Discover.
• Multiple blogs and multiple Micro.blog accounts.
• Choose categories when posting.
• Viewing profiles and following new users.

We have a few more things to wrap up before we officially call it 1.0. For example, push notifications will make the final release but they aren’t in this beta. There will be bug fixes, UI tweaks, and other improvements based on feedback.

Enjoy! Let us know what you think.

Reacting to Daniel Jalkut’s follow-up on his 2010 post about native apps vs. web apps, Michael Tsai has a great summary of how much Apple has lost the plot. His blog post collects many of the problems in one place:

Since then, Apple has slowed the pace of improvements to the frameworks for writing native Mac apps. It added technical (sandboxing, TCC, SIP, kernel extension restrictions) and policy (App Review) roadblocks that make it harder to develop apps that go beyond what can be done with Web technologies.

I’ve been doing a lot with AppKit this week, updating Micro.blog for Mac. I can’t believe I’m saying this in 2022, but AppKit is still the best way to develop Mac apps. Apple’s framework strategy is so muddled.

If you’re supporting iOS, Android, and macOS, you might choose an Apple framework like Catalyst or SwiftUI to cover iOS and macOS, then something different for Android. But lately I’ve been thinking the best way to support all 3 platforms is to have cross-platform code on mobile, and AppKit on macOS. iOS and Android are a lot more similar than either one is to the Mac.

Today we released an update to the Mac app that adds a preview window. This is handy for longer posts with lots of Markdown or HTML, so you can check what they will look like when published.

I decided to make this a floating window that previews whatever post window happens to be open. You can move it off to the side of your screen and then quickly show or hide it with the keyboard shortcut whenever you need it.

Full changes:

• Added View menu → Preview when writing a blog post. The preview floats over other windows and will show you what the current Markdown or HTML will look like.
• Fixed posts list not updating when saving a new draft.
• Fixed post button for drafts to show that the draft will be published. Use File → Save to keep saving as a draft on Micro.blog.

As always, the download link is on the help site, or choose “Check for Updates” if you’re already running an older version.

A few weeks ago, something in a discussion prompted me to look up the site 43 Things, which I used in 2005 to keep track of big things I wanted to do. The site is long gone, but a lot of it is preserved in the Internet Archive. I took a screenshot of the 10 things I had on my list back then:

The site was peak Web 2.0. Part personal to-do list, part community, part API. Something about the design was fun to use.

Now that it has been 15+ years, I thought I’d revisit my list and see how I’m doing now, with some context from 2005:

1. Finish my degree — I spent a year at UT Austin, but I was more interesting in working at tech companies than attending school. Later I went back to take classes at night. I always thought I’d eventually get my college degree. Seems unlikely at this point.
2. Animate a short film — Might be something I’ll get back to one day. A couple years ago I dug up some drawings and posted them to my blog.
3. Run a half marathon — Still haven’t done this. I’ve run a couple 5Ks.
4. Watch a space shuttle launch — Sadly the space shuttle is gone. There are more rockets than ever, though, so this seems doable.
5. Write a book — I consider this done.
6. Drive across the USA — I’ve driven from Texas to the west coast and to the east coast. Never all the way across. Can’t see this one happening unless I actually live on one of the coasts.
7. Learn Ruby — Done.
8. Work on a political campaign — I’ve volunteered for a few campaigns to call voters and knock on doors. Seems good enough.
9. Read 50 books in 2005 — I’m sure I didn’t ready that many books in 2005, but I could still do this for another year. Last year I read 33 books and this year my goal is 40.
10. Live to see Halley’s Comet return in 2061 — The most difficult thing on this list. I would be 86.

Daniel and I also discussed this list on Core Intuition 402 from 2020.

There has been a lot of activity around Micro.blog plug-ins lately, inspiring me to improve the theme and plug-in system. Under the hood Micro.blog uses Hugo to process blog templates, and we’ve been running an ancient version of Hugo. Having such an old version has held back some plug-in features, so today I started the process of migrating to the latest version of Hugo.

It’s a big jump, from version 0.54 released in 2019, to 0.91 released just a couple weeks ago. Some things are likely to break, so instead of updating everyone’s blog automatically and dealing with the fallout, we’re going to take it slow. The new version of Hugo is opt-in for now, under the Design screen:

Each blog on your account can use a different version, making it convenient to run Hugo 0.91 with a test blog while keeping your main blog as-is.

I don’t recommend updating unless you are working on a theme or plug-in that needs a specific feature from newer versions of Hugo. I’m testing all the built-in themes with the new Hugo and will keep updating them with tweaks until we’re happy that everything is running smoothly.

If you do try Hugo 0.91, I’ve already updated the Default and Marfa plug-ins — as well as some built-in Micro.blog templates — to work with the new version. You can install the latest versions of the plug-ins for those themes to get the latest versions, instead of waiting for Micro.blog to update.

The most common problem I noticed was using .Data.Pages. That’s a quick fix to use .Site.Pages instead so that it’s compatible with both versions.

I’ve also fixed some HTML escaping issues this week. Micro.blog is now smarter about not escaping special characters like “<” and “{{” when inside a code block.

It was way back around IndieWebCamp Austin 2017 that I proposed a new archive format for blogs. These .bar files are essentially ZIP files that contain HTML with Microformats, JSON Feed with original Markdown or HTML, and uploaded photos. The nice thing about this format is that you can unzip them and preview your entire site in any web browser, and it contains all the related photos and other files.

I’ve been working on improving support for Blog Archive in Micro.blog. Version 2.3 of the Mac app can now import .bar files with a nice preview window and progress. It can import into Micro.blog or external Micropub and WordPress blogs.

When the Mac app uploads photos for your blog from the archive, it rewrites img tags in your HTML to use the new URLs, so it’s a good way to migrate a blog with no or minimal cleanup needed afterwards.

Tools that want to process these files can choose between parsing the Microformats or JSON Feed version of the blog. IndieWeb-friendly tools may find it easier to work with Microformats, and new apps can use any JSON parser.

When generating a .bar file, I recommend having plain HTML in index.html with common Microformats like h-feed, h-entry, u-url, dt-published, and e-content. In the JSON Feed, you can use content_text for the source Markdown or HTML if you have it, and then HTML in content_html. Micro.blog will prefer content_text if it’s there.

For an example to test with, check out this file: example.bar. This contains a few posts and screenshots from our Epilogue blog.

I really hope this format catches on. The files can be big, but they give you a single file that you can backup anywhere.

I’ve updated the Mac app with some improvements around drafts and scheduling posts. There’s a new File → “Schedule Post” menu command to tell Micro.blog to publish a post at a date in the future.

This update includes a handful of other fixes and minor changes too. See the help page for the download link and full release notes. Or choose “Check for Updates” in the current app.

We improved the email newsletter subscriptions feature today based on early feedback. There are a couple of bug fixes: not putting imported posts into emails, and a better “from” email address that includes your name.

Styling of HTML emails is now possible with CSS. Under the Design → “Edit CSS” screen, there’s a new checkbox to include the CSS with emails in addition to on your blog:

The email content is wrapped in a microblog_email class, which you can use if you want to target specific parts of an email without affecting the CSS on your blog. For example, when Micro.blog collects posts together in weekly or monthly emails, it adds a link with the post date. If you wanted to change the color of that link:

.microblog_email .microblog_permalink {
    color: orange
}

This could also be used for changing the appearance of block quotes or inline images. I’ll be sprinkling in some more CSS class names in the future so that other components of the email are easy to override.

Today we’re announcing a major new feature for Micro.blog Premium subscribers: email newsletters. Micro.blog can now manage letting readers subscribe to your blog and receive emails for new blog posts. It’s deeply integrated into Micro.blog and works great for collecting multiple microblog posts together automatically.

Why are we creating yet another email newsletter feature when there’s already Substack, Buttondown, HEY World, SendGrid, MailChimp, and others? We always want to make blogging easier and to encourage more people to blog. We think many people want to publish to the web and email, instead of splitting their writing off into a members-only newsletter.

Micro.blog’s email newsletters are like Micro.blog’s cross-posting: designed to start with your blog first and be effortless to maintain. You can enable it and forget about it. Micro.blog will create newsletter drafts from your blog posts automatically. You can edit a newsletter if you want, or ignore it and Micro.blog will queue it to send to your subscribers.

There are a few settings when you enable email subscriptions: have Micro.blog send a new email for every full-length blog post; collect all your blog posts for a week together and send them in a single email; or collect all your blog posts from a category into a monthly email. The weekly and monthly options work great when you have a mix of short and long posts, so your email subscribers can read them together in order.

We think Micro.blog’s email newsletters are a great option for potential readers who are not using RSS. Everyone uses email. You can keep email subscribers in the loop without pulling attention away from your blog. All your content still lives in one place and not fragmented across multiple services.

When you enable email newsletters, Micro.blog also adds a special email address that will be the “from” address for any emails sent for your blog. Your subscribers can reply to your email and Micro.blog will forward the text to you, without having to make your real email address public.

To try out email newsletters, click on Plans to make sure you’re on Micro.blog Premium. This $10 plan also includes podcast hosting, video, and bookmark archiving. You’ll see a new Newsletter link in the sidebar on the web, where you can enable email subscriptions, manage subscribers, and edit email drafts before they’re sent to your readers.

I’ve also posted a video to YouTube showing some more of how it works. Let us know what you think!

This week we improved a few things in Micro.blog for managing drafts and scheduling blog posts to publish at a future date. If you have any drafts or scheduled posts, you’ll see a new set of buttons in the Posts screen on the web to filter your posts:

You can save a post as a draft in the iOS or macOS apps, on the web (click the “…” button), or from apps like Ulysses, iA Writer, and MarsEdit. Some apps can automatically schedule a post just by picking a date in the future. You can now also take any draft post in Micro.blog on the web and schedule it from the editing screen:

As always, Micro.blog is first about quick, easy posting. If you don’t need drafts or scheduling, the UI should stay out of your way. I know how cluttered some other blog systems can get, and we want to keep Micro.blog as streamlined as possible even though it does have advanced features under the hood.

On the latest Core Intuition, Daniel and I talk about the just-released FastScripts 3, his app for quickly running scripts. He mentioned that even though AppleScript hasn’t had any attention in years, it’s still useful as a complement to Shortcuts and other workflows. Daniel said:

It’s like learning a little bit of French when you go to France. You don’t have to do it, but you’re going to have such an easier time if you do. And in my opinion, learning — even now, even in its state of relative neglect — learning a little bit of AppleScript on the Mac is like learning a little bit of French in France. You’re going to get a lot farther with everything you want to do.

Micro.blog doesn’t have AppleScript support, but it does have a URL scheme for starting a new blog post. For example, I wrote the AppleScript below to play around with FastScripts 3. You could trigger it with a keyboard shortcut from FastScripts to start a new blog post using a link for an open Safari tab.

-- we'll need access to AppKit for NSString's URL encoding
use framework "Foundation"
use scripting additions

-- global variables that we'll set later
set the_url to ""
set the_title to ""

-- helper function to URL-encode the text we'll pass to Micro.blog
on urlEncode(input)
	tell current application's NSString to set raw_url to stringWithString_(input)
	set the_encoded_url to raw_url's stringByAddingPercentEscapesUsingEncoding:4 -- 4 is NSUTF8StringEncoding
	return the_encoded_url as Unicode text
end urlEncode

-- ask Safari for the current tab's URL and page title
tell application "Safari"
	set the_url to URL of current tab of window 1
	set the_title to name of current tab of window 1
end tell

-- make a Markdown string like [title](url)
set s to "[" & the_title & "](" & the_url & ")"
set the_mb_url to "microblog://post?text=" & urlEncode(s)

-- start a new post with Micro.blog for Mac
open location the_mb_url

My AppleScript knowledge is very rusty, and it took more than a few web searches to cobble this together, mostly because of the URL encoding. Now that it’s working it could be the basis for other automation with Micro.blog.

We released an update to Micro.blog for macOS today:

• Added View menu → “Go to User” menu command to quickly open someone’s profile by username.
• Added publishing progress pane to top of Timeline after posting.
• Updated row selection in Posts and Pages to be full-width to better match Timeline selection.
• Fixed account toolbar item background color in Dark Mode.

This version includes a fix from @vincode! Neat to see other people look at the code now that it’s open source and contribute changes.

You can grab the latest version in the Micro.blog Help Center or choose “Check for Updates” from the current app.

Epilogue is now available in Google Play. This is the first official app we’ve released for Android! Version 1.0 is very focused — just adding books to your reading list and posting about the book to your blog — but if people like it we’ll add additional features in future versions. I like that it takes a small part of the “bookshelves” in Micro.blog and makes it much quicker to access.

We are not going to compete directly with all the features in the new Goodreads competitors that have sprung up recently. Italic Type, StoryGraph, and Literal have interesting approaches to tracking books and building a community around reading. We’ll integrate with them where we can. Instead, Epilogue is for that last step of connecting to your blog, so that you can share your books at your own domain name where you own the content. To get there, we had to build a little bit of plumbing that is similar to those other book services, but I want Micro.blog and Epilogue to remain as lightweight as possible.

The iOS version is stuck in App Review. You can still get the TestFlight public beta here. We also have a blog just for Epilogue news: epilogue.micro.blog.

Happy reading! If you need inspiration, browse through the covers for books that members of the Micro.blog community are reading in our Discover section for books. Each book cover links to a blog post.

Last week I sent out a survey to ask how people are tracking books they are reading or blogging about. The response was encourage enough that I got to work building a new app for books. It’s called Epilogue.

As I discussed on Core Intuition, we already have a few iOS-only apps, but Micro.blog is before anything else a web-based platform. Vincent is working on an official Android app, and whatever we do next should be available on multiple platforms. So I decided to try something new with Epilogue, designing the UI with HTML to share it across both iOS and Android.

I’m pretty happy with the result. There are a few quirks in the UI — things we can probably smooth over in future versions or if necessary replace with fully-native screens. But I was able to build the whole thing quickly by iterating in Safari on my Mac.

Here are a few screenshots:

Epilogue is now available as a public beta on TestFlight. It will be available on Google Play soon-ish. I have it working, even if Android is still mostly uncharted territory for me. I also feel like I need to get some public feedback before going too much farther down this road.

It’s open source. GitHub says the language breakdown is:

What’s next? This first beta is for people who are already using Micro.blog. It’s for quickly adding a book or blogging about it. The search is new, powered by Google Books. We’ll wrap up 1.0 soon and then consider where to go with the app in future versions.

With a dedicated app, we could add more features than would fit into Micro.blog on the web, but I also don’t want to get too sidetracked. The goal is a lightweight app that can complement other book services, making it easier to blog about books.

I was inspired when I saw news about the Flickr Foundation to take another look at what Flickr has been up to since they were separated from Yahoo. I haven’t used Flickr much in years, but I know it remains popular with some photographers on Micro.blog.

In early versions of Sunlit, we let you browse your Flickr photo library and pick a photo to post to your blog. We removed the feature because the design was kind of backwards. I don’t want to post to Flickr first and then copy to my blog. I want to post photos to my blog first and then send a copy to Flickr, to share with followers on Flickr and to have an extra backup with a company that is committed to preserving web content.

Today we’re rolling out Flickr support in Micro.blog with that vision in mind. It’s enabled under Account → “Edit Feeds & Cross-posting”, just like sending blog posts to Twitter, Medium, Tumblr, and other services. As Micro.blog is processing your feed, when it finds a blog post that contains images, it uploads them to Flickr, including the title (if any) and text of the blog post.

It’s worth pointing out a couple things that this feature does not do:

• No uploading of full-resolution photos or EXIF data. If you want Flickr to have the best version of your photo and all metadata, you should continue to upload original photos to Flickr directly.
• No attempt to collect multi-photo blog posts into Flickr albums. If a blog post has multiple photos, they are uploaded individually with duplicate text.

In other words, if you already have a Flickr workflow that you like, you should probably continue to use it! This is for people who have a Flickr account that has gone unused, but who know there’s value on Flickr if only it was easier to remember to use it. Now there’s a simple way to save photos from your blog to Flickr automatically.

Drummer is a new outliner (with companion blogging system) from Dave Winer. As I’ve watched some folks on Micro.blog play with Drummer, I thought I’d take a look at how we could make it easier to use an outline in Drummer to write new blog posts for Micro.blog.

The result is an experimental feature in Micro.blog that adds support for creating or updating posts automatically from OPML files on the web. Write in Drummer, publish to a blog hosted on Micro.blog. There are a few moving pieces, so the best way to explain how it works is this screencast video I made (also available on YouTube).

I was fascinated to discover that when you look under the surface of Drummer, there’s the start of a Frontier-inspired scripting system too. I’m not sure where OPML support in Micro.blog will go from here, but this was fun to work on, and there may be more we can do with other outliners in the future.

Maurice Parker has a blog post exploring the differences between Drummer and his outliner Zavala. Over the years, outliners have gotten more feature-rich but also complicated. There seems to be a lot of potential for more lightweight outliners like Drummer and Zavala that can potentially talk to each other and to the web.

Yesterday was a whirlwind for me, taking care of personal stuff unrelated to Micro.blog, and I don’t think I really appreciated the 6-hour Facebook downtime until last night, sitting down to watch CNN. Mistakes happen, and I’m sympathetic to Facebook engineers who had to scramble, but this is the cost if you want your platform to have 3 billion users and essentially be the web for so many people.

Facebook is (obviously) too big. Their week is about to get worse, with whistleblower Frances Haugen testifying in Congress today. It feels like the culmination of years of reputation-destroying bad PR on privacy and misinformation.

In 2018 I blogged that breaking up Facebook is up to us. Facebook’s business is more fragile than I even realized. Their problems are baked into the product design, maybe unfixable at this extreme scale.

Yesterday the world got a glimpse of what 6 hours without Facebook and Instagram looks like. It was disruptive for many businesses and many friends just trying to connect… but it was also fine. More like this, please.

This is supposedly the first mural still standing in Austin, Creation painted on the University Baptist Church in 1950. Seems a fitting way to wrap up this series of 30 murals. The artist, Seymour Fogel, also studied under Diego Rivera.

A few of the murals I had hoped to visit have since been painted over. Murals are inherently fleeting. Even the best murals are always at risk of graffiti or new construction. Artists know this, but they put their mark on the city anyway, a gift for us to admire and capture in photos before everything changes.

This might seem like a distraction or procrastination technique, but bear with me here. @patrickrhone’s talk at Micro Camp must’ve been sitting in the back of my mind because I realized I should collect my 30 day series — coffee shops, libraries, parks, and murals — into a book. I’m using it as a trial run for the print layout for Indie Microblogging, experimenting with the size, fonts, footnotes, etc.

After I finish the final week of murals, I’ll send a copy off to IngramSpark for printing. I’m actively editing Indie Microblogging and feel good about wrapping it up this year. If everything turns out well with 30 Days, maybe I’ll include the book as a bonus for Kickstarter backers at higher tiers too. We’ll see.

Sunlit 3.4 is now available in the App Store. For this update, we focused on improving the timeline experience, cleaning it up so that it better focuses on photos and viewing conversations. There are a bunch of little changes that together make the app feel much more responsive and easier to use:

• Streamlined the timeline user experience, with single tap to view conversations and moved some buttons to secondary screens.
• Improved performance and added placeholder blurred backgrounds while photos load.
• Fixed bugs, updated toolbar with translucency, and other design tweaks.

The blurred photo placeholders are done with BlurHash. Whenever you post a photo, Micro.blog calculates the BlurHash for it and includes that value in the /posts/media JSON Feed so apps like Sunlit can use it.

Remember that the Micro.blog iOS app also supports sharing photos from Glass, and those photos will show up in Sunlit. I’ve been using Glass in addition to posting to my own blog for my murals photoblog series this month, and some of these improvements in Sunlit 3.4 are partially inspired by the UI polish in Glass. This is the best version of Sunlit yet.

We updated the Micro.blog app for macOS today with the following changes:

• Fixed file export issue that would cause blog export with many photos to get increasingly slower, sometimes crashing.
• Fixed notification bar color for new messages to better fit in Dark Mode.
• Fixed uploading animated GIFs in new posts.

Choose “Check for Updates” to grab the latest version.

We’re also hearing feedback about the new Dark Mode support for the web version of Micro.blog. I’m excited that we rolled this out and we’ll continue to update it as-needed. I don’t usually run Dark Mode on my Mac, but I’m living with it this week so I can better test everything.

We’ve finished a server upgrade for Micro.blog-hosted blogs. It’s now backed by the Caddy web server and includes a few other improvements. The big changes for Micro.blog are:

• Automatic HTTPS. If you used custom domains on Micro.blog before, you noticed there was a delay between setting up your domain and HTTPS getting enabled. That delay is gone now.
• Hostname redirects. Micro.blog now always redirects to the primary version of your custom domain. As an example, my domain under the Design page is set to “www.manton.org”, so “manton.micro.blog” and “manton.org” will redirect there.
• Faster publishing. Because of some of these changes, we cut down on the work Micro.blog does behind the scenes, making it faster to go from clicking “Post” to having the web page live on your blog.
• Scaling. We can now more easily copy your hosted blog across multiple servers. This will minimize downtime and help performance as we grow.

If you are hosting on Micro.blog, you don’t need to do anything. All blogs have been upgraded with these improvements.

If you notice any problems, please let us know. We’ve been rolling this out slowly over the last few days to avoid rate-limiting with new HTTPS certificates. If you are using Cloudflare in front of Micro.blog, you will need to disable Cloudflare’s request proxying so that Micro.blog can finish setting up the secure version of your site.

I’m always paying attention to new platforms that pop up, especially when there is some overlap with Micro.blog. The iOS-only photo sharing app Glass launched last week as an interesting alternative to larger social networks. Today I’m announcing a new version of Micro.blog with special support for Glass.

Glass has no public API or web version, but it does have a way to share a simple web page of your photo. We’ve leveraged this so that you can take one of your Glass photos and send a copy directly to your own blog.

Here’s a quick screencast video showing this feature in action:

This might look normal enough, but because Glass shares a web page URL instead of the photo, if you use any other app you’re just going to get a link. Micro.blog downloads the HTML, parses it looking for the photo URL and caption, then moves that into a Micro.blog post. The new photo is hosted on your blog, with your own domain name if you have one.

Glass is so new that it remains to be seen where the app will go, and how it might expand in the future. It shares some of the same principles as Micro.blog — no ads, no algorithms, no likes — but Glass lacks important open web features like domain names and IndieWeb APIs.

I’ll always prefer posting photos to my own blog instead of a silo. We do need more social networks, though, and any attention that can be pried away from Facebook and Instagram is a win. Best of luck to the Glass folks.

To pair with my post about downtime, I thought I’d share our current Linode servers. Some people ask us about this kind of thing, and I know I love reading about how other platforms are set up.

My server naming theme for Micro.blog is the Disneyland Railroad. Servers are named after locomotives, people who inspired them, or theme parks. Fort Wilderness in Orlando, which used to have a train back in the 1970s, is the server that failed last night and is still offline.

The only server that doesn’t get a name is Discourse, because I don’t really enjoy hosting it and hope to shuffle it off somewhere else eventually. We also use Linode’s load balancers, object storage, and Amazon S3.

Thanks to everyone who has a Micro.blog paid subscription. Your support allows us to add new servers when we run into problems and make everything more stable and fast in the future.

Yesterday’s outage was the worst downtime we’ve ever had for Micro.blog-hosted blogs. I designed the architecture to separate the main platform from hosted blogs, so that all the complex moving pieces of the platform — databases, the API, multiple servers — couldn’t affect performance of your own blog. This has worked out so well over the years that it has made me lax about planning how to recover quickly from worst-case scenarios.

So what happened? We noticed some performance issues and glitches, with unusually high CPU usage. On reboot, the disk check failed, and I was unable to repair it. To make matters worse, I could not recover from the latest backup because Linode’s backup service was also down for unscheduled maintenance.

As I wrote in more detail a few months ago, we store important files like photos in multiple places so that if disaster strikes we can still rebuild your blog. With the backups down, I set out to do that kind of rebuild, but I had never done it on quite that scale before. One problem I had overlooked is how long it would take to update HTTPS certificates for custom domain names.

After a few false starts, I scrapped that restoration work when Linode’s backups came online, and was able to more quickly get everything back up and running. I learned a lot, and Vincent and I will be talking through some next steps to make this more robust. I never want to go through an extended outage like this again. I’m very sorry it happened and I’m thankful for everyone’s patience.

I’ll be keeping an eye out for any lingering problems. Please reach out to help@micro.blog if you notice anything that looks wrong.

Micro.blog for iPhone and iPad has been updated today with a handful of bug fixes:

• Fixed erratic scrolling when typing long blog posts.
• Fixed post context menu appearing offscreen for posts with many photos.
• Fixed not loading your latest profile photo.
• Fixed profile photo moving after user screen loads.

Happy blogging! You can grab it in the App Store.

Vincent Ritter is the developer behind the excellent Gluon, a Micro.blog app for iOS and Android. He has been a long-time member of the community and helped push the Micro.blog API forward. As we look to all the things we want to do this year, I’m excited to announce that Vincent has agreed to join us as a part-time contractor to help me on the Micro.blog backend code.

This complements our announcement that all the iOS and macOS apps have been open-sourced. Having another set of eyes on the larger web platform behind Micro.blog will help us scale it as we grow the community, and Vincent’s experience developing third-party apps will make sure we don’t overlook improvements to the API that can benefit all apps.

But wait, is this like when Twitter acquired the third-party iOS app Tweetie, making it the foundation for Twitter’s own native app? Are we taking over development of Gluon? Nope. Vincent may help with the official apps in the future, but Gluon will continue as an independent project with the same access to the API as any other app.

It’s an important part of Micro.blog that there is an open API and a diverse set of third-party apps. Our business is simple — no ads, just pay for blog hosting if you want to — so we don’t need the official app to solve every problem or discourage third-party apps. Where we need help is improving the foundation of Micro.blog, the web interface, and expanding the API to make all apps better.

Vincent will also be joining us on a panel at Micro Camp — along with Daniel Jalkut and Sam Grover — to talk about developing for Micro.blog.

Thanks Vincent for your support of Micro.blog and for jumping into the server codebase!

Version 2.1 of Micro.blog for the Mac is now available. This release includes the following changes:

• Added emoji topics pop-up menu to Discover. See screenshot here.
• Added export menu for WordPress, Blog Archive Format, Markdown folder, and Day One.
• Fixed posting window to disable smart quotes.

And don’t forget, the app is also open source. We’ll be talking more about development with the Micro.blog API at Micro Camp next month.

Usually I work on features in short sprints and ship them out to everyone as soon as they are ready. Days or weeks, not months, unless it is a major overhaul that touches all pieces of the platform. For Micro.blog 2.1 for macOS, I set out to add some export options directly to the app, and it has proven to be a bit of a slippery slope… If there’s Markdown export and Day One, might as well add Blog Archive Format and WordPress too. And if there’s export, what about import?

But importing and exporting are already part of Micro.blog on the web. We support importing from WordPress, Medium, Tumblr, Ghost, Markdown, and others. It doesn’t make sense to recreate all of those in the native app, unless there’s an advantage to running locally like for our Instagram import on macOS.

This is all a long way of saying, I’m keeping 2.1 in beta while I continue to work on this and test it. Your milage may vary, make sure you have backups, etc. You can download the latest beta here.

I’ve been thinking a lot lately about the longevity of Micro.blog and where we need help to continue to grow the platform and community. As we approach 4 years since the public launch, there are some parts of the platform and supporting services that should be shared more widely, so that I’m not the bottleneck on every little change.

As a next step, all the native apps for iOS and macOS are now open source, available on GitHub:

• microdotblog/microblog-ios
• microdotblog/microblog-mac
• microdotblog/sunlit
• microdotblog/wavelength

Note that the projects started as private repositories without the intention of lots of people seeing them, so the usual disclaimers apply: the project structure might be confusing, the code a little messy, and maybe not everything will work perfectly without some tinkering.

I’ll have more to write later about how we want to grow Micro.blog this year. In the meantime, enjoy the code! MIT license, so there’s plenty of flexibility to use it however you’d like.

Since launching the bookshelves feature in Micro.blog on the web, I’ve been wondering whether we should build a native interface for this in the Micro.blog app. My answer: no. Books are so unique that it feels like they need a dedicated app, just like there is a native app for Goodreads on iOS and Android. Native apps could make it easy to quickly mark a book as “finished reading”, or provide fun features like barcode scanning from the phone camera.

You can make a pretty strong case that we already have too many official iOS apps: Micro.blog, Sunlit, and Wavelength. Books seems like a great third-party opportunity instead.

I’ve documented the bookshelves API in the Help Center. It can do most of what Micro.blog on the web does, with the notable exception of book search. If you are building a books app, you’ll need to “bring your own” book search from Open Library, ISBNdb, Google Books, Amazon, or wherever.

A theoretical app built on Micro.blog could let the user sign in with their Micro.blog account using IndieAuth. Then the app could get the user’s bookshelves, add new books, or post to their blog with a link to the book.

Like most of Micro.blog, the API is based on JSON Feed. Lists of bookshelves and books are just JSON Feed with a little bit of extra data like isbn in a namespace field. When Micro.blog has the book cover, it’s included in image.

There have been some interesting experiments with custom JSON formats or even based on OPML, but as I was reviewing these it seemed like an unusual departure for Micro.blog to not use JSON Feed. We can consider adding additional formats later.

I’m happy to support whoever wants to tackle this. Jon Hays suggested a hackathon for people to get together and tinker with the API, or build an app together. What do y’all think?

In addition to the Micro.blog API, another area where we could experiment is an app that connects bookshelf data from independent web sites. For Micro.blog-hosted blogs, the bookshelves are available via Hugo templates, so it’s possible to generate HTML pages that include Microformats. See the IndieWeb wiki for some prior art about this.

The experiment to manage the books you’re reading in Micro.blog has been really well received. We’ve heard some great feedback about how to improve this feature and what its final form should look like when it’s rolled out to everyone.

I’ve made a few improvements recently, including making it easier to try. If you want to enable the “Bookshelves” link in your Micro.blog sidebar, just click on this link when you’re signed in to Micro.blog on the web.

The books list is now sorted with most recently-added books at the top. The data is also now available to Hugo themes. In any template, you can use some Hugo code like this to access the books in a bookshelf such as “Currently reading”:

{{ range .Site.Data.bookshelves.currentlyreading }}
   <a href="https://micro.blog/books/{{ .isbn }}">
     {{ .title }} by {{ .author }}
   </a>
{{ end }}

Thanks to Jason Becker for suggesting this. I had never used Hugo data templates before and there is a lot we could do with them. (And you can still edit a bookshelf to include it on any page without making theme changes.)

Some of the feedback I’ve been thinking about is whether “books” isn’t general enough for this feature. Daniel made this pitch on our podcast, and others have suggested music, movies, podcasts, or even beer as other things that could be tracked in “shelves”. These would all be fun to work on and useful, but they would make a fairly simple feature many times more complicated and take months of additional development time. I don’t think we could tackle that kind of scope expansion without distracting from our core priorities with Micro.blog.

For 2021, the plan is to stick with books. We’ll continue to tweak it and then enable it for everyone by default in a few weeks.

After the Webmention session last weekend, I was inspired to revisit a quirk of Micro.blog’s Webmention implementation. Bridgy is an IndieWeb-friendly service commonly used to forward tweet replies via Webmention. If you were using Bridgy to connect your blog to Twitter, Micro.blog had been essentially ignoring any tweet replies to your blog post. Unlike Micro.blog’s support for Mastodon and blogs, there was no way to represent a Twitter user in Micro.blog, and so it didn’t make sense to thread tweets into a Micro.blog conversation.

Including tweets in Micro.blog would have other ripple effects that I wanted to avoid. For example, what happens if you reply to a tweet? I’m not interested in turning Micro.blog into a Twitter client. Quite the opposite. I’m actively trying to distance myself from Twitter and avoid dependencies on any big social networks unless they are based on open standards.

Back to Webmention. I think I’ve found a good compromise solution for compatibility with Bridgy, bringing Micro.blog’s Webmention support more in line with what Webmention.io can provide.

When Micro.blog receives a Webmention for a tweet via Bridgy, it now does create a special reference for that Twitter user and stores the tweet text. The tweet still does not appear anywhere on Micro.blog. The tweet is available as part of the conversation on your blog, though. If you don’t have replies enabled on your blog, you can learn more in the Help Center about using Conversation.js.

This is all a long way of saying: when you post a link to your blog post on Twitter, tweet replies will be collected and included under your blog post on the web.

There’s an additional gotcha you should know about using Bridgy and Micro.blog together. Bridgy needs a link to your blog post for it to be able to match up tweet replies to that blog post. When cross-posting to Twitter from Micro.blog, Micro.blog only includes a link back to your blog if your blog post has a title, or if it needs to be truncated to fit in the tweet.

If you want all cross-posted tweets to link back to the microblog post, even if they were short, you can use Bridgy itself for the cross-posting instead of Micro.blog, and disable cross-posting in Micro.blog. I’m not planning any changes to Micro.blog’s cross-posting in the near term.

This weekend there will be an IndieWeb discussion session about Webmention. Micro.blog has support for both sending and receiving Webmentions, with some twists, so I thought I’d make a quick video to demo how it works with external blogs. This is a big part of making sure Micro.blog is a good participant in the larger web.

I glossed over a few details in the video. One thing I should have mentioned is that WordPress doesn’t have this functionality by default. It requires installing the IndieWeb suite of plugins for Micropub and Webmention.

I’ve been experimenting with another new feature for books in Micro.blog. Bookshelves are like a little slice of Goodreads, but without some of the social features and complexity. Bookshelves in Micro.blog are focused on keeping track of books you are reading to make it easier to blog about them.

Here’s a screencast video of how it currently works:

Next steps might include showing a “Currently reading” page on your blog, and pulling any existing “Finished reading” blog posts into a bookshelf to get started. I think there’s a lot of potential, but I also don’t want to clutter Micro.blog for people who don’t need this. Looking forward to your feedback before we ship it.

We updated our iOS companion app Wavelength today. The new version adds Dark Mode support, now uses the system font, and takes care of some other housekeeping after going so long without an update.

We are also open-sourcing the app! It is available here on GitHub. Just like our other app Sunlit, this was developed with Jon Hays and as we wanted to open source more pieces of Micro.blog, Wavelength felt like a perfect next step.

To celebrate the launch of version 1.1, we’re enabling podcast hosting for all paid Micro.blog accounts for the next 2 weeks. You can publish a podcast episode to your blog via Wavelength, or upload an MP3 directly on the web. We take care of generating a podcast feed and all the other details. If you want to continue with podcast hosting after that, it’s included in Micro.blog Premium for $10/month.

Download Wavelength from the App Store, or learn more in the Help Center.

I’ve been upgrading servers and improving performance in Micro.blog lately, a theme which will continue throughout the year to make everything as stable as possible. Sometimes this introduces new bugs or weird behavior that makes people scratch their heads. What is Micro.blog even doing? So let’s look a little at the architecture.

When you write a new post, Micro.blog saves it into a MySQL database. We currently run 2 database servers, so that we can spread some queries between them and to make backups easier. But unlike many web apps, we do not serve blogs from this database. Blogs are published to a separate server as static HTML and images, served directly by Nginx with few or no dependencies on the rest of Micro.blog. This makes your blog very fast, and means that major parts of Micro.blog can go down without affecting your blog.

This has been a key design goal from the very beginning of Micro.blog. We host a blog for you, but it can have its own domain name and is only loosely tied to the rest of Micro.blog. This goal meant discarding some common architectures such as dynamically generating the blog when pages are requested.

Micro.blog is really 3 separate systems combined into a single platform: a blog admin interface, a blog hosting service, and a Twitter-like timeline.

To achieve this, Micro.blog has to translate the blog posts from Markdown to HTML. It runs all the text through Hugo. It also has to put photos and podcasts in the right place. When you upload a file, Micro.blog copies it to an object storage server at the same time that it syncs the file to your blog.

Timeline web requests and background tasks are run across a few servers, so that we can balance load and deal with outages. While Hugo wants all your Markdown and photos in a specific structure in the file system, Micro.blog maintains content in separate databases and then writes it out to the format that Hugo wants for processing.

Any given server could have part of your content or none of it yet, so Micro.blog will have to sync everything up. It does this in multiple phases to make publishing as fast as possible, and this is the area that I’ve been spending a lot of time tweaking.

First, Micro.blog attempts to quickly publish your latest post, so that it’s available at the permalink URL and included in the blog feed. If you have thousands of posts, it ignores most of them during this phase. It just wants to get your post up on the web as quickly as possible and added to the Micro.blog timeline.

Whenever Micro.blog is processing posts, it also applies any custom themes for your blog. It never skips the Hugo step, even if your blog post content is so simple that it could be previewed with a separate Markdown filter. Every post is run through Hugo, added to the RSS or JSON Feed, and only then processed into the Micro.blog timeline.

This round-trip journey your content takes is an important part of how Micro.blog works with external blog feeds like WordPress. We aren’t interested in building a proprietary social network that is not rooted in blogs. The timeline works with blogs no matter where they are hosted.

Next, Micro.blog will do a full publish of your blog, with the entire site, categories, photo pages, and archive. In some cases, it will combine the Markdown with any uploaded photos before processing them, but usually the uploads are already on your blog. It also keeps a copy of all the Markdown files, independent on any of the web servers, so that if possible it can update those versions without writing out potentially thousands of posts to the file system.

This phase of publishing is the longest, although it’s faster now than it has ever been. During this phase, your latest post should already be live and the timeline updated, so it’s not as annoying to wait around for the archive or category pages to update.

I’m exposing more of what Micro.blog is doing behind the scenes in the logs for your account. Here’s a snippet from my log recently, although I’ve flipped it so that it reads in chronology order instead of newest at top:

2021-04-11 16:54:25: Publish: Not queued, publishing manton
2021-04-11 16:54:25: Publish: Initial prepare for manton
2021-04-11 16:54:25: Publish: Preparing pages for manton
2021-04-11 16:54:25: Publish: Persistent folder exists, updating for manton
2021-04-11 16:54:25: Publish: Initial posts for manton
2021-04-11 16:54:26: Publish: Linking shared content files for manton
2021-04-11 16:54:26: Publish: Running Hugo for manton
2021-04-11 16:54:26: Publish: Initial Hugo run for manton
2021-04-11 16:54:26: Publish: Initial sync for manton
2021-04-11 16:54:26: Publish: Pinging manton, progress: 0.866 seconds

Here, there are actually 2 overlapping background tasks. The lines with “Initial” (italicized above) are part of this first phase of quickly publishing your post. In this case, the round-trip from saving the content, publishing the feed, and then updating the timeline was about 1 second. Under a few seconds is kind of the gold standard we’re aiming for.

Finally, Micro.blog assembles the timeline so that it can be served quickly no matter how many people you are following. We have a Redis server that keeps the timeline for each user in a sorted set, and use that from the Micro.blog API to page between posts. Micro.blog also processes posts for @-mentions, sending Webmentions, auto-linking URLs, and other details that are beyond what I wanted to write about here.

Could this be even better? Yes. But while I’m sometimes tempted to change the architecture to something closer to WordPress’s model, I know there’s always more performance we can squeeze out of our current setup.

Micro.blog sends Webmentions to external blogs when you “reply” to a post inside Micro.blog. It marks up your reply with Microformats, discovers the Webmention endpoint for the post you’re replying to, and sends the Webmention. This allows your Micro.blog replies to be included as comments on blogs hosted by other platforms, like WordPress.

An RSVP is a special type of reply used to indicate whether you’re attending an event. By posting RSVPs to your own blog, you can attach them to existing posts or just have your own copy of the data. As more bloggers use RSVPs, we could eventually have a more distributed, IndieWeb-friendly system instead of relying on Facebook or Evite.

How to create an RSVP on Micro.blog? We don’t currently have an RSVP button in Micro.blog, because Webmention-enabled events are still rare enough that it would take up a lot of the Micro.blog UI, potentially cluttering the interface.

You’ll need a little bit of HTML to create an RSVP. First, add a link to where you want to send the Webmention. Instead of using Markdown for the link, use HTML and add the Microformats class="u-in-reply-to" to mark the link as a reply to another URL:

Looking forward to this <a href="..." class="u-in-reply-to">Webmentions pop-up session</a> next month.

Then, to make this an RSVP, add a data tag somewhere in the post with “yes”, “maybe”, or “no”:

<data class="p-rsvp" value="yes" />

I like to use data because it’s invisible when displayed in a web browser, but it could be a span or other HTML tag. You can see a full example of this if you view the HTML source of my post here, RSVP-ing to an IndieWeb online event.

When you publish the post, Micro.blog will automatically notice the u-in-reply-to, find the Webmention endpoint for the post you’re linking to, and send the Webmention for you. Micro.blog themes also handle the other details, like including your name and profile photo.

I rolled out several improvements to Micro.blog today. I’ve been working on a long-term plan to significantly improve publishing performance for blog posts, and the first part of that is live now. It may not be immediately noticeably but it will start to make a difference for some parts of the publishing workflow behind the scenes. (And in the best case, some things will already be faster.)

I also finished better support for redirecting URLs in hosted blogs. This cleans up some clunkiness in the old implementation:

• When you create a page where the text content is just a plain URL, Micro.blog will better redirect to that URL without loading any of the design layout for your blog. This eliminates the flicker or partial page load you could see previously in some themes.
• There is now a separate “New Redirect” button under Pages on the web. This lets you set up extra redirects, for example old URLs when migrating from a previous blog platform. These redirects are only checked when a page does not already exist on your blog.

Note that when using the import feature of Micro.blog — from WordPress, Ghost, Medium, or Tumblr — Micro.blog tries to automatically create redirects to preserve your old URLs. It also redirects common RSS feed URLs. It does not list these special redirects on the Pages screen.

Thanks everyone for using Micro.blog! We’ve seen a lot of new interest this week with the release of Ulysses. More improvements on the way.

The latest version of Ulysses is out today with Micro.blog support! We are very excited to see this ship. I use Ulysses for my notes, blog post drafts, and even writing for my upcoming book, so the integration to publish directly to Micro.blog is perfect, skipping the need to copy/paste or export text between apps.

Here’s how to get started. I’m using the Mac version, but this works on iOS too. Ulysses supports publishing to a few blog systems, and you’ll configure them in the Preferences window on the Mac. First click the “+” button under Accounts.

You’ll be prompted to enter an “app token” for your Micro.blog account. This is like an app-specific password that lets Ulysses sign in to your Micro.blog account and publish to your blog. You can generate a new token for Ulysses in Micro.blog on the web under Account → “App tokens”. The “Micro.blog account” link in the Ulysses window will also take you right there.

If you have multiple hosted blogs in Micro.blog, Ulysses will prompt for which blog you’d like to post to. Micro.blog supports multiple blogs so you can have an extra blog for a podcast, or photo blog at a different domain name, or just a test blog to try out theme changes without affecting your main site.

When you’re ready to publish a blog post, click the share icon in the upper-right corner of Ulysses and select Publishing. Ulysses will preview the post and then when you click Publish, it will prompt for setting a title, categories, and whether to save the post to Micro.blog as a draft or make it live on your site.

To learn more about everything included in the new version of Ulysses, check out the Ulysses blog post. It’s available through the App Store and includes a free trial.

I wanted the original help site for Micro.blog to be a blog, hosted on GitHub, because it would be easy for me to post new articles, and anyone could see the version history of an article, or contribute their own changes. And some people did! I want to especially thank @paulrobertlloyd for redesigning the help site a couple years ago.

But now that we’ve had some time since winding down our Slack community, it has become clear that even with the potential for extra blogs about Micro.blog like custom.micro.blog, which is a great resource, we needed a place that people could ask questions and get help from the community. The idea is to use the web forums software Discourse and combine it with all the content from our original help site.

Today the new help.micro.blog is live. My favorite part: it will use your Micro.blog account. Just click Login and you’ll be automatically signed in. No new account to manage just to post to Discourse. Hope you like it!

First, there is no right way! Just type something about what you’ve read or want to read, hit post, and you’re good. However, we have built a few book-specific features in to Micro.blog that aren’t obvious on first glance.

My favorite is the book search. Enter an ISBN-13 or a book title and author, and Micro.blog will return a list of books it finds using Open Library and ISBNdb. From there, you can click to automatically draft a post with the book title, link, and author. You can then add some commentary or just publish it as-is.

Blog posts that contain the books emoji 📚 will get collected in our Discover → Books collection. If the post includes a link to Micro.blog with the ISBN (micro.blog/books/isbn-here, added for you by the book search), then Micro.blog will also show the blog post on our book covers grid, which is another fun way to discover what people on Micro.blog are reading.

A nice bonus with including 📚 in your posts is that it’s easy to tell Micro.blog to add all your book-related posts to a category on your blog. Click on Categories → Edit Filters and make a filter that assigns the Books category whenever a post contains that emoji.

Micro.blog also supports indiebookclub. It uses the Micropub API to publish blog posts, and Micro.blog will format them so they are also included in the book covers and Discover collection.

Personally, I’ve been reading a lot the last few months. I’ve also started to use Goodreads more, in addition to blogging about books I finish on my own site, to better understand what additional features we could build around books for Micro.blog.

Jean and I were talking this week about how it’s been 1 year since IndieWebCamp Austin. That was the 3rd IndieWebCamp here, and after it wrapped up we were already talking about plans for 2021, excited to look at potential new spaces for the conference in Austin.

Little did we know last year that IndieWebCamp Austin would be the last in-person IndieWeb event all year, for any city, with everything else cancelled or moved online because of COVID. If the Austin event had been even a couple weeks later, we probably would have cancelled it too, as the scope of COVID was just starting to be understood.

Now a year later, a tragic 500,000 dead in the United States, vaccines are rolling out, and we are starting to see the light at the end of the tunnel. I think 2021 is going to be largely the same as 2020 in terms of events. WWDC will no doubt be online again too. But I can start to imagine that some in-person events and meetups will come back next year, although surely reimagined around safety. In the meantime there have been a number of online IndieWeb events, both informal meetups and pop-up sessions around specific topics, like improving APIs.

We are also thinking about what a Micro.blog-focused online conference might look like. It has been wonderful to watch the community grow, and there’s so much we could do this year.

Election Day is today. I hope that it will be a turning point for the country, so it seems like a good time to also look back.

I try to write every day, whether it’s here on this blog or in my journal using Day One. Posts about family or personal stories usually stay private, because there are plenty of other topics to write about here. Today I want to collect together a few things that have happened this year, events that I might jot down in my journal but which haven’t made it into the blog.

Back in March, when the kids were home for spring break and the seriousness of the coronavirus was just starting to become real, we wrote down some rules on giant sticky notes and stuck them on the fridge. Like the rest of the country, we were trying to figure out what to do, and it helped get everyone mostly on the same page.

There was still a lot of confusion about what was safe. Texas was about to go into lockdown. The NBA was about to postpone games. SXSW was about to be cancelled. It felt like everything was just on the verge of changing. I thought if we could only stay safe for a few weeks, we’d make sure that our family didn’t get sick when hospitals would be overrun.

We made masks. I didn’t do much of the sewing, but our home-made masks turned out great. It was fun to do something a little creative, especially early on.

We ordered more masks later, including my new go-to mask with a Mickey Mouse pattern. We fell into a routine of ordering groceries online. I rarely went inside stores. I wore my mask whenever I was picking up take-out dinner or running other errands. I washed my hands all the time. The few weeks of quarantine had turned into months of isolation.

Later in June we went to the beach for a couple days, to get away. I was worried, because the Houston and Galveston area were getting hit hard by COVID, but we were barely 30 feet from anyone else. It felt great to be near the water, eat outside on the deck with a cool breeze, and escape the normal stress of the quarantine. We had a house on Airbnb to ourselves, cooked most of our meals there, and I picked up pizza one night in town.

A few days later we were up in Dallas. That weekend I wasn’t feeling great. I figured it was a cold or allergies. No fever, no shortness of breath. Because I had been with family, out of caution I decided to get tested for COVID-19. I talked to a nurse for advice and also called a nearby drive-thru clinic that did testing.

While waiting in line to get tested, I convinced myself that I had overreacted. I was wasting everyone’s time, while people with much more serious symptoms needed help. But I got tested anyway, felt better the next day, and went on with my work week, releasing a major upgrade to Micro.blog to support plug-ins that week.

A doctor called me with the results about 4 days after I had gotten tested. It was positive.

My symptoms were extremely mild. I’m still not sure the test wasn’t a fluke. I had planned to follow up with an antibody test to confirm it, but I never did. Even so, going through that process of getting tested had highlighted for me what Texas and other states were going through back in June and July, and now again as winter looms.

This year has been long, and disappointing, but there was hope. We flattened the curve. We were well on our way to putting the coronavirus behind us and looking toward school restarting. But we opened too quickly without the right guidance. We lost control of the virus. We were almost there, and we blew it.

Fast forward several months when I’m writing this. We flattened the curve a little, again, only to see the progress slip away. The setbacks have been frustrating, watching so many people flout the guidelines. 2020 could have gone much differently — much better — but there were good moments too, with family and work, watching the Micro.blog community grow.

We can’t get 2020 back. There’s a lot to catch up on. Let’s make 2021 count.

We’ve released an update to our photo app Sunlit with the following changes:

• Added Bookmarks tab and star icon in timeline to bookmark a photo.
• Added share sheet for starting a new post from other apps.
• Added option for new posts to choose photos already uploaded to your blog.
• Improved signing in to look for existing sign-in info if Micro.blog app is also installed.
• Improved entering accessibility alt text to show multiple lines.
• Improved performance when uploading multiple photos.
• Fixed keeping in-progress reply text when switching to another app.
• Fixed potential crash when uploading photos.
• Fixed publishing errors when upgrading from an old version without re-selecting blog.

Download it in the App Store. Next up on the to-do list: an iOS widget extension. Jon has been testing it and it will show up in the TestFlight beta soon.

We just posted Core Intuition 441. From the show notes:

Daniel checks in with Manton, who is making an effort to take some time off from working so hard. They veer into a discussion weighing the merits of fixing little nitpicky bugs vs. adding meaningful features. They discuss the debate sparked by Sketch about native desktop apps vs. web apps, and Daniel concedes some of the advantages of web development.

Thanks for listening to the show. If you’d like to support the podcast with a subscription, check out our membership page.

I’ve written a few blog posts to preview some features in Micro.blog, but until 2.0 launched today we didn’t really have everything in one place. Here are a bunch of the new features:

• Bookmark archiving for Micro.blog Premium. When you bookmark a microblog post (or bookmark any URL on the web), Micro.blog will download the web page and save a copy of the text and images. This also makes the web page searchable.
• Highlighting. Bookmarked web pages get a special reading interface. Make highlights in the text and use those highlights as quotes in future blog posts. See this video for a tour.
• Multiple account support on iOS. Tap your profile icon in the menu to add a new account or switch between accounts.
• Manage uploads. On iOS, upload photos, podcasts, or any file to your blog. On macOS, you can also drag files in to upload them. Uploaded files get a Copy HTML button to paste an img, audio, video, or link tag for the upload into a blog post.
• Redesigned web interface with new sidebar. It is now much easier to access your blog settings and edit posts.
• Share extension to add a bookmark on iOS. There’s also a bookmarklet to use in your web browser.
• Improved character counter on the web. When writing a new post, it now takes into account the text length after processing Markdown.
• Editing replies. You’ve been able to edit your own blog posts for a while. Now you can also edit replies to other people. Great for fixing typos.
• Separate window for new posts on macOS. The app looks the best on macOS 11 Big Sur, but still supports Mojave and Catalina too.

And many other minor improvements and fixes. Enjoy!

We are getting ready to roll out a major update to Micro.blog. The web version and all the native apps are being updated at the same time. The new version will launch Tuesday, September 29th.

What’s new? To start with, the web version has been redesigned with a new sidebar, bringing common areas of your microblog like managing posts and uploads to the top-level of Micro.blog so they’re easier to access.

In the iOS and macOS apps, we’ve added new Pages and Uploads section, so you can create or edit standalone pages, and upload podcasts or other files to your blog. There are new icons in the sidebar and the layout in many screens has been improved.

On the Mac, creating a new post has been moved to its own window. This makes it easier to see the timeline while you are typing a new post or reply. You can also drag photos from the Uploads section into a new post.

We are expanding what the current $10/month plan can do, renaming it Micro.blog Premium. In addition to hosting podcasts and video, Micro.blog Premium will archive the contents of bookmarked web pages, with a special reader interface for highlighting text. You can quickly create a new blog post from highlights in Micro.blog.

I’ll be talking more about the new bookmarks and highlights as we get closer to launch. I’m excited to bring something totally new to Micro.blog, but in a way that stays true to Micro.blog’s mission of making it easier to blog.

And there are many other bug fixes and minor improvements, such as (finally!) editing replies. I can’t wait for everyone to check it out next week.

I’ve heard the excuses and I get it. You have family on Facebook. You have friends on Instagram. Maybe you can’t completely give up on those platforms. But you can shut them down for a month.

Facebook has not made enough progress in the last 4 years to deal with misinformation and hate. In the final stretch of the presidential campaign, why are we supporting any platform that risks the consequence of fake news and conspiracy stories spreading unchecked? Are we going to stop using Facebook and Instagram now, or are we going to wait until after Trump is reelected?

You don’t have to use Micro.blog. But don’t spend another minute on Facebook-owned platforms until after the election.

With my iPhone X glass broken, I needed a replacement phone quickly. The timing is not great because Apple has an event tomorrow, likely for the iPad and Apple Watch, with an announcement for new iPhones to follow within a few weeks. On the other hand, it has been nearly 3 years since I bought my iPhone X, so I don’t feel bad upgrading even to last year’s iPhone.

Meanwhile, there’s Android. As Daniel and I have been discussing on Core Intuition, I’ve been increasingly frustrated with how Apple manages the App Store. It would be good for me to have more experience with Android, eventually developing an Android version of Micro.blog.

Last year I bought a cheap Android tablet (Galaxy Tab A) to use for testing. I’ve been using it much more often, and it has become my “catching up on email, surfing the web, and Slack-ing while in the living room” device. The hardware is slow, but it runs Android 10, and already it has been useful for seeing how Android users experience Micro.blog.

iMessage lock-in remains the biggest problem with Android for me. I tried AirMessage, which Ben Thompson had good things to say about on Dithering. AirMessage runs on your Mac and essentially forwards messages back and forth to Android. It’s clever, but because I use a MacBook Pro exclusively, AirMessage will stop working if I close the laptop or take it somewhere else.

One option I seriously considered is getting a Pixel 4a and using an old iPhone (or ordering a new iPod Touch) just to run iMessage, Micro.blog, and anything else that I needed iOS for. It doesn’t make sense to go all-in on Android while I’m in the middle of wrapping up a major iOS upgrade to Micro.blog 2.0. Having 2 inexpensive devices would force me to live in the Android world while also keeping iMessage and everyday testing for Micro.blog 2.0. It looked like I couldn’t get a Pixel 4a shipped very quickly, though.

In the end, I’ve decided to upgrade to the iPhone 11 Pro. It arrives tomorrow. It’s the 3rd version of the iPhone X-style phone, so I know it’s a stable, better version of what I already have. I don’t know what the iPhone 12 is going to look like, whether the quality will be rushed because of COVID, or what features they’ll stick in that I don’t need. I’ll continue to tinker with Android, and maybe that will be my next phone, but it felt a little too early for such a disruptive change.

The latest episode of Core Intuition is out. From the show notes:

Manton and Daniel review Daniel’s experiences as his first podcasting sponsorship airs, and they talk more generally about being willing to “sink money” as part of a learning process in business. Manton talks about his interest in developing for Android, and we lament the increasing feeling that we need to hedge our bets against being “all-in with Apple.”

We’ve also been publishing more episodes of Extra Intuition, our podcast just for members, with the 10th episode out this week. You can subscribe for $5 and get a special podcast feed for the extra show, plus access to a members-only channel in Slack.

Sunlit 3.0 will ship tomorrow. For the last post in this blog post series to highlight Sunlit features, I want to mention a convenient way to follow Tumblr photoblogs.

Micro.blog is based on blogs and IndieWeb standards so that it can integrate well with the rest of the web, not be walled off like a silo. One aspect of this is that you can follow many blogs in Micro.blog even if the author of the blog hasn’t registered on Micro.blog yet, similar to how you can subscribe to blogs in a feed reader like NetNewsWire or Feedbin.

For Sunlit, there’s special support for searching for Tumblr blogs so that they are easy to follow directly from within Sunlit. Use the search under the Discover tab to enter the domain name to follow, as shown in this series of screenshots:

There is expanded support for following other blogs and even Mastodon users in Micro.blog itself. You can always use Micro.blog to find a blog to follow, then go back to Sunlit and those posts will appear in the Sunlit timeline.

Tomorrow we’ll update the App Store for the Sunlit 3.0 release. I hope you like it!

Sunlit 3.0 will ship in 2 days, on Tuesday. Today I’m going to highlight how Sunlit’s timeline can be used to browse and reply to photos.

Sunlit’s timeline is built on the Micro.blog timeline. When you follow someone in either Micro.blog or Sunlit, their photo posts are added to the Sunlit timeline. It’s strictly reverse-chronological based on who you’re following. No ads. No algorithms.

This quick video shows how scrolling through the timeline works, and how to reply to posts and view conversations.

Tomorrow I’ll have the last post in this series about Sunlit 3.0. We’ve also been working on some additional bug fixes that will be rolled into 3.0.1, shortly after launch.

Sunlit 3.0 will ship in 3 days, on Tuesday. Today I want to highlight another new feature: the redesigned Discover browsing interface.

Both Sunlit and Micro.blog use Discover to help you find people to follow. Because Sunlit is all about photos, Sunlit takes the usual Discover sections from Micro.blog, but shows only the photos from each section instead of all post types.

For example, tapping on 📚 at the top of Discover will show microblog posts that have used the books emoji along with a photo, which will often be a book cover or other photo of the book. Tapping on 🧶 will usually show people’s knitting or crochet projects. Tapping on ☕️ will show coffee-related photos. Tapping on 🍞 will show baking.