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.

It’s a great way to discover people to follow even if they haven’t posted a recent photo that you might see in the main 📷 photos section.

Check back tomorrow for another blog post in this series as we look forward to the Sunlit 3.0 launch. And thanks to everyone who tested the Sunlit beta!

Sunlit 3.0 will ship in 4 days, on Tuesday. Today I wanted to highlight one of the new features in 3.0. We’ve redesigned the new post screen to be faster and more flexible than the previous version. It’s great for posting a quick single photo, but it can scale up to full blog posts with multiple sections of text and photos.

Here’s a screenshot for part of a blog post I wrote last year about a trip to Toronto. Sunlit lets me structure the blog post in sections that can each have one or more photos. It then uploads the photos to my blog along with the HTML layout for the post.

I’ll continue this blog post series about Sunlit 3.0 with a new post tomorrow.

I was listening to Jason Fried on This Week in Startups today while out taking a walk, and Jason said something so extraordinary it kind of stopped me in my tracks. On the Hey vs. Apple controversy:

If the Apple decision would have gone the other way, I was considered quitting, and basically retiring. […] Here’s why: I didn’t get into business — I didn’t start a business — to be told what to do by another business. […] We’re self-funded. We do everything our own way so that we can do it our own way. And to be in an industry where if Apple forced us to have to give them 30% of our business and not be able to interface with our customers the way we want, I don’t want to be in that industry.

The segment starts about 60 minutes in. Here’s an Overcast link to the spot in the podcast.

Even more than the latest case with Epic Games, or WordPress iOS rejected for weeks, that quote from Jason highlights what this is all about. Apple’s total control over iPhone app distribution and payment is preventing developers from doing their best work. The App Store started with good intentions, to help users, but the rules have become twisted, corrupted as Apple gains power. It’s not right.

A couple months ago, we watched The Spy Who Came In from the Cold and then became kind of obsessed with finding other old spy movies. Next we watched a series with Michael Caine, and then moved on to James Bond, and so on, filling in a bunch of movies we’ve never seen over the course of a month.

Here’s the complete list, with a short note about each one or each series. First the standalone movies:

• The Spy Who Came In from the Cold (1965): John le Carré. We didn’t rewatch Tinker Tailor Soldier Spy, but it’s another great one.
• North by Northwest (1959): Alfred Hitchcock. Now I understand all the praise this movie gets.
• Three Days of the Condor (1975): With Robert Redford, I feel like this could almost be a prelude to Sneakers. One of my favorites from our month of watching spy movies.
• The Third Man (1949): Not a spy movie, but written by someone with espionage in their Wikipedia bio. We discovered it while looking for other films.

Then three movies with Michael Caine, based on books by Len Deighton:

• The Ipcress File (1965)
• Funeral in Berlin (1966)
• Billion Dollar Brain (1967)

This series started great, and I would’ve loved to see more movies with Michael Caine’s Harry Palmer character, but by the 3rd movie the plot has gone completely off the rails. The author Deighton had an interesting career.

Sean Connery as James Bond. I hadn’t really seen most of these, and never in order before:

• Dr. No (1962)
• From Russia with Love (1963)
• Goldfinger (1964)
• Thunderball (1965)
• You Only Live Twice (1967)
• Diamonds Are Forever (1971)

We alternated between old Bond and the new movies with Daniel Craig:

• Casino Royale (2006)
• Quantum of Solace (2008)
• Skyfall (2012)
• Spectre (2015)

Just for fun, we rewatched all the Austin Powers movies too:

• Austin Powers: International Man of Mystery (1997)
• Austin Powers: The Spy Who Shagged Me (1999)
• Austin Powers in Goldmember (2002)

I think I’m now officially burned out on spy movies for a while.

Today we’re officially announcing version 1.1 of JSON Feed:

We’ve updated the spec to version 1.1. It’s a minor update to JSON Feed, clarifying a few things in the spec and adding a couple new fields such as authors and language.

The jsonfeed.org site has also recently switched over to be hosted on Micro.blog. The design and previous URLs are all preserved or redirected. I created a simple Micro.blog theme to adapt the old site.

This week 5 years ago, I was winding down the last few days at my regular job. It was a great job working with great people, but I knew I had to move on to be able to create Micro.blog. In a blog post on my last day at the job, I wrote about starting over and the hope for what would come next.

The years since have been both amazing and difficult. Only recently, a few years after launching Micro.blog, does it feel like things are really starting to click. Micro.blog has improved significantly and the community keeps growing. For all the things we still want to do, we’ve also done quite a lot already that I’m very proud of.

Thanks everyone who reads this blog or participates on Micro.blog. The next 5 years are going to be fun.

I’ve been experimenting with a few different features around books on Micro.blog. The goal is to make it easier to blog about a book you’re reading, or to discover other books from fellow microbloggers. Some of these features are now tied together in a more cohesive way, so I’d like to summarize what we have.

There are 2 new buttons on the Discover → 📚 page:

• Book Covers shows a grid view of covers for books that people on Micro.blog are blogging about. Each cover links to the individual microblog post. Any microblog post that links to Micro.blog’s book detail page (micro.blog/books/isbn-here) will automatically be included in the grid view.
• Book Search lets you look up a book by an ISBN-13 number, or search for a book by its title or author. This uses a combination of Open Library and ISBNdb. I added ISBNdb to have another source of metadata and it really helps fill in some gaps.

Micro.blog also continues to work great with indiebookclub. Micro.blog will format your microblog post and link the book if you’ve included the ISBN, so it will show up in the 📚 page as well as the new covers grid view.

We’re not trying to reinvent all of Goodreads here, but I’m pretty happy with the way these book features are falling into place. If you like to read (or wish you read more often!) I hope this makes Micro.blog more useful for you.

Micro.blog used to have a feature that would mirror the HTML and photos for your blog to GitHub, so that you’d always have an extra copy as a backup outside of Micro.blog. The initial version of this feature had some limitations that forced me to disable it over a year ago. I always hoped to bring it back in another form, and today I rolled out the replacement.

The new version of GitHub archiving has a few changes:

• It uses a new structure based on the Blog Archive Format. It is a single HTML file (with Microformats), a JSON Feed (with both HTML and original Markdown), and all your uploads, like photos, videos, and podcast episodes.
• It now has more limited access to your GitHub account for better security. It only works with your own public repositories. If you previously used this feature, I’ve cleared any access that Micro.blog used to have.
• It is designed as an archive, not a live mirror, so it only sends changes to GitHub about once a week. You can enable it and then forget its there, and I can keep supporting it because it uses fewer server resources.

I’ve updated the help page to describe the new feature. It’s available under Posts → Design.

One of the minor hassles that has held me back from blogging about books I’m reading is finding the ISBN and cover art. To improve this workflow, I’m testing out a new book search feature on Micro.blog.

Type in the title of a book, and Micro.blog will search Open Library. It is not as complete as Amazon or Goodreads, so I hope to expand this in the future with more data sources. You can add author or ISBN to the search too.

Micro.blog will also show thumbnail images for any book covers that are found for the various editions. You can click on one of the book covers to select it, leading to this page:

From there, use the Micro.blog or indiebookclub buttons to start a new microblog post with the title, author, and ISBN filled in:

I’ve made a few minor improvements to the web posting form for Micro.blog. The “Preview” button now supports Markdown tables and footnotes, so that it more closely matches the Markdown rendering on your published blog.

The new post URL also now accepts an optional text parameter to pre-populate the text form. For example, to start a new post on the web with the word “Hello”:

micro.blog/post?text=Hello

This is similar to the URL schemes used in the native iOS and macOS apps. It’s useful for creating bookmarklets or sharing from other apps.

We had a great Micropub pop-up session over the weekend, discussing a dozen Micropub extension proposals. I’ve now implemented some of the improvements in Micro.blog:

• Added a filter parameter when getting the category list. If someone is using categories more like tags and has hundreds or thousands of categories, the server can now filter them, making it easier to build category auto-complete in client apps.
• Added support for standalone pages. You can create a page by sending mp-channel=pages. To query a list of pages, use q=source&mp-channel=pages. Update: Changed from h-page to instead use the new channels idea.
• Added q=contact to help clients do username auto-complete. This requires the filter parameter. Clients should also maintain their own username cache, built from the timeline or following lists, so they can show results quickly even before asking the server.
• Updated q=source on the media endpoint to support paging through uploaded photos with limit and offset parameters.

Micropub continues to improve through IndieWeb community discussions like this. If you’d like to learn more about Micropub, I’ve published the Micropub draft chapter from my upcoming book here.

A couple weeks ago I posted a sneak peek at Sunlit 3.0, our iOS companion app for photos. Today we’re opening up the beta and also making the source code public.

You can sign up on TestFlight here. There are still some rough edges, and this version is mostly for iPhone. iPad will be improved in the next beta, and macOS will follow later.

Sunlit can post to Micro.blog-hosted blogs, WordPress, or any blog that supports the Micropub API. You can use it with a free Micro.blog account or a paid subscription.

Composing a new post is much more flexible now. You can post a quick photo, or you can create a full blog post with multiple photos and text sections. I’ve created a screencast below to show how it works:

Jon Hays also joined me on the latest episode of Timetable to talk about the Sunlit beta and more.

Our app Sunlit has an interesting history. Jonathan Hays and I came up with the original concept for the app way back in 2012. The app changed form a couple times, first building off of App.net, and then adapted for blogging. Along the way, it accumulated a lot of baggage — old code and old designs that made it difficult to keep improving the app.

Today I’d like to give a sneak peek at what’s next for Sunlit: version 3.0, a complete rewrite, sharing essentially no code with previous versions. Jon has been working on this for a while, leading development while I focus most of my time on Micro.blog itself. We are taking what we’ve learned and trying to build an app that can appeal to people looking for an Instagram alternative, as well as people who want more control over publishing blog posts with multiple photos.

Here are a couple screenshots:

The app will also be completely open source. It can publish to Micro.blog, WordPress, or via Micropub to IndieWeb blogs. It’s written in Swift. There’s no release date yet, but there will be a public beta, and we hope to take the time to get it right.

I often hear from people who like the built-in designs on Micro.blog-hosted blogs, but they want to customize just one little thing about the default HTML. No problem! Because the designs are built with Hugo, you’ve been able to create a custom theme to override any template file or add new functionality to your blog. But that flexibility comes with a learning curve: it requires knowledge of HTML, CSS, and sometimes even JavaScript.

Today I’m launching a plug-ins system for Micro.blog that formalizes a lot of the power of Micro.blog themes, but wrapped in a package that is easier to develop and install. Instead of creating a custom theme for your blog and editing the templates yourself, you might be able to find a plug-in that will add the feature. Unlike custom themes, there can also be multiple plug-ins installed for a single blog.

Here are a few of the things plug-ins can do:

• Provide a brand new design. Plug-ins are actually just special Hugo themes, so anything a Hugo theme can do, a plug-in can provide. Now web developers can create custom blog designs that are easy to install.
• Override one or more template files in a theme. For example, changing the header or footer, or adding new CSS or JavaScript includes.
• Add new Hugo parameters that are available in the plug-in or another custom theme. Micro.blog can even show a settings screen so that users can edit parameter values easily.

There is a new plugin.json file that a plug-in can provide to tell Micro.blog what parameters should be configurable for the plug-in. This file also includes the plug-in metadata and any extra CSS or JavaScript references.

Here’s what a plugin.json file would look like for a plug-in I wrote to provide some more control over Micro.blog’s default Photos page. Because the plug-in defines some parameters, those are available in a settings UI inside Micro.blog automatically:

Plug-ins are available under a new “Plug-ins” tab in your blog settings. Click “Find Plug-ins” to see a list of registered plug-ins.

Since this is brand new, it only includes a few plug-ins that I wrote. Web developers who want to contribute a new plug-in to the directory can email me: help@micro.blog. There’s a help page here with more details about developing plug-ins.

And if you have ideas for a plug-in, let me know that too. In the past, when I’ve heard a feature request that requires a custom theme, I’d have to consider either adding that as a built-in Micro.blog feature — which might complicate the UI for everyone, even if few people wanted the feature — or I’d explain how to create a custom theme to solve it. Now, I can implement some of those requests as plug-ins.

There’s a lot more which I’ll be documenting. Having said that, Micro.blog plug-ins can’t do everything. As we learn what people want, I’d like to work with plug-in developers to iterate on this system, as well as clean up some of the built-in themes so that it’s easier to override certain behavior in a blog. Enjoy!

It’s WWDC opening day. I wasn’t planning on writing about the App Store again, because I feel like I’ve said it all before, but maybe I haven’t put it together in one place, or in a concise enough format.

Because I’ve dedicated the last several years to working on Micro.blog and writing about the open web, I think about the problems with massive social networks all the time. I’m obsessed with it. The App Store is also a huge platform with far too much power, so fixing it is not all that different than figuring out what to do with Facebook.

Here are the 4 things Apple should do:

• Allow side-loading. Essentially like Gatekeeper on macOS, but for iOS instead, this can still allow Apple to disable malware while letting developers skip app review. As I wrote in 2011, there will always be another controversy until side-loading is allowed.
• Don’t require in-app purchase. Exclusive payment mirrors the problem of exclusive distribution, so both have a similar solution. Let developers charge customers outside the App Store. Apple should compete on payment user experience, not with force.
• Keep curating the App Store. Apple is on the right track with highlighting great apps in the store. The point of my post about open gardens is that by loosening their tight control over distribution, Apple would actually be more free to curate, even rejecting apps because there would be an alternative with side-loading.
• Lower the cut to 15%. For all paid downloads, all subscriptions, and for all companies. This is the least significant part of anything in this blog post, because as Jason Fried writes, choice is more important than money. But it would go a long way to rebuilding trust with developers.

Anything short of all this is a band-aid, not a permanent fix.

I have long argued for fixing the 2 most fundamental problems with the App Store: exclusive distribution and exclusive payment. With Apple’s monopoly on iOS app distribution, we should have more options such as side-loading, reduced payment fees, and flexibility to sell subscriptions outside the store without hiding external links from potential users.

See my blog posts from 2011, 2016, 2018, 2019, and my broader essay on open gardens.

Now the EU is investigating Apple. Apple’s response:

It’s disappointing the European Commission is advancing baseless complaints from a handful of companies who simply want a free ride, and don’t want to play by the same rules as everyone else… We don’t think that’s right — we want to maintain a level playing field where anyone with determination and a great idea can succeed.

This is the worst, most insulting statement from Apple that I’ve ever seen. Everything in it is backwards.

For a long time I’ve wanted to add quoting tools to Micro.blog, so that it’s even easier to embed text from other blog posts and add your own thoughts. Markdown block quotes are fairly easy, but do require a little more copy/paste work and some editing.

So I was really interested in the recent launch of Quotebacks, from Tom Critchlow and Toby Shorin. We’ve needed a kind of “embed microblog post” feature in Micro.blog, similar to the embedding that Twitter and Facebook have. Quotebacks are exactly that, but they work for anything on the web.

I’d like to run with Quotebacks and see where it leads us. For now, I’ve added “Embed” links on the Micro.blog Favorites page on the web. This is an experiment. It will likely change, either rolling out in some form to all the platforms, or based on feedback maybe we’ll go in a different direction.

I’ve also forked the Quotebacks repository and tweaked the JavaScript with a couple changes:

• Instead of routing the favicons through Google’s cache, Micro.blog’s version just uses the profile photos on your account directly with a new data-avatar attribute.
• Because copied microblog posts always have a profile photo, it is displayed larger with rounded corners.

How does this look? I’m embedding a microblog post below using this feature:

We’ve posted Core Int 424, talking with @danielpunkass about the ARM rumor, how it compares to previous transitions, WWDC, and more.

I’ve kept the “Embed” links isolated to the Favorites page so we can try a few things without disrupting the rest of your Micro.blog workflow. There are other questions to answer, such as how this should integrate with sending Webmentions, but I think having something like this to play with is a good first step.

We published a new episode of Core Intuition today. From the show notes:

Daniel and Manton react to Apple’s statement against racism, and also talk a bit about the Accidental Tech Podcast’s statements. They talk about trying to figure out what we can all do as individuals in the wake of this. Daniel talks about getting a Black Ink update out the door while continuing to struggle with finishing up MarsEdit 4.4. Manton shares an update on Micro.blog progress, and shares his new “stop keeping track of things” methodology for getting things done.

The podcast is 12 years old now, started right before WWDC 2008. I don’t know if we’ll still be recording 12 years from now, but let’s imagine we might be. What will America look like in 2032? I hope we will all be able to look back on the intervening years and say that we cared about something that mattered, supporting the people who made a difference.

We’ve updated Micro.blog’s muting today to work more consistently everywhere, with a new option to hide replies that mention the username you are muting. Now when you mute a username you’ll see an additional checkbox to enable this option:

Posts that would normally appear in any of the Discover screens or search are now hidden. Replies in the timeline and conversations are also hidden.

The muting interface is on the web under Account → Edit Muted Users. I’ve also updated the API to support muting.

Everyone reacts differently when frustrated by what they see in the world. When I don’t know what to do, I work. After 2016, that led to launching Micro.blog. Building a platform that can help people find a voice (and avoid amplifying the voices of hate). It seems small next to the more widespread changes that are needed in America right now, but it’s one positive thing I can focus on.

Barack Obama had a great essay on Medium this week, highlighting how working locally has a big impact:

If, going forward, we can channel our justifiable anger into peaceful, sustained, and effective action, then this moment can be a real turning point in our nation’s long journey to live up to our highest ideals.

What I read into his words and from many other posts over the last few days is that we all have a small part to play. The solution isn’t one daunting, impossible task but instead thousands of “minor” choices, from local elections, to what we say and write about, to where we donate, to how our social networks are designed, to which stories journalists cover.

Even small movements forward can make a difference. Stay safe, everyone.

No surprise since we launched microcasting on Micro.blog — short podcasts, usually around 5-15 minutes — that I love the short format of Dithering with John Gruber and Ben Thompson. Today’s episode covers the escalating Trump vs. Twitter drama. Ben says:

At the end of the day, people act like what Twitter should do is obvious. When, one, I can make an argument for any number of things that Twitter should do, all of which are in conflict with each other. But two, it turns out most companies are not prepared for the president of the United States to be tweeting murder conspiracy theories, and I think that’s a pretty understandable lack of preparation.

They cover a few angles of this. It’s a really good episode.

Last year I published an essay about open gardens that fits right into this discussion, on the balance between free speech and moderation in social networks. It remains a guiding principle of how I think about Micro.blog.

Nick Heer also has a good summary at Pixel Envy on Trump’s executive order with related links.

Three years ago I created microblogging.slack.com to chat about indie microblogging and Micro.blog. There have been many great discussions in that time, and I appreciate everyone who has contributed or helped other members of the Micro.blog community. But to continue to improve Micro.blog regularly, I need to focus on fewer support channels.

Daniel Jalkut and I talked about this on Core Intuition 421. It is not sustainable for me to work on new Micro.blog features at the current pace as well as be responsive in Slack. If someone has a question about Micro.blog, I want to point them to the best place to get a thorough answer, and that’s email.

Slack also has a couple problems:

• It’s a proprietary platform that doesn’t fit well with our goals for Micro.blog. For example, you can’t have your own domain name for Slack, which makes migrating away very difficult.
• Because the search is limited to only recent messages, it is less useful as a resource to new members.

Last year, Jean MacDonald and I considered replacing Slack with Discourse. We may still do that, or it may be that forums around microblogging should best be run by the community rather than an official channel of Micro.blog. There is also a great IndieWeb chat accessible via Slack.

This weekend, I’ll be closing the current Slack. I will export all the data for backup — just in case we want to rebuild it in the future, or make the messages searchable — and then I’ll completely delete the Slack account, unless I can find a more elegant way to handle shutting it down or pausing it.

Thanks again to everyone who has participated in the Slack community, sending feature requests, helping others with Hugo theme questions, and just being supportive of the mission of Micro.blog. See you on Micro.blog!

I added a new built-in design to Micro.blog today: Archie, based on the Hugo theme of the same name. It has been lightly modified to work well in Micro.blog, and my changes are on GitHub.

What I liked about this theme is that it was different than most of the built-in designs, and it has a custom dark mode interface:

The link colors can be changed using a custom theme by editing the top of the main.css or dark.css templates.

Just a quick update for the iOS version of Micro.blog. From the release notes:

• Fixed username search.
• Fixed opening links to account-related screens in posts.
• Fixed navigation bar glitch when dragging conversations on some iPads.
• Updated full-screen photo viewer to not hide status bar.

You can download it in the App Store.

Last week I made available an archive of all App.net posts, which I had downloaded right before App.net shut down. There are now a couple tools to help process your own App.net posts from the archive.

Jordan Merrick has an iOS shortcut to download your posts:

Posts are made available as JSON dictionaries containing various pieces of information, such as the text and date created. All posts are downloaded and saved as individual JSON files to iCloud Drive at /Shortcuts/ADN Archive.

And Matt Bircher has a web app that can download your posts as a CSV file. If you have thousands of posts, note that both solutions are going to take a long time to run, because they have to download one post at a time from the archive.

I’ve redesigned the theme text editor in Micro.blog, adding a preview pane and other improvements. It now features a split view with the template on the left and your web site on the right.

When you update a template, Micro.blog publishes your change and then reloads your web site. Micro.blog knows when the publish has finished, so you no longer need to keep reloading, waiting for the change to show up.

This works best with a test blog, which you can create from Posts → Design → Edit Custom Themes. You can use it with your main blog too, but test blogs are usually faster to update. If your theme is being used by multiple blogs, Micro.blog will always show the test blog in the split view.

I’ve also updated all the built-in designs to include the theme modified time in any CSS references on your blog. This helps web browsers reload your design right away, while still caching the CSS until you edit your theme again. There’s a new Hugo variable for this: .Site.Params.theme_seconds

If you’ve ever worked on a custom theme, I think you’ll find this interface drastically better than the old workflow. It is much easier to iterate on a design. Enjoy!

I rolled out 2 major improvements to Micro.blog’s import feature today:

• You can now import from a folder of Markdown files. This is designed to help migrating to Micro.blog from Jekyll, Hugo, or Blot. It supports basic front matter such as title, date, and categories or tags.
• WordPress import has been updated with support for photo attachments that are not referenced in the blog post. Micro.blog will attempt to download your photos and store them on your Micro.blog-hosted blog.

You can read more about this over at the help. For the Markdown import, keep in mind that it’s just a ZIP file of Markdown files. It does not support including photos inside the archive because they will be downloaded from the web during import.

Despite the hiccup last night with profile photos while Linode had downtime for maintenance, Micro.blog should also be running significantly faster than before. I upgraded 2 servers last week.

Here’s a quick tip about iA Writer’s new support for Micro.blog. If you use hashtags in iA Writer to organize your documents, you can configure your hosted microblog to automatically assign Micro.blog categories based on those tags.

When you publish to Micro.blog, the tags from iA Writer will be included in the blog post content. Create filters in Micro.blog to automatically assign categories based on those tags. Filters are run whenever a new blog post is created.

Here’s what a post might look like in iA Writer, using the hashtag #travel:

In Micro.blog, click Posts → Categories → Edit Filters to create a new filter. For the text, enter #travel, because we know it will appear somewhere in the text content. Then pick a category to assign for any matching posts:

Note that the hashtag will still appear in your blog post, although you can edit it out later if you want to.

Exciting news today: the latest version of iA Writer for both iOS and macOS can publish to Micro.blog-hosted blogs. It uses the Micropub API, which is Micro.blog’s native API for posting.

To get started in iA Writer on iOS, go back to the first screen in the app and tap the settings icon → Accounts → Add Account → Micropub. You’ll be prompted to approve iA Writer in Micro.blog. If you’re not signed in yet in mobile Safari, you can sign in first and then try again:

In a text document, tap the share icon → Publish → New Draft on Micro.blog:

When you publish a post, it’s saved on Micro.blog as a draft, and iA Writer opens a preview of the draft on Micro.blog. From there, you can tap to publish it.

Thanks to the iA Writer team for making this happen! And because it’s built on IndieWeb standards, it’s not just tied to Micro.blog. I’d love to see similar support in other popular text editors.

In the final week before App.net shut down, I whipped up a few scripts to download every post on the platform via the API. After that finished, I also attempted to download small versions of many of the photos, but ran out of time. This data has been sitting on one of my servers for the last 3 years.

Why did I bother? At a high level, see my post from 2012 called Permanence. I also hoped to build a tool that would let anyone export their personal archive, or even migrate it to a blogging platform like Micro.blog.

I took some time this weekend to make the posts available. It’s the bare minimum to find a list of posts for your username, then download them. There’s no HTML interface; the data is meant for apps or scripts to access.

Here’s the structure of the main URLs:

• adn.micro.blog/users/m/manton.txt — a list of my posts (first letter of username is used in the path)
• adn.micro.blog/posts/2012/08/11/20063.json — post ID 20063 on August 11th, 2012

There are also a very limited number of photos:

• adn.micro.blog/photos/2017/01/01/12345/1.jpg — for a hypothetical post ID 12345 on January 1st, the first photo if available (2.jpg for the second photo)

I’m still on the fence about integrating this as an import feature for Micro.blog. Right now, I don’t plan to. When Micro.blog first launched, we had a Twitter import feature, and I ended up disabling it because almost everyone who imported thousands of tweets into their blog regretted it.

At the very least, importing tweets or App.net posts requires some curation. It should be done thoughtfully, not with a single click.

If you use this data for anything, let me know! I tentatively plan to host these indefinitely, but I’m still looking for ways to simplify it, and may try again to move the archive to S3 in the future.

Today we’re launching a new feature on Micro.blog: support for multi-user blogs, so your whole team can write posts on a shared blog. We think it’s going to be great for small companies, families, and schools, with everything from shared photo blogs to podcasts.

When you upgrade a blog to the teams subscription, a new “People” tab will appear in Micro.blog. Here you can give existing Micro.blog accounts access to post to the blog, or you can invite new people. Team members can publish new posts, edit existing posts, upload files, manage categories, and more.

For example, for our Micro Monday podcast, previously Jean and I had to share a Micro.blog account to make changes to the podcast. Now it’s a team podcast where either of us can post with our individual Micro.blog accounts:

When someone is added to a team blog, that blog shows up as an additional blog on the web or in the native iOS and macOS apps. A single Micro.blog account can have access to any number of blogs and podcasts.

The teams plan is a $20/month subscription with unlimited users. It also includes podcasting and video hosting. If you invite someone who doesn’t already have a Micro.blog account, Micro.blog will give them immediate access to the team blog without prompting them to create their own microblog or sign up for a paid subscription.

To upgrade a blog, click on “Plans” and choose “Upgrade to Teams”. If you have any questions, let me know at help@micro.blog.

For the last 2 years, Chet Collins has published a microcast where he shares bits from his day with his kids. He wrote on his blog this week about why a podcast is such a nice format for capturing these memories:

Audio recordings, in an open format, are about as future-proof as you can get. Even more than that, these recordings deliver the actual sound of my children’s voices, their laughter, and their unfiltered thoughts. They are the perfect time capsule of my children, recorded and preserved for the future.

These recordings are very special. Using a podcast essentially provides some structure, transforming audio snippets from everyday life into a format that can be easily reviewed later. It’s more organized than a digital junk drawer of random video clips, which for most people are unlikely to ever be edited. Podcasts inherently have a narrator to give context.

The closest thing we’ve done is a family travel blog, where text and photos can be brought together to highlight certain parts of the day. A podcast would make a great addition to that.

Here’s a simple tip for using MarsEdit with Micro.blog. By default, formatting options in MarsEdit such as Bold and Italic map to HTML tags: <strong> and <em>. You can customize them to use Markdown instead.

Click on Format → Customize to bring up MarsEdit’s Formatting Macros window. Delete the existing Bold and Italic commands and click the “+” button to create a new one. For Bold, add “**” for the opening and closing markup and set the keyboard shortcut ⌘B. For Italic, use “_” and ⌘I.

Not everything in Markdown can be added to MarsEdit this way, but it’s nice to have a couple of the basics. You can also set the Preview Text Filter in the preferences window to Markdown.

I’ve updated Micro.blog for macOS to version 1.9.3 with a few bug fixes:

• Fixed crash importing photos from Instagram archive.
• Fixed not showing error message when posting fails.
• Fixed window and split view divider resizing.

If you didn’t know about the Instagram import, I made a video walk-through with details of how it works. You can download the latest version of Micro.blog here or choose “Check for Updates” if you’re already running Micro.blog.

Micro.blog supports primarily 2 APIs for posting to hosted blogs:

• Micropub, the IndieWeb API used in the official Micro.blog apps.
• MetaWeblog, the XML-RPC API used in MarsEdit for macOS.

XML-RPC used to be the standard for blog posting, widely supported in all blogging platforms. It is still used in WordPress today, and I’ve supported it in Micro.blog from the beginning. I’ve always wanted Micro.blog to be compatible with as many apps as possible, especially MarsEdit.

To understand XML-RPC, we have to go way back in blogging history, to 2001 and the original Blogger API by Evan Williams. Micro.blog’s support for XML-RPC still closely matches what the API looked like nearly 20 years ago.

As is obvious from the name, requests and responses in XML-RPC are sent as XML. Common data types such as integers, strings, and structs are encoded with rules outlined in the XML-RPC specification. To create a new post in the original Blogger API with the words “Hello world”, the request to the method blogger.newPost might look like this:

<?xml version="1.0"?>
<methodCall>
  <methodName>blogger.newPost</methodName>
  <params>
    <param>
      <value><int>app ID</int></value>
    </param>
    <param>
      <value><int>blog ID</int></value>
    </param>
    <param>
      <value><string>manton</string></value>
    </param>
    <param>
      <value><string>mypassword</string></value>
    </param>
    <param>
      <value><string>Hello world.</string></value>
    </param>
    <param>
      <value><boolean>1</boolean></value>
    </param>
  </params>
</methodCall>

Subsequent blogging platforms extended the Blogger API with their own features. Instead of blogger.newPost, Movable Type had mt.newPost with similar parameters, adding a title field. WordPress had wordpress.newPost.

To try to unify future improvements under a vendor-neutral standard, Dave Winer proposed the MetaWeblog API. MetaWeblog switched to passing content as structs, which could more easily be extended with additional fields, and added an image upload API, metaWeblog.newMediaObject. Dave patterned the field names after RSS:

The MetaWeblog API uses an XML-RPC struct to represent a weblog post. Rather than invent a new vocabulary for the metadata of a weblog post, we use the vocabulary for an item in RSS 2.0. So you can refer to a post’s title, link and description; or its author, comments, enclosure, guid, etc using the already-familiar names given to those elements in RSS 2.0.

Dave wasn’t the only one who hoped to bring consistency between feed formats and a blogging API. A couple years later, AtomPub was created based on Atom feeds.

Ben Trott of Six Apart, makers of Movable Type, blogged at the time about the benefits to basing an API on the Atom feed format, which back then was called Echo:

Benefits to developers: using the same data model and serialization for syndication, archiving, and editing simplifies the development of tools to work with (produce and consume) these formats, for obvious reasons: code written to produce an item in an Echo feed, for example, can also be used for producing data sent in an API request or packaged up for archiving.

AtomPub was adopted in Blogger but is not supported in any other modern blogging platforms. Earlier this year, MarsEdit developer Daniel Jalkut announced that he would also be phasing out support for posting to Blogger.

Between the early 2000s when there was so much activity around blogging standards, and the growth of the IndieWeb and W3C-recommended standard Micropub API in 2017, there was a notable lack of innovation in blogging. Everyone was pulled away to social networks. Platform-specific APIs became the norm. It is because of this lull that XML-RPC survived so long without a modern replacement.

So that brings us to today. Micro.blog has always worked with MarsEdit, but because it’s based on a standard that was frozen, MarsEdit could not support all of Micro.blog’s features. And while Micropub is clearly the future, there is more we could do now without requiring MarsEdit to be adapted for Micropub.

I’ve been working with Daniel to identity what is missing from MetaWeblog and rolling that into a new Micro.blog-specific flavor of XML-RPC. This is essentially what Movable Type and WordPress had done years ago. I had avoided it until now because Micro.blog should default to supporting standards wherever possible before inventing something new.

We talked through this on Core Intuition 416. Now that there’s an alpha of MarsEdit 4.4 available, I’ve documented the new API parameters here. It is based on MetaWeblog, but cleaned up with more consistent field names and support for new features such as creating and editing pages on your blog, server drafts, and downloading all posts.

Micro.blog now shows up in MarsEdit as one of the supported blog systems, along with Tumblr and WordPress:

I’ve been using the new MarsEdit for the last few days, and it really is a big improvement for Micro.blog. Keep an eye out for the final release.

Like everyone, lately we’ve been watching a lot of TV. Here are some of the movies and shows we watched over the weekend:

• The Irishman: An epic 3 and a half hours. I’d like to rewatch it now that I know where the story was going and more about the historical backdrop.
• SNL at Home: Zoom sketch + Weekend Update were worth it alone. Great to see the cast adapting as best they can without the stage.
• HORSE tournament: If the NBA hadn’t suspended the season, this week would be the last before the playoffs started. HORSE had just the right balance of lightheartedness and competition.
• Emma: No regrets on this $20 rental. I think it’s in the top few Jane Austen movies behind Pride and Prejudice (2005) and Sense and Sensibility (1995).

And a few from last week and earlier:

• Tiger King: Difficult to look away once you start the first episode. Can’t decide if I regret watching the whole series.
• Onward: Loved this. I thought after the trailer I knew what to expect, but it surprised me.
• The Imagineering Story: There’s something in this 6-part series for most Disney fans. Next best thing to experiencing the Disney parks while they are closed.

Hope everyone’s staying safe and healthy at home. 📺

Podcasting with Micro.blog requires no configuration. Just upload an MP3 with your blog post and Micro.blog handles the rest: creating a podcast feed, using your profile photo as the cover art, and setting other defaults.

If you want full control over the podcast feed, it’s just a Hugo template. You can edit it with a custom Micro.blog theme to add anything you want. Because of this flexibility, I’ve been recommending that anyone starting a podcast on Micro.blog who doesn’t want to create a separate account (which would have its own profile photo) to tweak the podcast feed to override the default cover art.

Now it’s much easier. There’s a new feature on Micro.blog under Posts → Design that lets you change the cover art:

Click the existing cover art to select a new image from your uploads:

Happy microcasting!

I blogged years ago about how I started writing in a journal, originally in books and then in Day One. I’m trying to get back into the routine of writing regularly, so this week I upgraded to the new version of Day One. I had been sticking with the classic version because I liked syncing with Dropbox, but it stopped being supported on iOS in favor of Day One’s own syncing.

These journal entries are so important to me, I don’t really want them permanently encrypted in the cloud, where the data is opaque and could be lost. I’ve been thinking about a couple options:

• Export as plain text from Day One every month or so. These exports could be archived on Dropbox. Day One’s export options are great, even including printed books!
• Switch to using Micro.blog for journaling. Long-term, I really want all of my journal entries published on the web, but there needs to be some distance from the events. For example, maybe there could be a feature that automatically published entries older than 10 years.

For now, I’m enjoying using Day One. It’s well worth the yearly subscription. I may experiment with eventually moving to something blog-based, or look at adding Day One import to Micro.blog for anyone who wants to keep their journal and microblog in sync.

Version 1.8 of the Micro.blog iOS app is available. From the release notes:

• Added “Posts” menu for editing your recent posts. Designed for quick updates and typo fixes for Micro.blog-hosted blogs. Can also be used to publish drafts or delete posts.
• Switched to system font and tweaked colors and layout through the app.
• Fixed a few issues including missing push notification text.

Here are a couple screenshots of editing recent posts, similar to what the macOS version has had for a while:

You can download the update on the App Store.

We’ve been talking for a while about offering a “teams” plan on Micro.blog that would be great for small businesses, schools, and family blogs. With more people working from home, we’re already adding podcast hosting to all plans through April, and we think that podcasts and short videos could be valuable tools for teachers who are adapting their lesson plans for online classes.

We don’t want these teachers to wait until there is an official teams plan that schools can subscribe to, so today we are giving teachers free hosting for the next 6 months. This is a full Micro.blog account that can host blog posts, podcast episodes, and short videos.

To get started, email help@micro.blog with your school name and we’ll reply with a special invite to Micro.blog. We can’t wait to see what you use Micro.blog for.

I’ve added some info about creating draft blog posts to Micro.blog’s Micropub API help page. It also documents a new preview URL that can be used by third-party apps to send the user to a preview web page, with an option to finish publishing the post.

The preview renders the Markdown text, but does not process it through Hugo, so it might not exactly match the published HTML on your microblog in some cases. I plan to further improve this in the future to send it through Hugo.

Along with the new preview URL for the API, I’ve also fixed a bug creating draft posts with the JSON flavor of Micropub.

We’ve shipped version 1.7.3 of Micro.blog for iOS. From the release notes:

• Fixed issues and improved colors in Dark Mode.
• Fixed crashes when sharing some photos to Micro.blog from other apps.
• Fixed blurry thumbnails when selecting or filtering a photo.

There were several Dark Mode-related glitches fixes in this update. Dragging to view a conversation looks better, navigation bar colors update when switching to Dark Mode without restarting the app, and we’ve switched the timeline background color to use full black instead of very dark gray.

You can grab the latest version in the App Store. And if the official Micro.blog app isn’t your cup of tea, remember that there are other great third-party iOS apps including Gluon, Icro, and specialized tools like the new Mimi Uploader.

It is really easy in times like this to feel lost, unsure of how best to respond to the COVID-19 crisis. Micro.blog is a tiny company where we all already work from home. Jon Hays has even written a series of blog posts recently about working remotely with a team.

We wanted to do a little something extra for everyone who now finds themselves working from home, or needing to take time off work, to encourage everyone to stay creative and positive. Here’s what we’ve come up with: free podcast hosting for all hosted microblogs through April.

Merlin Mann was also thinking about how the world might see new podcasts right now:

Remember how there were (supposedly) so many pregnancies that happened during the New York Blackout?

I hope we get that but for really good new podcasts.

Jean MacDonald is working on some resources to help those who have never made a podcast before get started. Details will follow next week. In the meantime, we have a help page with the basics.

We’ve said since the launch of podcast hosting on Micro.blog that everyone has a story to tell. That’s probably even more true right now. We are also extending all Micro.blog accounts that have already expired for an additional 30 days.

And if you already have a paid subscription but you’re getting hit hard financially right now, drop us an email and we’ll credit your account for the month. Take care, everyone!

MarsEdit developer Daniel Jalkut had a great post recently about protecting privacy by stripping out location information from a photo’s metadata before uploading it to your blog:

If you choose to publish photos in your blog posts, it’s important to understand that image metadata may reveal more to your blog’s readers than you necessarily intended.

We followed up on this for Core Intuition episode 409 and again briefly on episode 411.

Micro.blog also tries to strip out location information, but a couple of times it has been applied inconsistently because there are several different ways to get a photo in to Micro.blog. I’ve found and fixed a new bug related to this and want to document it here.

The native iOS and macOS apps for Micro.blog have always fixed the orientation information in a photo and stripped any metadata before uploading. The web version of Micro.blog also did the same thing on the server when using the Uploads tab. But I noticed a case where this processing was skipped when attaching a photo to a new post on the web and not uploading it separately in the Uploads tab or with a third-party app.

As a precaution I’ve decided to retroactively strip metadata from existing photos that have been uploaded over the last few years. I wrote some scripts to check these photos, updating both our primary photo storage and the published blogs that were affected.

I also stripped metadata from any profile photos that contained location information. In some cases, the colorspace may have changed. If you notice any subtle changes to your profile photo and want to re-upload it, you can do that under Account.

I’m sorry I missed this. If you have any concerns, let me know via help@micro.blog. You can also check one of your photos by downloading it from your blog and opening it in an app that can display metadata. (In Preview.app for macOS, choose Tools → Show Inspector.)

I’ve heard from a few folks recently who would like a better way to control on a per-post basis what appears on their blog and what appears in the Micro.blog timeline. The idea is that they are effectively writing for multiple audiences, and while they might want all posts on their blog, not everything needs to appear in the Micro.blog timeline where it’s more likely to spark a conversation.

One of the main goals with Micro.blog is to make blogging easier, so we very deliberately try to keep the posting screen uncluttered. Even basic fields like the title of a blog post don’t appear until they are needed. I’m not in a hurry to add more options, because more options can lead to confusion, making Micro.blog harder to use and more likely that someone will give up before posting.

However, there is a lot of power underneath Micro.blog, just one step removed from the default interface. We can leverage categories to build this feature of picking which posts should appear in the timeline.

The timeline itself is not magic. It is built from RSS and JSON feeds that tell Micro.blog where your posts are. Usually there is only one feed configured under Account → “Edit Feeds & Cross-posting”, and that feed includes all your posts. To limit what appears in the timeline, we can remove that feed and replace it with a feed that includes a more limited set of posts.

Micro.blog-hosted blogs already have RSS feeds for each category. Today, I improved the feeds to match the default RSS feed, so that they include the full text (and any photos) instead of a truncated version of the post.

You can create a category named something like “Micro.blog” or “Timeline” that will contain posts that you’d like to appear in the Micro.blog timeline. Categories are managed on the web under Posts → Categories. Then, remove the default feed from Account → “Edit Feeds & Cross-posting” and add the RSS feed for that new category. If the category is called “Timeline”, the URL for the RSS would look like this:

https://your-username.micro.blog/categories/timeline/feed.xml

Now when you’re posting, assign the new post to that category and it will appear on Micro.blog:

Your followers will see that post and can reply. All other posts will still appear on your Micro.blog-hosted blog on the web, and other readers can follow those posts in a feed reader.

I voted here in Texas on Tuesday. I’ve blogged in short bursts over the last few years about the upcoming election, and the last one, but now is a good time to collect my thoughts on the race.

Clyburn’s endorsement leading in to South Carolina was critical. Then there was the incredible coordination of Pete, Klobuchar, and Beto all endorsing within 24 hours of each other, culminating in that rally in Dallas the night before Super Tuesday. I’m not sure Biden even advertised in Texas. Everything changed very quickly.

I’ve tried to keep my mouth shut about Bernie because I was quietly psyching myself up to support him if he became the nominee. I’m still disappointed that he and his most hardcore supporters did not do more to help Hillary in 2016. He attacked her character for a year and too many people stayed home.

Now we need to welcome Bernie supporters back to the Democratic party and hope that anyone clinging to that perfect or nothing attitude can let it go, in the same way that I hope to let go of 2016. I think there’s inspiration in Hillary’s own support of Obama, especially her fantastic speech at the 2008 convention. It’s powerful. She knew that unity was more important than anything else.

Biden was not my first, second, or third choice. He might not have been your first choice. It’s not a good feeling when by the time voting comes around your favorite candidate has already lost.

I loved what Beto had done for Texas in 2018. I loved imagining how effective Klobuchar could be not just as president, but at unifying moderates who felt the country was being ripped apart at the extremes. The last thing we need right now is more divisiveness.

Beto and Klobuchar were out, so I voted for Warren. In a parallel universe somewhere, the timing of momentum would have worked out for her to be president, and she’d be a great one. But the Democratic party has spoken. The nominee must be Biden.

And it’s kind of fitting. Trump tried to preemptively cheat against Biden using leverage with Ukraine. Trump was caught, impeached, still did a lot of damage to Biden in the process… but you know what? We’re going to !#@%-ing nominate Biden anyway just to send a message to Trump.

Let’s get ready. Biden is now our best choice to get this country back on track, and as Klobuchar said, to put someone with a heart back in the White House. I’m starting to get excited thinking about all the great choices he will have for vice president.

While we have greatly improved the performance of publishing new posts to your microblog and refreshing feeds, there are still occasional hiccups where posts don’t appear in the timeline as fast they should. Today I’m adding an obvious feature: a refresh button!

This screenshot is from the Account → “Edit Feeds & Cross-posting” screen. The refresh button simply tries to download your feed again as soon as possible, instead of waiting in the backlog of potentially thousands of other feeds Micro.blog is checking.

You should very rarely have to click this. Micro.blog is always checking your feeds for new posts. But if your posts aren’t appearing in the timeline right away after they show up on your microblog, this button will help speed up the process if anything is stuck because of errors.

Behind the scenes, the refresh button is just sending POST /ping with your feed URL. This is automatic for Micro.blog-hosted sites and can be automated from external hosting as well.

During the project day at IndieWebCamp Austin last weekend, I built a new feature for Micro.blog that I’m calling Conversation.js. It’s a JavaScript include that lets you take a conversation on Micro.blog and drop it into your blog.

Like a lot of Micro.blog features, it works either as a simple feature you can enable with a click, or as a more advanced API that can be customized however you’d like. If all you want to do is enable the feature, just click on Posts → Design and look for this checkbox:

Behind the scenes, this checkbox is adding a new Hugo parameter .Params.include_conversation that can be used in a custom theme. All the built-in Micro.blog designs have been updated to check for this parameter and then add the following line of JavaScript:

<script type="text/javascript" src="https://micro.blog/conversation.js?url={{ .Permalink }}"></script>

This JavaScript include gathers the replies to the current blog post and adds them to your web page. The HTML elements all have class names so you can style the replies to match your site.

See this page on my blog for how the replies look on one of my blog posts.

If you need even more control, you can request the conversation as JSON from apps or scripts by adding format=jsonfeed to the URL. Or you can add format=jf2 to produce output that matches Webmention.io, so it’s easier to repurpose tools that already work with Webmention.io.

Speaking of Webmention, this is not just about taking Micro.blog-only replies and putting them on your blog. Because all Micro.blog-hosted blogs support Webmention, and Micro.blog can accept mentions even from blogs that have not yet registered on Micro.blog, with Conversation.js it now becomes much more useful for other blogs to send you replies. Those replies can appear on your blog, with Micro.blog mostly acting as glue so that both blogs can talk to each other.

I’ve been wanting to do something like this for a while. It didn’t take long at IndieWebCamp Austin when I finally sat down to code it, but I think it opens up a lot of options for Micro.blog in the future, including acting as an IndieWeb-friendly replacement for Disqus and other commenting systems.

IndieWebCamp Austin is this weekend! Jean MacDonald will be in town for the event, so we’re also going to have a Micro.blog meetup on Friday evening. Anyone interested in Micro.blog is welcome to join us whether you’re attending IndieWebCamp or not.

Easy Tiger on 6th Street, 5-7pm. Jean and I will be there a little early to get a table, probably outside if the weather’s nice. We’ll have Micro.blog stickers.

Hope to see you at the meetup! And you can also still register for IndieWebCamp Austin.

Gluon is the first cross-platform mobile app for Micro.blog. It supports multiple Micro.blog accounts and features like local drafts, muting, and themes. Developer Vincent Ritter has documented the development process on his blog through several iterations of the app.

Congrats Vincent! You can download Gluon on the App Store here.

We’ll never have ads on Micro.blog. It’s really important to me that it’s user-supported and the timeline only includes posts you want to see. But if ads are already on a platform like Twitter, why not use them? I’ve experimented a couple times with Twitter ads. This week I decided to run a very small campaign to help get the word out about IndieWebCamp Austin.

I’m not sure it’s very effective, but I find the results interesting. Here’s a screenshot of the stats after the ad ran over the weekend:

IndieWebCamp can be difficult to explain succinctly. Micro.blog can be too, for that matter. But I’ve found the IndieWeb events I’ve attended extremely valuable, both to be inspired by what people are working on and to have a little time to make Micro.blog even more IndieWeb-friendly. Hope to see y’all there!

I’m happy to announce that we have 3 short keynotes planned for the first morning of IndieWebCamp Austin! After coffee and breakfast tacos, we’ll get the day started with an introduction to the schedule and our featured speakers.

Natalie Hester — Natalie keeps a gratitude journal on Micro.blog where you can see snapshots of her life as a full-time partner to Ryan, new mom to Aria, and academic fundraiser. She will be talking about her unlikely journey away from Facebook and what it’s like being a new mom on social media.

Pace Smith — Pace is a queer trans intersectional feminist Sufi bridger. She codes, podcasts, blogs, makes indie games, writes limericks, and tries to make the world a better place. She will be talking about the role of the bridger and building trust on the web.

Aaron Parecki — Aaron is an IndieWeb co-founder and security architect at Okta. He is the editor of several IndieWeb specifications at the W3C. He will be talking about using an Indie Reader to take control of how he follows and responds to people online.

Before we break for lunch, we’ll plan the afternoon sessions. If you’ve never attended an IndieWebCamp before, the rest of the sessions are organized by attendees. This helps adapt the conference to the topics that attendees are interested in.

I hope you’ll join us! Register here for $10.

For the last couple of years we’ve used Mailchimp’s Mandrill service to send transactional emails from Micro.blog. These emails are for when you get a link to sign in, or a reminder that your trial expired. It was convenient to have everything in Mailchimp because we also used it to send our newsletters.

Because Mandrill was going to be down for maintenance a couple weeks ago, I decided to switch over to SendGrid. I’ve used SendGrid in the past and while I left disappointed at the time, that was years ago and I recently got some great help from a SendGrid employee while troubleshooting Sign in with Apple. It was easy to switch back.

I’m also moving our newsletter emails over to SendGrid and hope to resume sending the Micro Monday newsletter this week. The savings are significant. We were paying MailChimp about $220/month. On SendGrid, the comparable set of plans will be only $65/month.

Daniel and I talked more about sending email on Core Intuition a couple weeks ago. We’ve had some good feedback from folks about their favorite email providers, both for and against nearly every popular service, so I wanted to document the change here on the blog.

When Daniel Jalkut posted about Apple’s email to keep his blog active in Apple News, I commented that Apple no longer even allows RSS for new blogs. I got this mixed up, though, confusing the options for publishers with what feeds users can add to the app themselves. Nick Heer followed up to clarify:

Nevertheless, it seems like it’s still possible — according to that News Publisher site — to create a new channel based on RSS. Existing RSS-based channels also appear to be functional still; this one is, at least. However, it is no longer possible to subscribe to an RSS feed as a user with Apple News.

I’ve now confirmed this. Today I tested using Apple’s News Publisher with a new Apple ID, and it does let you add RSS sources. However, it really discourages it. The default is Apple News format, and when you switch to RSS you get this prompt:

As soon as you start using Apple News format instead of RSS, you can’t go back to RSS. It’s hard to tell if this was a technical limitation with how Apple News manages different feeds on the backend, or a decision to move Apple News away from RSS. Probably a little of both.

Sam Grover has been working on a new iOS app for Micro.blog called Mimi Uploader that is all about batch uploading photos to your blog. I love it because it takes a specific need and provides a really polished workflow just for that. After the upload finishes, you can copy Markdown or HTML to reference all the photos for easy pasting into another app or Micro.blog on the web.

It’s now available as a public beta. There’s a link to the TestFlight beta on Sam’s microblog.

When I was first developing Micro.blog, I made a choice that quick replies in the timeline should be stored separately from regular blog posts. I thought that most people wouldn’t want replies mixed in with their blog posts at their own domain name. I also liked that replies were simple, usually short and without images, because it makes the timeline much more readable.

This has admittedly poked a hole in one of the most important goals of Micro.blog: owning your own content by having it at your own domain name. If someone wanted more control over their replies, they would need to use an external blog like WordPress, even though Micro.blog had great support for Webmention and cross-site replies.

I always thought this limitation would be temporary. As I’ve been finishing up my book Indie Microblogging, this trade-off with replies from the early days of Micro.blog has become untenable for me. Storing replies outside of your Micro.blog-hosted blog, even if you can export them or move to another IndieWeb-friendly platform, is too silo-like for the mission of Micro.blog.

Today I’m rolling out the first of a series of improvements to replies. You can now optionally have your replies on your own blog, with reply permalink URLs at your own domain name.

Here’s a screenshot of the option on the Account screen. The popup menu will include any blog that’s hosted on Micro.blog, so you could even create a separate microblog just for replies:

Replies get a new reply post type in Hugo, which is used under-the-hood for your microblog. This means they won’t show up in your default feeds or home page, although you can create a custom theme to change that.

Micro.blog adds a few Hugo parameters that can be used for reply HTML templates:

• .Params.reply_to_url: The URL for the post you are replying to.
• .Params.reply_to_hostname: Just the hostname part of the reply-to URL.
• .Params.reply_to_username: The username for the Micro.blog user you’re replying to.
• .Params.reply_to_avatar: The URL for the Micro.blog user’s profile photo.

I’ve added a new template in the Marfa theme to use these:

There’s also a new page at yourblog.com/replies with the most recent replies. If you enable pagination under your blog’s settings, that page will expand to show all your replies.

It’s still early for this feature, and for now I’ve made some of these customizations only in the Marfa theme. Consider this new plumbing that you can take advantage of in your custom themes, with more improvements to follow later so this works as consistently as possible across all the built-in designs. But it is a major step to strengthen the IndieWeb principles in Micro.blog.

I was looking through some of my drawings while copying a backup from an old hard drive. Around 2003 and 2004, I worked on a hand-drawn animated short film in my spare time, based on my kids. I never finished it, but I made thousands of drawings for it, most of which I shot with a camera and put together as rough tests.

Here are a few seconds of one little scene that I found while looking through the old files:

I was sick a few days before Christmas and it forced me to take some extra time off after a very busy November and December. Happy to be back blogging and looking forward to 2020, so let’s wrap up the holidays with a post about Christmas movies.

This isn’t necessarily a list of the best Christmas movies. There are other classics that are usually on an all-time best list that aren’t here. This is a list of my 10 favorites.

1. The Nightmare Before Christmas — Perfect for Christmas or Halloween. So nearly flawless I had to put this at the top of the list.
2. The Muppet Christmas Carol — There are many great adaptations of A Christmas Carol, and last year we watched pretty much all of them. I wish there was room to include a couple of the animated versions, like Richard Williams' A Christmas Carol and Mickey’s Christmas Carol.
3. A Charlie Brown Christmas — “That’s what Christmas is all about, Charlie Brown.”
4. Klaus — Beautifully animated. Brand new, but now that I’ve seen it twice I know it will hold its own against the best. There’s a great interview with director Sergio Pablos on The Bancroft Brothers Animation Podcast.
5. Elf — We probably rewatch this more than anything else. Can’t say enough good things about the variety of movies Jon Favreau has worked on (not to mention The Mandalorian).
6. Meet Me in St. Louis — I’ll admit, I didn’t want to love this at first, years ago, but now that I’ve seen it dozens of times it’s a favorite, and I think the best of the older classics.
7. National Lampoon’s Christmas Vacation — One of our traditions is to cut a tree down at the Elgin Christmas tree farm, and there’s a little of Clark Griswold in the endeavor.
8. Die Hard — Definitely a Christmas movie.
9. A Christmas Story — “You’ll shoot your eye out.”
10. Rudolph the Red-Nosed Reindeer — Check out this YouTube video about some of the editing problems with the recent TV version.

If I could only watch these 10 movies every year I’d be happy. But there are others we enjoy that deserve honorable mentions: Edward Scissorhands, Love Actually, It’s a Wonderful Life, Home Alone, The Grinch (2018), Jingle All The Way, and Christmas with the Kranks. And a special shoutout for the soundtrack of The Polar Express.

Happy Holidays! ❄️

This morning, Jack Dorsey dropped a bombshell:

Twitter is funding a small independent team of up to five open source architects, engineers, and designers to develop an open and decentralized standard for social media. The goal is for Twitter to ultimately be a client of this standard.

I should be excited about this, but instead my first reaction was frustration. Ten years after early Twitter employees like Blaine Cook and Alex Payne were pushing for a more open architecture, now Jack Dorsey realizes Twitter is too big and creates a team to work on… blockchain-based solutions?

Finally, new technologies have emerged to make a decentralized approach more viable. Blockchain points to a series of decentralized solutions for open and durable hosting, governance, and even monetization. Much work to be done, but the fundamentals are there.

The first step should be to check out the IndieWeb. There are people who have been thinking about and working toward more open social networks for years.

After a closer reading of Jack’s tweets, though, I think my first interpretation wasn’t quite right. Twitter isn’t necessarily interested in decentralizing content or even identity on their platform. Why would they be? Their business is based around having all your tweets in one place.

Early in the thread, Jack hints at what Twitter is trying to do:

First, we’re facing entirely new challenges centralized solutions are struggling to meet. For instance, centralized enforcement of global policy to address abuse and misleading information is unlikely to scale over the long-term without placing far too much burden on people.

This “burden on people” is the resources it would take for Twitter to actively combat hate and abuse on their platform. Facebook, for example, has hired thousands of moderators. If Twitter is hoping to outsource curation to shared protocols, it should be in addition to — not a replacement for — the type of effort that Facebook is undertaking. I’ve outlined a better approach in my posts on open gardens and 4 parts to fixing social networks, which don’t seem compatible with Twitter’s current business.

I’m going to be paying close attention to this. Good luck to Jack and the new team. I hope they seriously look at existing standards, because we’ve come too far to start over.

I’ve finished adding the special pin for anyone who participated in the Microblogvember challenge. Jean MacDonald also has an emoji recap of all the challenge prompt words.

There’s a link at the top of your Account page in Micro.blog, or click here to view your pins. If you don’t see the pin yet, it should appear whenever you post to your microblog next, which tells Micro.blog to check for new pins again.

Because some people started late or posted twice in one day, the “algorithm” for calculating the pin isn’t very strict. If you were blogging regularly in November and used 30 of the prompt words from the challenge, you’ll get the pin. This was a lot of fun and I hope we can do more challenges like this in the new year.

Now is also the perfect time to unlock the “Happy Holidays” pin by posting to your microblog with something about the winter holidays. It’ll match on a bunch of keywords including Christmas, Hanukkah, Santa, snow, reindeer, and a few others. Enjoy! ❄️

Interesting article from The New York Times about a report from the NATO Strategic Communications Center of Excellence. Researchers ran a series of experiments to buy likes, comments, and clicks on social media posts. They paid companies in Russia and Europe hundreds of dollars to buy thousands of likes and followers, writing up a report on the results:

But the report also brings renewed attention to an often overlooked vulnerability for internet platforms: companies that sell clicks, likes and comments on social media networks. Many of the companies are in Russia, according to the researchers. Because the social networks’ software ranks posts in part by the amount of engagement they generate, the paid activity can lead to more prominent positions.

The researchers then actively notified the social media companies about the fake likes and tracked what action the tech companies took, if any. Most fake likes and accounts used for the experiment remained online a month after they were reported.

It is very difficult for a massive platform like Facebook or Twitter to catch everything. Instead of trying to “fix” fake likes that are purchased, the solution is to remove the reason someone would purchase likes to begin with. If like counts weren’t featured so prominently and used for surfacing content, there would be no incentive to try to game the system.

Jean MacDonald has a great wrap-up post about the Microblogvember daily blogging challenge and the value of looking for “micro” versions of bigger projects:

Ever since I became the community manager of Micro.blog, I’ve developed an appreciation for the beauty of going “micro”: microposts, microcasts, micro meetups, microcosms of interesting humans interacting online on a human scale.

This is a key part of Micro.blog’s mission. Many people find writing a full-length blog post too daunting, but break it down into micro-sized posts and it’s easier for everyone. Jean continues:

This is what I like about a micro approach. Start with something small, and build on that. It also works with podcasting, for example. Micro.blog has spawned several microcasts (including our own Micro Monday) by making it easy to start small.

It reminds me of why we’ve added so many “full” blogging features to Micro.blog hosting, like longer posts, file uploads, categories, custom themes, standalone web pages, and podcast hosting. After you’ve “started small” and have a nice routine with microblog posts, the platform should grow to accommodate whatever you need next.

Early last Friday morning, one of the Micro.blog photo storage servers failed. I brought it back up shortly after I noticed, but dealing with the problem motivated me to make a change I’ve been thinking about for how photos are stored. Over the weekend I migrated the photo storage to a new system based on Linode’s Object Storage.

(Luckily, years ago when I was designing Micro.blog, I had anticipated I might eventually make a change like this. The old server was running Minio to provide an S3-compatible interface, internal to Micro.blog, so switching to a new system was much easier.)

When a photo is uploaded to Micro.blog, it has always been kept in at least 2 places: on a primary photo storage server, and on a copy of your published blog, along with HTML and other files. Both of these locations were backed up daily.

Over the summer there was a similar error to what happened last week. For some new uploads, only 1 copy of the photo was kept. If Micro.blog needed to rebuild your published blog files, there was a small window during which it could overwrite the latest photos that had been uploaded. Usually I’d be able to fix this from a backup, but I know at least 1 user who was affected by it, and there might have been a few more.

If you ever see broken images on your site, please reach out to help@micro.blog. You can also re-upload photos under Posts → Uploads in Micro.blog on the web and update any posts from the original photos.

Remember that Micro.blog also has built-in features for making extra backups for yourself, beyond the backups we already handle behind the scenes:

• Save new posts to the Internet Archive. There’s a checkbox to enable this under Posts → Design. When you publish a new post, Micro.blog automatically makes it available in the Wayback Machine.
• Export in Blog Archive Format. Micro.blog will make a .bar file that is actually a ZIP file with all your photos, HTML for posts, and a complete JSON Feed.

The new photo storage that is live now should be even more robust. Photos are a very important part of Micro.blog. I’ll keep improving this and adding storage redundancy wherever I can.

Today I sent the following update to Kickstarter backers.

Hi everyone! I’ve set a release date for the book Indie Microblogging: January 2nd, 2020. I’ll send an email that day to all Kickstarter backers with a link to read the book on the web.

You can preview the draft table of contents here: book.micro.blog

There’s a pre-order link on that page. You don’t need to pre-order the book because you will already have access as a Kickstarter backer, but please share the link on your blog, to followers on social networks, and with friends who might need a reason to dust off their blog or even start writing on the web for the first time.

Thanks for your support and patience as I’ve spent the last couple of years focused on building and improving Micro.blog. There is still a lot of work to do, but I’m excited to spend the next month wrapping up the book reward for Kickstarter backers.

And if you haven’t checked out Micro.blog lately, the community keeps growing and the platform has evolved to be great for full-featured blogs, not just microblogs. Photos, Hugo themes, categories, pages, podcast hosting, publishing from apps across iOS, macOS, Android, the web, and much more.

— Manton

P.S. Indie Microblogging is a book about the web, so I want it to be on the web first. After some time to incorporate fixes and improvements to the text, I’ll follow up with a print version for backers at the higher reward tiers.

I’ve blogged about Klaus a couple times. It’s one of those films that I was a little nervous about because I wanted it to be great, and it is. There is some wonderful character animation in this.

Animation World has an interview with director Sergio Pablos about what a positive experience it was to work with Netflix, and on getting few chances in life to do something great, especially with animated features:

You hope you’ve made something good, but you’re so close to it that you’re kind of blind to it. We’ve been trying to make a film for 15 years in my company and we’ve failed in different ways. Right? Sometimes a film would end up going elsewhere, or it wouldn’t even get made. Meanwhile, we’re taking service work to try and support our effort. So, it’s been a long road. But I always dreamt the day would come where I’d have a project I could be proud of.

Congrats to the team for doing something that feels new with 2D animation. I may need to get the art book.

As 2016 was winding down, I was determined to start 2017 with something new. On January 2nd, I launched the Kickstarter campaign for Micro.blog and a book I’m writing called Indie Microblogging.

In the years since then, I’ve put everything into Micro.blog to fulfill my promise to Kickstarter backers. Micro.blog does way more than I had dreamed it could do 3 years ago. But the more I put into Micro.blog, the more it needed of me, and the book kept taking a back seat until now.

I’ve set the ship date for the book: January 2nd, 2020. It will be published on the web for all Kickstarter backers, and if you missed the Kickstarter you can pre-order the book now for $20. The money goes right back into Micro.blog so that Jean, Jon, and I can continue improving the platform and growing the community.

When completed the book will be over 50 short chapters in 6 major parts, plus intro and conclusion sections that get to the mission of Indie Microblogging and the next steps. It will also feature several interviews.

You can view the draft table of contents here and pre-order the book. Thank you for your support.

You might think because I created Micro.blog that I have a perfectly simple blogging workflow that will work for everyone, all the time. Nope. I use a variety of different apps depending on what I’m trying to do:

• If I’m posting a quick microblog post and know what I want to say, I type it into the Micro.blog app for Mac.
• If I’m posting a single photo, I use Micro.blog on my iPhone.
• If I’m posting a bunch of photos like this post from Toronto, I use Sunlit to write a little something for each day.
• If I’m writing a longer post and have it all in my head, so I know I will post it very soon, I type it directly into MarsEdit and publish it to Micro.blog from there.
• If I’m writing a post and I’m not totally sure where it’s going, or when I’m going to post it, I type it into Ulysses. This is the majority of my posts. Then I copy it out as Markdown and paste it into Micro.blog.

And this only scratches the surface. There’s Wavelength for podcasts, and some people prefer apps like Icro, Gluon, Dialog, Quill, or automation via Shortcuts. This is why we link third-party apps from the posting screen in Micro.blog.

One of the things I’m most proud of with Micro.blog is that the API supports standards so you can use a variety of different apps for posting. There are so many different types of blogs out there, there shouldn’t just be one way to post.

We are getting really close to episode 400. Feels like a big milestone to me, and I’ve been wondering if we should change anything with the podcast format when we roll over into the 400s. But in the meantime, here’s 395:

Daniel and Manton try to take stock of long-term personal goals, thinking of how they align with and overlap with money-making goals. Manton reports back after watching Matt Mullenweg’s “State of the Word” talk at WordCamp US. Manton reflects on the important of simplicity for Micro.blog in contrast to WordPress, while Daniel considers that MarsEdit also serves as a more complex interface to Micro.blog. Finally, they digest the latest Apple announcements, focusing on the merits of the new AirPods Pro, and whether Apple TV+ is a justifiable pursuit for the company.

Daniel has already given me a sneak peek of next week’s manager check-in and it’s a good one. I think that is going to become a regular segment.

Brent Simmons marking the 20th anniversary of his blog:

It’s tempting to think that The Thing of my career has been NetNewsWire. And that’s kinda true. But the thing I’ve done the longest, love the most, and am most proud of is this blog.

The great thing about a personal blog is that if you stick with it, your blog will very likely span multiple jobs and even major life changes. You don’t need to know where you’re going to be in 20 years to start a blog today and post to it regularly. Writing about the journey — and looking back on the posts later to reflect on where you’ve been — is part of why blogging is still so special.

IndieWebCamp Austin is coming up in February at Capital Factory. This is our 3rd event in Austin and I’m excited to start getting the word out and help a lot of new people discover the IndieWeb. Registration is already open.

Tom Brown and Jean MacDonald are joining me as co-organizers and we’re looking for sponsors to help cover costs for the venue and breakfast for attendees. If you’re interested in sponsoring or work at a company that would be a good fit to support the IndieWeb, please email me: manton@micro.blog.

Platinum event sponsor: $2500

• Your logo on the IndieWebCamp event page.
• A verbal thank-you during the morning and closing of the event.
• You can bring t-shirts, stickers, and other promotional items to distribute to attendees.
• A special mention and link in the email we send to attendees the day of the event.

Silver event sponsor: $1000

• Your logo on the IndieWebCamp event page.
• A verbal thank-you during the morning and closing of the event.
• You can bring t-shirts, stickers, and other promotional items to distribute to attendees.

Bronze event sponsor: $500

• Your logo on the IndieWebCamp event page.
• A verbal thank-you during the morning and closing of the event.

Ben Thompson has an excellent article this week about free speech, political ads, and Facebook. There’s a good debate to be had about the roll of curation and fact-checking ads, but on the problems of massive, ad-based social networks there can be no doubt:

In the long run, though, it is very problematic that such a powerful player in our democracy has no accountability. Liberty is not simply about laws, or culture, it is also about structure, and it is right to be concerned about the centralized nature of companies like Facebook.

Platforms that have as many problems as Facebook does can always be improved, but by design they can never be good enough because their size alone is one of the problems.

The good news: it’s up to us. We can choose to reject these platforms and move to a more distributed web of indie microblogs. We can choose to reject the attention power-grab of the algorithmic timeline. We can choose to build the web we deserve… but it’s not going to happen if you keep feeding photos into Instagram.

There’s a powerful filter mechanism inside Micro.blog for automatically assigning categories based on criteria in the post. For example, if the post includes an img tag, assign it to a Photos category. Or if the post includes the 📚 emoji, assign it to a Books category. I blogged about this in September.

Today I’ve expanded this feature to also allow matching on whether the post is a short microblog post or whether it’s a longer post with a title. Like other parts of Micro.blog, it uses the title to determine how to categorize the post. Posts without titles are always considered short microblog posts.

To create new filters, go to Posts → Categories → Edit Filters.

You can use this in combination with matching the title or text in a post, or leave those fields blank when creating a filter to match all posts. This makes it easy to move all full-length posts into a category, which can also have its own RSS feed.

There’s a new built-in theme available on Micro.blog called Lanyon, based on the open source Hugo theme of the same name. It’s a clean, readable design with a slide-out menu for page links.

I’ve been working on getting several new themes ready for Micro.blog. Some Hugo themes work with only a couple tweaks, and some take more time. My fork of Lanyon with Micro.blog-specific changes is on GitHub.

Two new versions of the third-party Micro.blog app Icro have been released. The iOS version now supports push notifications, and a new version is available for macOS for the first time.

Because the official Mac app is distributed as a direct download, this is actually the first Micro.blog app available in the Mac App Store. It was ported to macOS using Catalyst, so it requires Catalina, which I just upgraded to. It’s great to have another microblogging option on the Mac!

For the last few years, right before the regular season starts, Jon Hays and I usually paste in our guesses for the top 8 in the west in chat. This year the west is up for grabs more than anytime in the last handful of years, so I thought I’d share my list:

1. Rockets
2. Clippers
3. Spurs
4. Blazers
5. Nuggets
6. Lakers
7. Jazz
8. Warriors

No doubt a few things are wrong here. For example, Dallas looks like a playoff team right now, and I left them out. But I’m excited to see how this shakes out, especially for the Spurs, who are exactly the team I was hoping they’d be now that Dejounte Murray is back.

Since the very beginning of Micro.blog we’ve encouraged you to use your own domain name with your microblog. It’s the best way to control your content and an important principle of the IndieWeb. Now it’s even easier.

If you don’t have a domain name yet — or need a new one! — Micro.blog can handle registration for you. We are using the Name.com API to purchase and configure the domain name for you. Payment is handled on your existing Micro.blog subscription and everything is automatic. No messing with DNS records.

Here’s a screenshot of finding a domain name, which is linked under the domain name section on Posts → Design:

I’m very excited about this feature. We’ll be expanding it based on feedback but it is already quite powerful, even including email forwarding. And of course, you can always register a domain name elsewhere on the web and point it to Micro.blog.

There have been a few IndieWebCamps recently, including in Amsterdam, New York, and Brighton. I’ve enjoyed reviewing the sessions, and after the Amsterdam event I noticed this post about content ownership:

When it comes to posting to Facebook or Twitter, you play a different game. You write and post it on their servers, therefore those companies own your data, not you. A photo (or video for that matter) is a special kind of data. Its file size creates limitations to its distribution, but no matter where it’s uploaded, it is always owned by its creator first.

While it’s good to acknowledge the unique hosting requirements of photos and videos, how we define content ownership shouldn’t be any different. People get lost in the weeds with running their own server, how to set up cross-posting to other social networks, where to post first, what formats and protocols to use, etc. But it’s actually much simpler than that.

I think in the tech world — and especially as programmers — we tend to make things more complicated than they need to be. We know too much about content ownership, most of it irrelevant for mainstream users.

If you want to control your content on the web, post it at your own personal domain name. That’s it. Everything else you want to do is icing on the cake.

Likewise, nothing else can be a replacement for that simple act of using your own domain name. You could write your own blog software with a custom database designed for ActivityPub and run it on a server in your basement. It doesn’t matter. Without the domain name, all you have is a pile of icing.

This has been the messaging for Micro.blog from the beginning. Keep it simple and make it easy for anyone to participate in the open web.

Following my experiment with importing Foursquare data, I’ve officially updated Micro.blog to support storing location information. The Micropub API now accepts checkin and location properties for sending venue name, URL, latitude, and longitude to Micro.blog. This works with the JSON format in OwnYourSwarm, which connects Foursquare/Swarm to your microblog.

Micro.blog on the web and the native apps do not send any location information. Right now this is purely an opt-in feature for third-party apps like OwnYourSwarm and custom solutions using the API. We consider location information very private and will never enable it automatically.

When a post has location information, you can see the coordinates in the posts list on your account:

The default Micro.blog themes do not currently do anything with this information. You can create a custom theme to access the coordinates as custom parameters, like this:

{{ if .Params.location_latitude }}
  <img src="https://example-mapping-service.com/?center={{ .Params.location_latitude }},{{ .Params.location_longitude}}" />
{{ end }}

The 4 available parameters are location_name, location_url, location_latitude, and location_longitude. The venue name is automatically prepended to post content so that no theme changes are necessary. I’d like to explore offering maps as a built-in feature in the future. Enjoy!

Years ago my wife and I were in Vegas and had a chance to see Elton John… and missed it. This year, when I realized he was playing in Toronto on the night of our 20th anniversary, I bought tickets as a surprise birthday gift and we planned a short trip around the concert.

We arrived in the late afternoon earlier this week, took the airport train to Union Station and the subway to our hotel, then went down to Polson Pier to catch the sunset. We had dinner and explored the Distillery District before checking out Jurassic Park for the Raptors game — too late, they had already closed it off — and settling for beers at the sports bar next door to watch the end of the game.

The next day we did a bike tour of the city. On the way to meet the guide, we wandered down a street to look at the trees and a woman said hi as she walked by. Realizing we were tourists, she stopped and told us that she had been friends with Jane Jacobs, who lived just a block away. There’s a sign outside her old house.

The bike tour was a great way to see a bunch of Toronto. Murals, CN Tower, trains at Roundhouse Park, sculptures at Ireland Park, the university, and several neighborhoods. We stopped for hot chocolate and then back on our own visited a couple libraries including the Sherlock Holmes room at the Toronto Reference Library.

Dinner in Little India and then the streetcar back for the concert. We loved it. Even with just a couple days we really got a lot out of visiting the city. Looking forward to coming back one day.

Garrett Dimon writes about removing all analytics from his web site and how little he misses it:

What over a decade of number-crunching analytics has taught me is that spending an hour writing, sharing, or helping someone is infinitely more valuable than spending that hour swimming through numbers. Moreover, trying to juice the numbers almost invariably divorces you from thinking about customers and understanding people.

We don’t have page-view stats on Micro.blog because they are incomplete without counting the Micro.blog timeline and feed readers, and I’d hate for someone to be discouraged when just getting started. Newsflash: your blog does not have a million readers. That’s okay! If you really want stats, you can add some custom JavaScript to include Google Analytics or Fathom Analytics, but most of the time it’s a distraction.

I love having everything together on manton.org. Whether it’s blog posts about tech, personal stuff, or photos, I don’t have to think too much about where to put it. If I’m writing on the internet, it goes on my blog.

But I’ve been wanting to experiment with sharing more location information too, and use that to try out location as a built-in Micro.blog feature, so I’ve created a new blog manton.coffee and imported my 2500 check-ins from Foursquare/Swarm representing about 8 years.

To build this, I upgraded Micro.blog to support venue names and location coordinates. We try to be very careful about privacy, and currently the apps do not fill any of this data in, but in the future it could be something people opt-in to for a post. The extra data is available to Hugo templates, which is how I’m including the little maps on the home page.

We’re working on some other features with higher priority than this, so consider this mostly a sneak peek for now. I’ll enable the Foursquare/Swarm import as an official feature after the glitches are worked out. Better integration with OwnYourSwarm should also be on the roadmap.

We’ve released a new version of our photo-blogging app Sunlit. Mostly a bunch of bug fixes, including these changes:

• Updated thumbnail previews in a new post to maintain the aspect ratio of the photo.
• Added an option in the Settings screen to clear cached photos and drafts from previous versions of Sunlit.
• Improved spacing of icons in tab bar.
• Fixed swipe left on a post to view the conversation.
• Fixed several other issues and potential crashes.

You can download Sunlit for free in the App Store.

I’ve removed the option for Facebook cross-posting on Micro.blog. Facebook recently disabled our API access, and my initial request for re-approval was denied. While I hope to eventually get it enabled again, I don’t want to have a feature on Micro.blog that is broken.

A year ago Facebook turned off API access for creating new posts unless they were sent to a Facebook page. I adapted Micro.blog to that change, but it already severely limited the usefulness of cross-posting to Facebook. At the time, Bridgy disabled all Facebook support:

Facebook’s moves to restrict its API to improve privacy and security are laudable, and arguably the right idea, but also mean that users can no longer use third party apps like Bridgy to create posts.

I hope that by officially saying goodbye to Facebook support we can focus on making the other cross-posting options in Micro.blog more robust. I’m currently looking into improving LinkedIn support, and we recently added Tumblr cross-posting to go along with Twitter, Medium, and Mastodon.

Facebook and even Instagram are at odds with the principles of the open web. I never want to remove a Micro.blog feature that users find valuable, but in this case we have little choice, and it’s best for Micro.blog to move on.

Yesterday we updated the iOS app for Micro.blog with several bug fixes and tweaks for iOS 13. Today I’m updating the macOS app with an important fix when running on macOS Catalina.

Here are the changes:

• Fixed post selection options popover on macOS Catalina.
• Updated for “notarization” to avoid launch warnings.

Along with macOS notarization, this release also now uses the “hardened runtime”. I thought this might break some features, but I haven’t noticed any problems. Choose “Check for Updates” in the app to get the latest version.

I’ve posted an update to Micro.blog for iOS with several bug fixes. Here are the changes in version 1.7.1:

• Updated a few more screens for Dark Mode on iOS 13.
• Fixed updating timeline when favoriting posts in Discover.
• Fixed alignment of popover when selecting a post.
• Fixed disabling cross-posting from post options screen.
• Fixed uploading videos to WordPress.

You can download it in the App Store.

There’s a new trailer out for Klaus, which hits select theaters and then Netflix in November. Amid Amidi at Cartoon Brew writes about director Sergio Pablos:

His goal hasn’t been to simply bring back 2d animation, but to push the craft forward, and Klaus’s distinct look is achieved via an innovative lighting and rendering pipeline that is applied to the drawn animation.

I’m excited for any hand-drawn feature film, especially one that comes from Sergio Pablos. Over the last few years his team has posted some early concepts and tests to their blog. I also mentioned Sergio on an episode of my podcast Timetable in 2017.

When Apple Arcade launched, I thought it would be fun to try a new game each day for 30 days. And it was fun! For… 18 days. On Saturday I sat down to play my 19th pick, Oceanhorn 2, and realized that playing a new game each day wasn’t working.

Unlike visiting 30 coffee shops, 30 libraries, and 30 parks — where each series of blog posts I explored Austin and got a lot out of it — playing video games has proven to be too big of a time commitment for me right now. I love video games and there are some great games in Apple Arcade, but if I’m on my phone for an hour I need to be using that time for something work-related. It was creating too much extra stress for too little return.

Oceanhorn 2 is also a good place to wrap up this experiment because it’s one of my favorites. It’s heavily inspired by Zelda. I’m going to enjoy playing it a little bit more over the next week or so. All the other games I’ve played are collected in this category on my blog.

Good luck to everyone participating in Inktober this month! We’ve added a special Micro.blog pin you can unlock by posting a photo of your drawing and the word “Inktober” somewhere in the post. To see your pins, click Account → View All next to the pins message.

If you’re drawing digitally, also check out these Inktober templates from Iconfactory for their iPad app Linea Sketch.

We posted episode 390 of Core Intuition. From the show notes:

Manton finds a workaround to his Sign in with Apple email problems! Daniel argues first that DTS should support pre-release software, and they discuss possible compromise approaches. Finally, they remark on Apple’s vigorous marketing push, and the thrill of promoting products we are proud of.

Only 10 more episodes to go before we hit 400!

As more Micro.blog bloggers use categories to organize their posts, I want to keep making categories more useful while retaining the simplicity of microblogging by default. Today we’ve added an option on the web (under the new “…” button when starting a new post) to choose categories right as the post is being created, as well as a new interface that can filter blog posts into categories based on the text in those posts.

For a while we’ve had a feature to automatically filter photo posts into a category. If you create a category called Photos or Photography, Micro.blog gives you this simple checkbox on the categories screen:

This is powered by filters that look for a match in the title or text of a post and then set a category for you automatically. These filters can now be managed from a new “Edit Filters” button on the categories screen on the web:

By default, filters are applied to new posts only. To also apply the filter to all posts, there’s a new “Run Filter” button. For blogs with thousands of posts, make sure to give Micro.blog a little time to update all your posts and publish them to your blog.

When we released Micro.blog 1.7 for iOS last week with Sign in with Apple support, Micro.blog could not actually send email to Apple’s private relay server. This is an issue that has popped up on the Apple developer forums and likely affects many developers. I was so excited for Sign in with Apple that I thought it was worth shipping anyway, crossing my fingers that we could resolve it shortly after iOS 13 was out.

Apple’s private email relay server is almost completely undocumented. In this blog post I’ll describe how I got it working.

The key issue is that the “return path” of your emails must be using a subdomain that can be verified by Apple. This blog post from SendGrid describes the solution in detail. I was happy to discover that I could customize this in the settings in Mandrill as well under Settings → Sending Defaults:

Here are the steps I took:

• Create a new subdomain. I decided to use mail.micro.blog. Set the TTL to just 1 minute, because you will need to change the DNS record multiple times during this process.
• Initially the subdomain should be a CNAME to your email provider. Mine was set to mandrill.com.
• Make sure you have SPF records for this new subdomain. Mandrill will walk you through this when you add a new subdomain under Settings → Domains → Tracking & Return Path Domains.
• Start registering the new subdomain in Apple’s developer portal. Apple will check the SPF records at this point. After you click Register, download the verification file.
• Create a new web site somewhere for your subdomain and update your DNS record to now point to that web host instead of Mandrill. The web site must support the latest encryption settings for HTTPS or it will mysteriously fail verification from Apple.
• I put the subdomain on GitHub Pages so I didn’t need to spin up a new server somewhere for it. If you use GitHub Pages, make sure to create .nojekyll file so that the .well-known folder that Apple needs isn’t skipped.
• Upload the apple-developer-domain-association.txt file from Apple to the new subdomain web site. Wait a few extra minutes to make sure the DNS has changed before clicking Verify at Apple.
• Also verify your root domain name and add the from email address you will be using to send email. Here’s what my settings look like when everything is working:

And finally:

• Change the DNS record for your new subdomain to point it back to mandrill.com.
• If any previous emails had already bounced, remove those from Mandrill’s blacklist under Settings → Rejection Lists so they will try to send again in the future.

As I type all of this out, I still can’t believe it’s so complicated. Apple should both document this and remove as much friction as possible, for example by allowing domain names to be verified by DNS records alone and providing much more detailed error messages when things go wrong.

I almost forgot to post to my blog for the 6th day of trying games on Apple Arcade. Remember those sliding block puzzles? The Enchanted World is that but set in a wonderful fantasy design where your character moves through the story using magic to set the world right.

I was going to stop my micro review there, but after I started playing the game I came across the story of the developer and designer who created it. Apple featured them in this newsroom blog post:

For creators and friends Ivan Ramadan and Amar Zubcevic, both 33, the game is much more than that: It’s a metaphor for a child growing up in a time of war. Both Ramadan and Zubcevic grew up in Sarajevo during the conflicts in the Balkans in the 1990s, and both had parents that used creativity to shield them from the violence and danger around them.

There’s also a longer feature on CNET about the developers.

Matt Mullenweg blogged that Automattic has received a Series D funding round of $300 million. He had some interesting comments in an interview with TechCrunch about how much they want to grow WordPress, comparing it to Android’s 85% market share and even going beyond that:

What we want to do is to become the operating system for the open web. We want every website, whether it’s e-commerce or anything to be powered by WordPress. And by doing so, we’ll make sure that the web can go back to being more open, more integrated and more user-centric than it would be if proprietary platforms become dominant.

I’ve long been inspired by Automattic. They were the best company to acquire Tumblr and they seem well-positioned to make a dent in the dominance of Facebook and Twitter. But also I’m thinking about one of the IndieWeb’s principles:

Plurality. With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.

WordPress is at 34% of web sites right now, and I can easily see it getting to 50%. Growing bigger than that might take away one of the beautiful things about the web: the diversity and flexibility to move between platforms. I’m rooting for Automattic to take market share away from the big social networks, but there should be a variety of tools available to build web sites, including platforms like Micro.blog.

We added Sign in with Apple to the next version of Micro.blog for iOS 13. It can be used to sign in to an existing Micro.blog account, or to create a brand new Micro.blog account right from iOS. It is the fastest way to start blogging.

Because Micro.blog doesn’t have passwords, in previous versions we had to send you an email to confirm signing in. With Sign in with Apple, we can skip this email verification and quickly sign you in with Touch ID or Face ID.

If you have an existing Micro.blog account and use Sign in with Apple with the same email address, you’ll be signed in to your current account. If you pick an email address that doesn’t match the email address used in Micro.blog, or if you choose Apple’s private email relay, Micro.blog will create a new account and start a hosted blog trial for you.

A few things to be aware of:

• You can have multiple email addresses associated with your Apple ID. When signing in, make sure to pick the one that is used by Micro.blog.
• If you accidentally create a new Micro.blog account, you’ll want to delete it so that you can sign in to your real account.
• Micro.blog cannot currently send email through Apple’s private relay service. I hope this will be resolved soon.

This update to Micro.blog ships on Thursday with iOS 13. If you’re already running iOS 13, you can try this update early by joining the TestFlight beta.

Last year after Twitter changed their streaming API so that apps like Twitterrific and Tweetbot could no longer use it, I blogged that I wanted to do everything I could to support third-party Micro.blog apps:

With that in mind, I’ve mentioned before that I’d like to offer a push notification service for developers. iOS and Android developers could upload their push notification credentials from Apple and Google. Micro.blog would store them and deliver push notifications directly to third-party apps.

That is now a reality. Today there’s a new beta of Gluon for Micro.blog that includes push notifications. Micro.blog sends the notifications on behalf of Gluon so developer Vincent Ritter doesn’t need to run his own server.

The other popular iOS app for Micro.blog is the open source Icro. I’ve added a comment to this Icro issue on GitHub with details on the new API. I’m looking forward to working with anyone building native apps for Micro.blog to enable push notifications for their app.

I can’t believe it’s been 2 years since Brent Simmons announced JSON Feed. In the first months after the spec was released there was a lot of activity on GitHub and interest from developers. The format has proven really useful in Micro.blog, in feed readers like Feedbin or Brent’s own NetNewsWire 5, and just to make it easier to build new web tools.

We’ve received some great feedback, and I’ve been reviewing a bunch of the issues on GitHub. There are a few things that we want to incorporate into the spec. I’ve posted a list of proposed changes over on GitHub.

Richard Williams passed away a couple of weeks ago. The day after, my family and I went to see the Animation Show of Shows at the Alamo Drafthouse. It was a wonderful collection of films — beautiful to experimental, funny or thoughtful, with a variety of different mediums.

But thinking about it now, none of the short films were really in the painstaking hand-drawn style of Richard Williams, who had incredibly high standards for what animation could be. He would embrace doing the work of drawing every frame, with few holds or shortcuts.

The films in the show weren’t trying to do that, and that’s fine. But I hope someone again picks up the depth and quality that Richard Williams brought to the industry. I blogged about him back in 2013, and I remain inspired today.

Blogs hosted on Micro.blog provide a lot of flexibility with custom CSS, themes, and Hugo templates. But if you are making major changes to the design of your blog, you may not want to do that live and risk breaking anything for your site visitors.

I often test out changes on a 2nd fake blog I created on Micro.blog. It’s like an extra sandbox that I can play in to edit templates without touching my real blog, and it’s useful enough that I want everyone else to be able to do the same thing.

Micro.blog now lets you create a free test blog for your account with a URL like username-test.micro.blog. There’s a button to create the test blog under Posts → Design → Edit Custom Themes. It will appear as a free 2nd blog on your account, and you can post to it, upload files, or try out custom themes.

Because custom themes on Micro.blog can be shared across multiple blogs, when you’re happy with any changes you’ve made in your new theme, you can assign the theme to your main blog and all those changes will be applied to both sites. I’ve also added a “duplicate” option that makes a new copy of the theme so you can edit templates in the duplicate theme on your test blog.

I’ve updated Micro.blog today to help Mastodon users follow people on Micro.blog. It used to be that if you clicked from Mastodon to a Micro.blog user, you just ended up their blog home page. Now it redirects to a special version of the Micro.blog profile screen which includes a follow form.

This is very similar to Mastodon’s default remote follow form, or Aaron Parecki’s profile page. For more about how to use your own blog’s domain name as your Mastodon-compatible username, see this Micro.blog help page about ActivityPub.

DHH blogs about giving a chance to smaller companies to help fix the problems with massive tech companies controlling so much of the web:

The world is full of alternatives to the Big Tech offerings that give you 95% of the utility for 0% of the regret. But if you can’t even be bothered to give up 5% to help an alternative along, you also can’t be surprised when the alternatives are so few and far between.

This is how I’ve been feeling about Instagram. I hear people complain about Facebook all the time. But then some of those same people turn around and post photos to Instagram instead of their own blog.

Complaining helps when the company listening cares about the same problems we do. For example, Apple and privacy. But the solution to massive social networks is already in our hands.

Curtis Herbert has a great blog post about starting an Android version of his app Slopes. Adding social features made it more compelling to support multiple platforms:

In any given group of friends the odds of a mix of both Android and iOS users is very high (not to mention Europe is a big potential market for me, and Android is much larger over there than in the states). If someone on iOS loves Slopes, but their friend group ends up using one of my competitors because it supports both platforms and therefore the entire group can join in on the in-app fun, that’s going to go poorly for Slopes.

What I find so interesting about this decision is that Curtis seems to be intentionally expanding the scope of Slopes. Everything he writes about with Android makes sense if you first assume that the social features will be an important selling point and grow the audience for the app. Other indie developers might instead choose to keep the app focused on iOS and solve a more narrow set of problems, and that’s fine too.

I’m thinking of my discussion with Daniel Jalkut on last week’s Core Intuition about whether we should try to change the world (which often means bigger apps and more platforms to reach the most people) or focus on just building an app that’s really good at what it does (but might not be revolutionary).

Micro.blog would benefit from an official Android version, so a lot of Curtis’s post resonated with me. Luckily the third-party app Dialog (and upcoming app Gluon) can help fill that void in Micro.blog in a way that isn’t possible with non-platform apps like Slopes.

Dialog is a full-featured Micro.blog app for Android. Jacky Alciné blogged about it today while thinking about Micro.blog and IndieWeb mobile apps:

I decided to look at the client landscape for micro.blog, the most mature social platform that’s built around IndieWeb principles. I defined maturity as a platform that allowed immediate on-boarding into the community, provided a very simple (no-explainer) interface on how to get started and made it easy to go beyond it. That level of support is something I want my suite of tools to have - and I’m still working on it.

Because Dialog is such a polished app and already open source, I wondered if it could be the foundation for additional IndieWeb-related features for Android users. The official repository with the source code for Dialog is on Gitlab here.

I’ve also copied it to the Micro.blog account on GitHub, in case it’s useful for any GitHub users to browse or fork the code there. Thanks again to Mike Haynes for Dialog and for making it available in Google Play, as well as open-sourcing it!

Congratulations to Brent Simmons and all the contributors of NetNewsWire for shipping version 5.0 today. Here’s Brent with the announcement:

This release took five years to make, and for four of those years it wasn’t even called NetNewsWire. It was just a year ago that I got the name NetNewsWire back from Black Pixel — and I thank them again for their wonderful generosity.

Each major new version of an app is an opportunity to refocus, and NetNewsWire 5.0 prioritizes all the right things: it’s fast, embraces the open web, and feels at home on the Mac. NetNewsWire 5.0 takes everything Brent learned from previous versions, but rebuilt from scratch with modern features like Feedbin syncing, Dark Mode, and JSON Feed support.

And for folks on Micro.blog, NetNewsWire 5.0 also includes a sharing option to start a new microblog post right from an article you’re reading in NetNewsWire. It’s a great way to quickly share links on your microblog.

I’ve decided to add Tumblr as a cross-posting service in Micro.blog. This means Micro.blog can take your blog posts and automatically copy them to a Tumblr blog.

I usually avoid adding blog hosting services to Micro.blog’s available cross-posting destinations. After all, if it’s a good blog host that I could recommend as your primary blog, why not just post everything there instead of using Micro.blog’s own blog hosting? But the more I’ve used Tumblr in the last couple of weeks, the more I think about Tumblr as a community first and a blog host second.

To add a Tumblr blog in Micro.blog, on the web click Account → “Edit Feeds & Cross-posting” → “Add Tumblr”.

In related news, I’ve removed the upload file size limit when importing a Tumblr blog archive to use Micro.blog hosting. If you have a Tumblr, Medium, or WordPress blog that you’d like to migrate to Micro.blog, click Posts → Import.

Twitter announced in a blog post that they have removed over 900 fake accounts spreading misinformation about the protests in Hong Kong:

This disclosure consists of 936 accounts originating from within the People’s Republic of China (PRC). Overall, these accounts were deliberately and specifically attempting to sow political discord in Hong Kong, including undermining the legitimacy and political positions of the protest movement on the ground. Based on our intensive investigations, we have reliable evidence to support that this is a coordinated state-backed operation.

I like that Twitter is being proactive and transparent about this. It’s especially remarkable that they notified a competitor, Facebook, about similar fake accounts on Facebook’s platform.

Unfortunately there’s a deeper problem here. It’s not just the fake accounts and misinformation, but the way that Twitter’s design can be exploited. It is too easy to piggyback on trending hashtags to gain exposure.

Maciej Cegłowski of Pinboard called attention to the promoted tweets:

Every day I go out and see stuff with my own eyes, and then I go to report it on Twitter and see promoted tweets saying the opposite of what I saw. Twitter is taking money from Chinese propaganda outfits and running these promoted tweets against the top Hong Kong protest hashtags

I wrote about this in 2018 when introducing Micro.blog’s emoji feature:

Hashtags and Twitter trends go together. They can be a powerful way to organize people and topics together across followers. But they can also be gamed, with troublemakers using popular hashtags to hijack your search results for their own promotion or unrelated ranting.

We’ve expanded search and discovery in Micro.blog slowly for this reason. While Micro.blog is certainly too small to attract the attention of state-run propaganda, there has been spam going through Micro.blog that no one else sees. I’m convinced that limited search, no trends, and active curation are the right foundation so we don’t end up with a design that creates problems when Micro.blog does get bigger.

In all the Mac and iOS software I’ve worked on over the years, I don’t think I’ve ever had a new release ready as soon as Apple shipped their major updates to macOS or iOS. The timing just never works out, so I update a couple of weeks or months later. For iOS 13, I’m finally ahead of the game.

I just updated the beta of Micro.blog for iOS with a couple fixes, especially for dark mode on iOS 13. There’s more to do, but I feel really good about being able to have this ready.

If you’re running the beta of iOS 13, you can sign up for the Micro.blog beta here. Thanks for testing!

I’m excited to see where Automattic takes Tumblr, but even today there are already several Tumblr-related features built in to Micro.blog. Here are a few ways that Micro.blog can integrate with Tumblr.

Follow Tumblr users on Micro.blog: Micro.blog tries to play nicely with the rest of the web, so you aren’t limited to just following Micro.blog users. To follow someone’s Tumblr blog, on Micro.blog click Discover, then click the search icon, and enter their Tumblr domain name:

Click on the Tumblr user to preview their posts and follow them. Now when they post to their blog, those posts from Tumblr will appear in the Micro.blog timeline. Short posts, photo posts, and art from Tumblr look great in Micro.blog.

Add your Tumblr feed to Micro.blog: If you actively post to Tumblr and also have a Micro.blog account, you can add your Tumblr RSS feed to Micro.blog so that when someone follows you on Micro.blog, they see posts from both your main microblog and your Tumblr blog.

Click Account → Edit Feeds & Cross-posting, then paste in your Tumblr RSS feed:

Import your Tumblr blog to Micro.blog: Maybe you no longer maintain your Tumblr blog and want to move your old posts over to Micro.blog. First, export your posts from the Tumblr dashboard. That will give you a .zip file you can import into Micro.blog under Posts → Import.

Thanks to the “on this day” feature that Jonathan LaCour built for Micro.blog-hosted blogs, I noticed that 7 years ago yesterday I blogged about App.net reaching their funding goal. I still get asked about App.net sometimes. It is easy to look back on something that didn’t last and pick it apart. I’d rather look at the good things that came out of App.net.

When it was shutting down, I blogged my thanks to the App.net community:

I wrote in 2013 that it was not just a Twitter clone but an amplifier for applications that couldn’t be built before. It came along at the right time, took off, and then faded. The App.net founders deserve significant credit and thanks for trying something risky and succeeding to grow a community that lasted so long.

There is a guiding principle in Micro.blog that differentiates it from nearly every other platform. It’s not only about creating an alternative social network. The foundation is around blogs and IndieWeb standards because that’s part of unrolling the damage caused by massive silos.

Micro.blog is also designed around blogs because it gives immediate value to the platform, insulating it against the network effect that drives the success or failure of most other social networks: not all your friends are there yet. Unlike ad-supported platforms, Micro.blog aligns its business model with customer needs. Subscriptions for blog hosting let us deliver the best features we can, and also help support the rest of the platform.

Brent Simmons really said it best:

Micro.blog is not an alternative silo: instead, it’s what you build when you believe that the web itself is the great social network.

I often look back at this quote to help guide me as I evaluate the direction of Micro.blog. I believe that Micro.blog is the first platform of its kind. The closest competition might be Tumblr, acquired yesterday by Automattic.

Of course it was coincidence that Automattic acquired Tumblr pretty much exactly 7 years after App.net was funded. No one is paying attention to those dates. And yet, now that I’ve noticed it, there’s a kind of symbolism to it. Tumblr is effectively being re-funded.

Like Micro.blog, Tumblr is about making blogging easier. Like Micro.blog, Tumblr allows custom domain names for your blog, something no other major social network allows. Unlike Micro.blog, however, Tumblr’s community is only Tumblr blogs. Micro.blog’s community brings together not just Micro.blog-hosted blogs, but people using WordPress, Mastodon, or home-grown IndieWeb solutions.

Matt Mullenweg and the Automattic team have a bunch of work ahead of them to integrate Tumblr into the WordPress ecosystem. I don’t know how that’s going to play out, but I know that preserving all the Tumblr blogs and giving them new life is a good thing.

I wonder if Micro.blog and Automattic are on parallel tracks. Two companies wildly different in size and scope, but we can all learn from platforms that have come and gone, finding our own path to a shared vision of the future that embraces content ownership, supports healthy communities, and deemphasizes massive social networks. I’m wishing the team at Automattic the best.

Micro.blog is not a popularity contest. We don’t have follower counts or public likes because we think those numbers have overshadowed more important aspects of blogging, like the quality of writing and engagement within the community. But we do hear from podcasters using Micro.blog who hope to one day have sponsors for their podcast, and so they do need to know approximately how many listeners they have.

Today we’ve added a setting to enable basic MP3 download counts if you’re hosting your podcast on Micro.blog. It is off by default. It’s likely that most podcasts — especially podcasts that are just getting started — do not have many listeners, and that’s fine! If you don’t plan to have sponsors for your podcast, you can ignore this setting.

It takes time to build an audience. Don’t get discouraged. There’s value in telling your story whether it reaches 5 people or 500. I love recording my microcast Timetable because it helps me think through things I’m working on and share that process with anyone who is interested in Micro.blog.

There aren’t any fancy graphs for this feature. Just a download number for each episode under Posts on the web, next to the “Edit” and “Delete” buttons. You can enable it with a checkbox from Posts → Design. Micro.blog is not tracking the downloads until you enable it, and it doesn’t count you viewing your own podcast, so initially there won’t be anything to see until your podcast feed is refreshed and your MP3s are downloaded again.

With this setting enabled, Micro.blog modifies your podcast feed to use different MP3 download URLs. It may take some time before the new URLs make it to all your listeners.

Micro.blog’s download tracking does not closely follow the IAB guidelines yet. It is intended as a rough estimate. I’ll be working toward IAB compliance in the future.

Happy podcasting! Let me know if you have any feedback.

When I started reading Ruined by Design, my first thought was that I had missed the window for writing my own book, Indie Microblogging, because Mike Monteiro was making all the same points that I was writing about. Luckily that wasn’t the case. Mike does cover some of the problems with social networks, but most of the book is focused on how designers can think about their work. I recommend it. (And it’s just as important for programmers and everyone else who is contributing to a product.)

Mike was also a guest on today’s episode of Presentable with Jeff Veen. I finished the book last month, so the podcast was a nice recap of a few of the main ideas and stories from the book.

I love photo blogs. Last year, Jonathan LaCour wrote Microgram to allow anyone on Micro.blog to paste in a little JavaScript on their blog to show a grid of photo thumbnails. This has been a really popular add-on for Micro.blog — thanks Jonathan! — but we knew we’d eventually need this as a built-in feature.

Today I’ve added a new page for photos so that new blogs hosted on Micro.blog get something that works out of the box without JavaScript. We’re starting with a simple grid of photo thumbnails similar to Microgram, each linking to the microblog post, and I’d like to expand it with more options in the future.

It uses CSS Grid Layout, so you can also customize a bunch of things without changing the template. For example, to change it to 5 equally-spaced columns, click Posts → Design → Edit CSS and paste in:

.photos-grid-container {
  	grid-template-columns: 20% 20% 20% 20% 20% !important;
}

This new photos page is created automatically for any new blogs on Micro.blog going forward. If you already have a page called “Photos” and want to switch to using the new page, you can delete the page you created manually. Micro.blog will then show a “New Photos Page” button to create one of these new pages for you. (You can also rename or re-order the page.)

Apple this week rolled out an updated list of categories for their podcast directory. Some old categories were removed and new categories added. It’s a better fit for what the podcasting world looks like now.

If you have a podcast hosted on Micro.blog, I’ve updated Micro.blog today with the new categories. On the web, click Posts → Design to see the new list. (Your current category will continue to be used until you update your podcast settings.)

Thinking about starting a podcast? Micro.blog podcasting is $10/month and also includes a full blog and video hosting.

I wanted to highlight 2 new blog posts from the Micro.blog community about customizing themes. Because Micro.blog uses Hugo templates, there’s flexibility to change the design or even override our default feeds.

• Chet Collins used a custom theme to change his podcast feed to use different artwork.
• Ricky de Laveaga updated the Hello theme with some CSS tweaks including improvements for dark mode.

As Micro.blog matures, it’s important that we keep the default interface as streamlined as possible. It should be as easy as tweeting to start your first blog post. But I love that there’s a lot of power under-the-hood for people who want to tinker with it.

Micro.blog makes it really easy to post some text and a photo to your blog, but sometimes you want a longer post that includes multiple photos. Because Micro.blog puts all the photos at the end of your post by default, I’ve noticed some people looking for an easier way to draft longer posts.

I’ve added a new “Copy HTML” button next to photos on the Uploads screen in Micro.blog. Using this button, you can first upload multiple photos, then copy and paste the right HTML reference into your blog post draft wherever you want. Happy photo-blogging!

Jason Snell has a post for Macworld reacting to the news that Apple plans to fund original podcasts:

The great thing about podcasts—and I say this as both a listener and a creator of podcasts—is that it is, like the web, a free and open ecosystem for content. You can listen to any podcast in any podcast player. If Apple creates podcasts that can only be listened to in Apple’s own app, it is furthering a potential future where your favorite shows are scattered across multiple services and siloed in different apps.

No one is too alarmed by this Apple rumor, because maybe nothing will come of it. But a good way to think about it is to imagine if the popularity of Apple and Spotify were reversed. Imagine if Spotify was the one with 60% of the podcast app market and then they decided to release Spotify-only exclusive “podcasts”. It would be an obvious threat to the openness of podcasts.

I wish I could give Apple the benefit of the doubt on this, but the risks are too great. Apple has more power than any other company over the podcast ecosystem. Just because they haven’t interfered with anything so far doesn’t mean they can’t still ruin what we’ve got.

I want to give everyone a heads-up about a change we’re making next week. When Micro.blog launched, it was really important to me that the service was as affordable as possible. Because of that, there were options to use it for free with an external blog, use it with the $2/month cross-posting, or have Micro.blog host your blog for $5/month. We later added podcasting and video hosting for $10/month.

As Micro.blog has improved, I think our blog hosting has become a great value. The price of the $5 subscription won’t change. But the $2 subscription introduces a lot of confusion. It’s priced per domain name, and it’s not obvious when or how to switch between the different plans. It also adds a lot of complexity on the backend to manage all the possible subscriptions.

To fix this, we’re removing the $2 plan and updating the $5 blog hosting to also include cross-posting from any domain name. If you’re only using the $2 cross-posting, don’t worry. We will switch you to the new plan but apply a $3 monthly credit to your account indefinitely, effectively keeping your original pricing.

Pricing Micro.blog has always been interesting because it needs to appeal to people who just want a new social network (usually $0/month) but also to people who want a great blog host (often $20/month). I think these changes keep the right balance to accommodate the different needs that people have with Micro.blog, while making it simpler for new users. Thanks for your support!

Last year after IndieWeb Summit in Portland, I sat down with IndieWeb co-founders Tantek Çelik and Aaron Parecki to talk about the history of IndieWebCamp for my upcoming book, Indie Microblogging. Only part of the interview will fit in the book, so I’m including a full transcript of our conversation below and on GitHub, where I’ll be incorporating any edits and also publishing future chapter drafts.

Manton: Take me back to 2011: the founding of IndieWebCamp. What did that feel like? How you all got together. How the first IndieWebCamp got started.

Tantek: You weren’t at the Federated Social Web Summit in 2010, were you? Did you hear about it? Did it even cross your radar?

Manton: I assume it did. But that’s already been a while.

Aaron: Nine years ago…

Tantek: Because I think that’s where the inspiration originally came from.

Aaron: So 2010 was the Federated Social Web Summit — in Portland — and that was the invite-only but “you could kind of ask for an invite”-style event.

Tantek: Which we now know greatly biases towards people that feel privileged enough to ask for an invite, so it’s sort of a bad way to do it. I didn’t even put that together until the last year. Yeah, don’t do that kind of private conference.

Aaron: So I ended up there, Tantek, as well as a bunch of others. It was a fun group, but the thing that we took out of it was that the focus seemed to be on people building things for other people, building specifically platforms. They were coming with platforms and trying to make them work together. Which is a fine goal, but that wasn’t my personal interest in it necessarily. So it was more like, “oh, I have this Buddycloud thing, let’s make it work with Friendica”. Or Diaspora was there.

Tantek: The Diaspora 4 were there, which was cool. That’s where I really got to spend time with them.

Aaron: And there was also a lot of solving problems in theory without actually testing them out or building something first. And a couple of pretty in the weeds discussions that I ended up sitting in on and was like, “this is really complicated”. I feel like there is a better solution. That was where SWAT0 the concept was formed as well, right? Interoperability tests between social networks — can someone post a photo of somebody else using a different system be notified that they were tagged in a photo and then a third person comment on the photo and have that comment notification appear on the person who favorited it. Everybody has to be using different software for that test to pass. SWAT0: social web acid test.

Tantek: It was actually really hard.

Aaron: Very hard. It still is.

Tantek: As far as we could tell no one actually got it to work across different sites.

Aaron: The goal with SWAT0 was to have three different systems interoperating. Several people claimed that they supported everything needed for SWAT0 themselves. But by definition that doesn’t solve SWAT0 because you need three different implementations. So there were several people who were like, “I can be every person in this — every role in this test”. But then there’s no one to test it with, because only one person would do that at a time. And we are still kind of in that situation sadly. It’s still a very hard problem. We did in 2015 have a demo of it working between three different recommendations, although each implementation only was able to be one or two of the roles of the three.

Manton: And that was using Webmention?

Aaron: Yeah, exactly.

Manton: So back in 2002 what was the technology to.. It was way after Pingbacks and Trackbacks.

Aaron: Yeah, the thought was the OStatus stack. Atom. Salmon for the responses.

Tantek: PubSubHubbub, I think.

Aaron: I believe so, yeah. For finding the photo in the first place.

Tantek: But Salmon for the notification.

Aaron: Salmon for the notification of the comment. But in order for someone to see it in the first place they would be following an Atom feed, probably, with PubSubHubbub.

Manton: And so now Salmon is making a comeback with Mastodon, right?

Aaron: No, it’s already done.

Manton: It did briefly make a comeback and then got replaced.

Aaron: Mastodon ripped out their whole code and replaced it with ActivityPub. So after that event we were like, “okay, that was cool, but we want to focus on people being more empowered individually to participate in this federated network.”

Tantek: Everyone got to give lightning talks. That was part of it.

Aaron: Yeah, yeah.

Tantek: Which was great. About any topic, like why they were there and… What was your lightning talk on?

Aaron: Probably location stuff, because I was just starting geolocate at the time. But the sense I got was that the assumption was that in order to participate in a federated social network, you have to be on a platform that supports the protocols. The only way to do that was that if someone built the platform that interoperates with other platforms, and then you as an individual join one of those platforms. There was no “just my web site”.

Tantek: Or one-person platform.

Aaron: Or single-person platforms was like: why would you do that? That was the feeling there. That was why we did IndieWebCamp the year after, because we wanted to approach it from the grassroots of: someone should be able to take their web site and be able to use their web site to participate in the same distributed social network — federated social network.

Manton: As the conference was wrapping up, did you have a feeling that y’all would probably do IndieWebCamp, or was it making friends and catching up with people.

Tantek: We were mostly catching up with people, meeting new people. I was just looking at my notes, because I actually put my entire talk from it on their wiki because it’s like that’s how it’ll survive. Turns out wikis are more persistent than PowerPoint.

Manton: So in that time… 2010 is actually a really interesting time because Twitter had been around for a few years and really gained a lot of steam, and actually a lot of early bloggers — who were blogging all the time in the early days — around 2010-ish they dropped off. They started just doing Twitter.

Tantek: Even just 2009…

Manton: Twitter satisfied that “I’m going to post something”. And you can see that. I went back recently and looked at a bunch of people that were doing blogging software. Founders of Blogger, Movable Type, and Six Apart people. And very few of them kept their blog through that period. So could you sense that at the time?

Tantek: Totally. Just even personally, the last blog post I wrote on my old blog was in August of 2008. I did not have anything on my own site in 2009. 2009 was a really weird transitional period, because I both saw that happening and I saw it happening to myself. And then the other thing that happened simultaneously — which I think helped — is that Twitter was really unreliable in 2009. We all switched to Twitter and then it got really unreliable. It was so frustrating.

Tantek: First of all I’m embarrassed that I’m not posting to my own site anymore, and then I’m frustrated because this damn tool is never up. And that’s really where I came up with the idea of, well, I should post to my own site and if I could set up a system where I can always just post to my own site, whether or not Twitter was down, then I can just have my site post to Twitter when it comes back up. And I can abstract away that frustration of their site being down. Abstract away their unreliability, while still getting that participation with friends thing. So 2009 is when I started working on what’s now my web site. Launched in 2010. January 1st, I’m like: from now on everything is going on my site first.

Tantek: And then the Federated Social Web Summit happened and I was like, “woah, okay”. But the platform perspective that Aaron was pointing out. Wait a minute, you don’t need to use a whole platform. Everyone can do this themselves. So that was my lightning talk, basically, and it even ended with… I’ll show you the summary: use your own site as your identity; publish on your own site; and then syndicate with PubSubHubbub. That’s still true.

Manton: And the first one, importantly… The very first principle of the IndieWeb principles is that. Use your own site, own your own content. Domain names are a big part of that. Really the biggest thing. Unfortunately domain names have not changed since 2010. They haven’t changed since 2000. It’s interesting that something so important, that “step one” is still really confusing to people.

Aaron: Yeah.

Tantek: Oh, that’s you’re going with that. I thought you were going with like, “they’re still around”.

Aaron: And it’s still just as hard.

Manton: I’m going with: why aren’t they easier? Because a lot of what the IndieWeb does, if you look at Microformats and Micropub and all these core parts of the IndieWeb, they’re built on HTML and HTTP where we have some control over making things easier and having other standards.

Tantek: Yes.

Manton: Is there hope for making DNS also easier for people, or are we just kind of stuck with this for a while?

Tantek: The irony is I don’t know what you’re comparing it to. Look at the amount of time it takes you and the form you have to fill out to get a new phone number. I would challenge you to do an A/B test. How long it takes to get a new phone number from scratch, not having a phone number, to how long it takes to getting a new domain name. And I would bet that it’s actually fewer steps to buy a new domain name. So I definitely sympathize that it could be easier to buy a domain name, but compare it to other forms of identity that people take for granted. It is less work to do. Or maybe the hard part is picking a domain name.

Aaron: Yeah, that’s part of it. A phone number just gets assigned to you.

Manton: And everybody kind of knows how phone numbers work, I guess. No one’s surprise that there’s a 3-digit area code, and a 3-digit number, and a 4-digit… Whereas with domain names there’s certain things (and IP addresses) that people are surprised by.

Aaron: Getting the domain is the first step. But then once you have it you have to know that you now need to set up DNS on it and point it at a hosting provider. And that’s the part that’s different from a phone number. Because once you have a phone number, it almost certainly came with a phone. You don’t buy a phone number and then assign it to a phone. You do that all as one step.

Tantek: It turned out that the equivalent of phone number registrars, all cell phones… It would be as if every domain name registrar — and a lot of them do now — sell hosting. So right off the bat, they’re like, “here’s a domain name, do you want us to flip on a simple web site for you?” A lot of them do that. That has changed.

Aaron: Yeah. That’s true, actually. That has gotten better. It used to be that GoDaddy or Name.com or NameCheap only did domain names. And then they all started adding hosting plans to their product.

Tantek: Which makes sense.

Aaron: It absolutely makes sense. And when you use the hosting plan provided by the registrar it is actually very easy, because it is more like you just go there, type in the domain you want, pay, and then now you have the empty shell to put stuff on. Doing something with the empty shell of a hosting plan is another step, but at least they do make the DNS to hosting step combined into one.

Tantek: Other hosting providers have made it easier to one-key turn on WordPress, turn on Known. I don’t know there’s a domain name registrar that also has easy hosting that also has a simple turn on a web site CMS.

Aaron: DreamHost does a pretty good job of it.

Tantek: That’s true. DreamHost probably has the most pieces that they’ve put together. And they were the first to do LetsEncrypt automation. Domain name, security, hosting. So that’s evolved. It’s very impressive to watch, even during the whole eight years of IndieWebCamp.

Manton: And comparing it to the phone numbers, if you go get a phone from someone they can always give you a phone number — if you go to Verizon or AT&T. And maybe where we need to be eventually with the web is that any place you can go get a web site can give you a domain name, which is not really true right now. The big companies can, but a smaller webhost can’t necessarily.

Aaron: You can, but it’s more work as a service provider. There’s plenty of domain resellers. I built a system to do that at one point, where we wanted to be able to offer domains as part of the product we were offering. So I found a domain reseller that had an API and hooked it all up. You would come to us and click the button for, “I want this web site with this theme.” It worked seamlessly.

Tantek: Even GitHub should it doing that, right?

Aaron: Right, for GitHub Pages. Instead of just offering GitHub Pages and being able to map a domain to it, why shouldn’t they offer their own domain registration.

Tantek: And make a little money. There’s incentive there.

Aaron: It would be a no brainer for Micro.blog to offer that feature. Sign up for the Micro.blog account, then right there type in what domain you want and it just works.

Manton: I’d love to do that.

Tantek: It’s also the kind of thing you could always add. “Yeah, now I’m ready for a domain name.”

Aaron: Yeah, you upgrade your subdomain to a real domain.

Manton: So you had mentioned with the changes in the last seven years… Going back to that first IndieWebCamp. We’re just wrapping up IndieWeb Summit 2018. Does it feel the same in terms of the community and what people are excited about? Obviously standards and everything else have evolved.

Aaron: The biggest shift in that context that I’ve seen between the original ones, specifically, although even from 2014 to now. Now we actually have a lot more stuff working together than we did in 2011, obviously, and even in 2014. At the beginning it was the same goal, the same ideals, but we couldn’t demo me commenting on someone’s post. That didn’t work until way later. And because of that the sessions were all drastically different, because there wasn’t a thing to coalesce around except for the ideals of own your data, have a domain name, do stuff on your web site.

Aaron: So if you go back and look the original sessions from 2011 to 2014, it’s a wide variety of things. Now at IndieWebCamps you end up with a lot of people who are coming to it and then become aware that there are things that work and then want to learn how to do those things. Now at the beginning of the second day we have the intro to the building blocks session. What is IndieAuth. Get Webmention working. Even in some of the IndieWebCamps there will be a whole track of unconference sessions about those building blocks for the whole day, where it’s people who know they want to learn these things that already exist.

Tantek: You had a session called “own your phone number”.

Aaron: That’s right. Yeah, I have actually kept that up. My phone number and my cell phone are completely disconnected. They’re not coupled. So my phone number is provided by Google Voice and I forward it to a phone number that I don’t know that my cell plan is on. I have no idea what my phone number is — the one on my phone. And I give out my Google Voice number as my identity.

Manton: When was that talk?

Aaron: That was 2011.

Tantek: The talks were so varied back then. We were just figuring out so many basics that a lot of the talks were very exploratory. We figured out some things like, “okay, I figured out how to syndicate into Buzz and Twitter, how about other places?” Then there was advocacy for plain text formats and there was a BitTorrent session.

Aaron: Yeah, I think that’s the biggest shift I’ve seen is that there’s so much more stuff that’s actually working now that’s functional. And it means that people are coming and wanting to learn that. And of course there’s still the experimental stuff. There was a good set of experimental sessions at this event. But there’s a lot more of: we have stuff working now that you can figure out and learn how to use.

Manton: There are two things, too. There’s all the IndieWeb-friendly formats and protocols are much more mature and established now, so that you could talk about the building blocks as a real thing. But then there’s also… It seems like the software is much further along. A bunch of people will come to the IndieWeb and they use WordPress, because WordPress powers 30% of the internet and it’s super popular. But there’s still a pretty good mix in the demo sessions and what people are hacking on of WordPress stuff and also “no, I rolled my own”.

Tantek: Yeah, in fact lots more rolled their own, which is not representative I think of people out there in general.

Manton: What do you think about the fact that WordPress is a very dominant platform. Is that good because there’s an agreed thing there everyone can use the same plugins, or are there any drawbacks?

Aaron: WordPress specifically because it’s self-hostable, that benefit ends up overriding some of the other drawbacks of that kind of approach. The danger with something being so dominant.. It’s the monoculture problem. We don’t want to be in a situation where we just have WordPress instances talking to each other. That doesn’t actually solve the problem.

Tantek: Or just have Mastodon talking to each other.

Aaron: Just Mastodon or just Diaspora or whatever, right. That’s the danger. That’s the thing we’re trying to avoid.

Tantek: Because that has lots of even worse consequences.

Aaron: Yes, exactly. And even when it’s a friendly company like WordPress that’s behind it, it doesn’t matter — the same problems.

Manton: You start to build like platform-specific… It’s different than just building for the web in general where anybody can bring their own site and plug in. With Mastodon specifically, it’s based on open standards but it also feels very opaque in a way — how stuff talks to each other. It’s a little more difficult to just build a web site and be compatible.

Tantek: It’s also levels of barriers to entry. Because that’s one thing that myself and I think a bunch of people at the 2010 Social Federated Web Summit we’re frustrated with was a lot of the standards being tossed around — every generation has its own standards — were really hard, like Salmon. I tried to read through the spec and understand what it was doing, and I could not wrap my head around enough of it to even start anywhere coding.

Aaron: I had the same experience at that event. I even then later, a year ago, tried to revisit the spec because Mastodon was using it. I feel like I should be able to have my web site just be a part of this network. I refuse to make a new Mastodon account and treat it as a POSSE destination because that completely defeats the purpose of what Mastodon itself is even shooting for, which is an actually distributed social experience.

Aaron: So I was like, “okay, it can’t be that hard now”. Certainly things have gotten better, and I should be able to just take my web site and add the stuff it needs. I still can’t figure it out. And then they went and dropped Salmon anyway and switched to ActivityPub, so I’m glad I didn’t spend my time on that.

Tantek: It turns out that the difficulty of the standard to implement makes a big difference. Because if it’s super difficult then you end up with only a handful — maybe even just one or two people on the planet — that can implement it, and then you get monoculture by default. In effect, not by design. One of the things we realized was that the antidote to that is to make the standards as simple as possible. Literally as dumb and simple, and frankly decomposed. So that’s where we came up with the building blocks idea rather than having a stack. And the idea that building blocks is you pick and choose the ones that you need for your use cases. That doesn’t mean you’re committed to implementing a layer after layer after layer to get to a certain point.

Tantek: That was a big insight. The more accessible the standards are for any developer to build their own solution. That means that the more they’re going to get exercised, the more that they’ll get good interoperability, the more that they’ll be a community around it. Because that’s really what it came down to.

Tantek: I think that’s kind of where the IndieWeb community started to form — started to really grow and gain critical mass — is the growing number of people that were like, “oh, I can implement that on my web site in an hour or less.” And then in a day they could do amazing things.

Aaron: And it’s demonstrated by the fact that like you look at the RSVP list on the event page, there’s like over 20 people who have been able to have their picture show up on the RSVP list, which works by having them publish a page on their own website and send a Webmention to the event page. That’s pretty cool. They didn’t have to go and read through a whole spec that talks about everything from using an app to publish to your site to then have a federation protocol behind it. They just need to know about this much of the whole picture in order to have that work. And that’s a quicker win. Now maybe you expand and start working on the rest of the building blocks.

Manton: Webmention is a great example of something that is as simple as it possibly can be. Can’t really get that down any simpler. So people get it. Microformats is similar in that it’s very approachable and transparent. If you know HTML you can figure out how to do that. You have Microformats 1 and 2, and remind me… Because Microformats predates…

Tantek: …IndieWeb. 2005.

Manton: And did that launch at SXSW or something like that?

Tantek: Shortly thereafter. I think we had sessions about it at SXSW in 2005, in March. The site launched in June itself. Until then we had just been doing it on the Technorati wiki. And my co-founder of the Microformats.org community, Rohit Khare. He’s like, “hey, happy birthday, I bought you a domain name.” And I was like, “really, you think this is worth having its own domain name?” That was my actual response.

Aaron: Wow.

Tantek: Because it seemed like such a simple stupid dumb thing. And he’s like, “yeah.” Okay, I guess we should do this then, and then we set up the site and well, what do you need on a community site. You need a mailing list, you need a blog, you need a wiki. So we set all those up. Since then we’ve learned that the primary ways of actually making progress are the wiki and IRC channel (or Slack) — an archived IRC channel. But that was definitely a response to, again, complexity. Like the whole RDF world — all that insanity — and the Atom/RSS wars back in the day, and then Atom going to IETF instead of W3C because there was a giant fear that it would just be turned into RDF at W3C. That’s how Microformats 1 started.

Tantek: We basically did make it look as dumb as possible. Let’s just take the names of the terms from the vCard spec and use them as class names. That was what I proposed in 2004 at FooCamp. And I ran it by Ray Ozzie at the time, who was like architect at Microsoft or something, but also just from Lotus Notes, you know he has a long history. He’s like, “yeah, that could work.”

Manton: So now we’re almost 15 years since then. Looking forward, there’s a lot of talk about generations — 1, 2, 3, 4 — moving up and making it more approachable and just easier for people to use. Obviously we can’t predict 15 years from now. Who knows what’s going to be around. Is Twitter going to look the same, are blogs going to be the same…

Tantek: Is Twitter going to be around?

Manton: Exactly. There’re no guarantees. A lot of people… So much time, they don’t remember before Twitter and Facebook and so it’s hard to imagine sometimes that those things could go away. But they could. They’re just web sites. Businesses built by people that make mistakes and do good things sometimes.

Tantek: Yeah, sites that become boring and people move on to what’s interesting. I think Facebook really extended their lifespan by buying Instagram.

Manton: So moving forward, how soon… Because I’m kind of impatient and I want everybody to blog on their site immediately, like tomorrow, and for it to be easy to use. But this stuff takes time.

Tantek: Totally.

Manton: Where do y’all see just over the next few years. How close are we to making this more mainstream or is this going to be just more time churning away building tools, trying to spread awareness.

Tantek: It’s kind of hard to predict. I do feel like we’re entering a new phase right now. I think we’ve had two phases, two very long phases of the IndieWeb community so far. One was this I almost want to say like Big Bang phase in the very beginning where there were all these different things coming out. People trying all kinds of different approaches, like Ward Cunningham did his federated wiki project. He figured out a way to do all this Javascript-based wiki federation thing that he loved. And other approaches. But then we started to coalesce around: use your own site, use Microformats. We actually used Pingback for a while until Sandeep Shetty showed up and he’s like, “hey, I’ve got this proposal for a simpler version called Webmention that does this.” And everyone in the community was like, “well, that completely aligns with our values of making things simpler.” So we instantly adopted it even though none of us knew who this guy was. And then we just ran with it.

Tantek: So the first four years was this explosion of getting basics working. We got RSVPs and events working by 2013. And that was kind of like, “whoa, we federate events and RSVPs,” which we were always looking for ways that in the actual things we do, how can we use the technology that we’re making. And after that, clearly we need to get these standards — that are barely specified — solid, testable, working, dependable, to reach the next level of stability.

Tantek: And then there was the second phase which was the work of making all these standards formal and reliable and secure and handling edge cases. We did that from I would say 2014 through 2017, and a lot of that was done in the social web working group that I was co-chair and Aaron was in, edited a bunch of the documents. Evan Prodromou was also co-chair, from StatusNet. But that was kind of a maturing phase. There were a lot of new features people were figuring out all the time, and new infrastructure like Bridgy during that phase.

Tantek: But I feel like a big part of that second phase was everything that was getting built was getting fed back into fixing the standards. People would build something, they would get to the point where they were like, “hey, this didn’t quite work, we have to fix a standard to handle that.” Okay, we fix it. They get it working. We have test suites for all these standards. And now when people are implementing things like Webmention or Micropub or whatever they’re not really running into new problems. What they’re running into is questions of how, not “this doesn’t work”. So we’ve reached this level — and I think Microsub, that might be one of the last pieces that kind of wraps it up. That’s why I feel like we’re closing on the second phase.

Aaron: And IndieAuth, too, because that was only written as a spec this year. Before that it was actually very interoperable, and there were several implementations before, but it was never written down as a proper spec. So that’s now this process of let’s formalize that.

Tantek: And we even formalized how do we update the Microformats parser spec and the vocabulary. That’s been much more formalized as well. So people have an idea that when I proposed something, when can I depend on something vs. what’s experimental, and then what’s the path.

Aaron: So you mentioned these two phases of…

Tantek: The Big Bang, the amazing explosion of cool stuff and then this sort of maturing of the standards to make stuff work reliably even just amongst theirselves. You mentioned you want everyone to have their own presence. But when I think about that I think, “people want things that are reliable, that just work.” And I think this second phase was us doing the difficult plumbing work of the details to make things just work.

Aaron: That leads into what I think is the next phase is getting more people building systems using these building blocks. When that happens, and you’re a great example of this…

Tantek: Yeah, there’s an overlap. I think Micro.blog was evidence that that phase was ready to enter.

Aaron: So now as someone who is building out a platform that is intended for end users… Whereas I’m building my web site. I do not want an end user to use that software. It is not the goal explicitly. But you’re building software that is intended for end users. You now have a pattern to follow where if someone else comes along with the same goal and build something, they work together. And so I think in order to reach the goal of people can just use this stuff out of the box, we need more people building tools that are intended to work out of the box for people on the same stacks. And four years ago, if you had come around and started this thing, there wasn’t a pattern to follow to make that work across implementations. And there is now, because of the work over the last four years, since 2014, of formalizing these specs, and having that actually hardened.

Tantek: And we also did it the hard way.

Aaron: Totally.

Tantek: We tried to do each spec as its own little building block piece. I would say hard but honestly I think greater chance of long-term success. The traditional approach that architects take is the stack approach or platform approach where they figure out the entire API. The whole thing. If you look at how OStatus happened, or even like ActivityStreams and ActivityPub. That’s very much a “we’re going to solve the whole problem”. And then we’ll iterate that whole big thing and then it turns out that’s both really hard to do and once again you end up with the problem that there’s only a handful of people that can implement it.

Aaron: And also I think more importantly that also has the problem of: if you realize there’s a mistake in it, then you have to essentially throw out the whole thing and make a version 2. And Microformats is a good example is this evolution. Microformats 1 vs. Microformats 2… they’re completely incompatible. They don’t work the same way, but you can still send a Webmention with Microformats 1 markup and it works. Webmention doesn’t have to change. So people build out Webmention tools and infrastructure, the thing on top of that is the Microformats to make it actually look good and make a comment work. Microformats can change and evolve, and Webmention doesn’t have to evolve. Whereas when you end up with a monolithic stack, if you’re like, “oh crap, we don’t like the things we decided for this layer in the stack.” We can’t just swap out that layer because then the whole stack breaks. That’s part of why the approach we’ve taken is harder, because you have to treat each one independently and evolve each one on its own schedule. And they all have their own change-control process.

Tantek: It looks more chaotic.

Aaron: Yeah, and it is little more overhead in terms of: each spec has its own document and test suite that is for each one specifically. But I do think that’s the better approach for a longer term success.

Aaron: We’re essentially entering this third phase of now we have stuff, we need the tools built on it, but we also don’t want to then four years from now turn around and say to everybody who’s built these tools, “oh, we’ve changed now, we’ve decided that we’re going this whole different approach and redo all your stuff.” No, we want to make sure that those are all based on ideas that are technically proven and easily swappable in small pieces if you need. But if we were to suddenly say, “we decided that Webmention doesn’t work and we need a third parameter and go fix Micro.blog.” You’d be like, “well crap, now what, do I do that, do I abandon it, break interop and continue iterating on my own product?”

Tantek: The other big thing that happened is that we expanded greatly in Europe. International. I think that really started with… was it 2013, the first Brighton IndieWebCamp? We’re looking to try to scale it beyond — and we’ve done this somewhat in Europe — but I think we want to see more of it. The things in the community running and people running IndieWebCamps and Homebrew Website Clubs without needing to even check with Aaron or me.

Tantek: I would be happy to help out as a guide or mentor more than a leader in that respect. And I think that’s the way we’re going to keep scaling it. And in the next 4 years, I would like to see us in more countries. I would like to see us reach more diverse populations. Maybe people that aren’t just in the tech crowds, but people that are not earning as much money, right? Everyone has a phone number supposedly. No matter what you’re earning or not. And I even hear from developers of new services that kids just use SMS, they don’t even want to deal with email. And so people doing new apps have purely SMS-based sign-up flows and all that. So there’s definitely opportunities to reach — to keep innovating and figuring out how can we reach even a broader set of folks in that regard.

I’ve updated the Discover emoji on Micro.blog to add several new topics:

• breakfast: 🍳 🥞 🥓
• racing: 🏎️ 🏁
• cricket: 🏏
• guitar: 🎸
• knitting & crochet: 🧶
• travel: 🗺✈️

The /posts/discover API for Micro.blog apps has also been updated. It now returns the emoji that Micro.blog is currently tracking, and whether it’s one that is “featured” in the default popup menu in Micro.blog on the web. Since many of the emoji are seasonal, like sports, we can rotate out the default list throughout the year. (The iOS and macOS apps will be updated later to more closely match the web version of Micro.blog’s topics popup menu.)

Greg Morris has imported his WordPress posts to Micro.blog hosting and had a question about referencing photos in a template:

Card previews I really want to be able to solve - does anyone know how to pull an image out of a hugo post in order to put meta property=“og:image” into the head?

Micro.blog uses Hugo themes because they are fast and there’s so much flexibility to customize them. To test this, I created a theme and edited the layouts/partials/head.html template, adding this somewhere along with the other meta tags:

{{ with .Params.images }}
  {{ range first 1 . }}
    <meta property="og:image" content="{{ . }}">
  {{ end }}    
{{ end }}

This looks at the photos on a post and takes the first one, adding its URL to a meta tag. If instead of the original photo you want to include a smaller thumbnail, you can use Micro.blog’s special photos.micro.blog resizing proxy. Here’s an example to include a 300x300 thumbnail:

{{ with .Params.images }}
  {{ range first 1 . }}
    <meta property="og:image" content="https://photos.micro.blog/300/{{ . }}">
  {{ end }}    
{{ end }}

I still want to add more built-in designs, as well as add design settings so that custom themes aren’t necessary for common features. But there’s a lot of power here to make your blog whatever you want it to be.

Micro.blog’s goal is to encourage more people to post to their own blogs instead of only on big social media sites, and to have a great community where conversations can happen from those posts. The goal is not to completely replace any specific social network, but instead to help the future be a little more decentralized, with more variety and independence in the web. Important changes are possible if we don’t concentrate so much of the web’s content only on Facebook and Twitter.

I’ve been happy to see so many people who have found that Micro.blog does supplement existing social media so well that they can spend more time blogging, browsing the Micro.blog timeline, and participating in conversations. Other folks will jump in to Micro.blog from time to time, but might have most of their attention elsewhere, and that’s fine too.

Facebook’s mission is different. They want to connect everyone in the world. Billions of people writing posts and sharing photos on a single domain name. Mark Zuckerberg talks about this often. Sure, some great things can happen when you do that, to bring people closer together, but also terrible things. The trade-off is not worth it.

Micro.blog leaves certain features out on purpose because adding those features risks changing our mission from what it is to what someone else’s mission is. We do want the community on Micro.blog to keep growing so that it’s more diverse and valuable to people, and for many more people to start new blogs that we can host on our platform. We can do that while staying true to our original goals and not falling for the trap of trying to become the next Facebook or Twitter.

I don’t even want to link to that story by Casey Newton at The Verge because it’s so disturbing and tragic. I read the whole thing because as the founder of Micro.blog, where we value the balance between content ownership and curation, I had to understand what Facebook is doing so we don’t repeat the same mistakes.

Social networks like Facebook (and Twitter) are designed to reward the sensational video. The timeline algorithm, “like” counts, and quick re-sharing all contribute to surfacing both the best and worst content. Whatever drives engagement.

Facebook is right to hire thousands of content moderators. But they should be real employees with healthy working conditions, not people who Facebook feels no responsibility to take care of. This is the most damning article I’ve ever read about Facebook.

On road trips lately, I’ve been fascinated by out-of-business donut shops. If it’s late in the afternoon, sometimes a donut shop is just closed for the day. But it seems like many are closed for good, the old fryers and cooling racks gathering dust.

Why is this? My guess is that the startup costs for opening a donut shop are less expensive than many types of restaurants. There’s nothing special about a donut shop except that it’s fairly easy to get started, but no guarantee of success, especially in a small town. Most businesses fail.

Jacob Gorban started a new site for musicians to connect on Micro.blog. From the about page:

I had the idea for this list because I’ve had quite a few inspiring music-related discussions on Micro.blog and I wanted to make it easier for musicians to find each other on the service, to facilitate even better discussions and maybe even some collaborations.

Jacob has been posting videos of playing guitar to his blog and on YouTube. Even if you’re not a musician, also check out @JustGoodMusic, a new blog about music from John Philpin, with posts from Jacob and others.

Finally getting around to posting this. The last couple of weeks since WWDC have been busy. But as I usually do, I still want to capture a little of the week in San Jose. (Looking back on my old posts about WWDC from the 2000s is a great reminder of what the earlier conferences were like, and I wish I had more of those posts.)

Arriving Saturday evening in San Jose, I rented a car and checked into my Airbnb. This is the first time I’ve tried Airbnb for WWDC. Hotel prices are out of control and I thought it would be a good way to see a different part of the city. Daniel and I caught up over dinner.

Sunday morning I drove up to San Francisco. I’ve made it a tradition to visit the Walt Disney Family Museum every year, and moving the conference to San Jose hasn’t deterred that. I stopped at Blue Bottle Coffee in San Mateo on the way.

The special exhibit at the museum was Mickey Mouse drawings. It was an incredible collection. Afterward I had a bite to eat at the Presidio Picnic. Fog covered the Golden Gate Bridge.

I picked up Jon Hays from SFO on the way back, and we stopped at the new visitor center for Apple’s spaceship campus, then got coffee and lunch down the road at Chromatic Coffee. Also detoured slightly for a quick look at Winchester Mystery House. (Skipped the $39 tour. Ouch.)

I didn’t need the rental car anymore, so we dropped it back at the airport and took an Uber downtown, planning to go to sfMacIndie and watch game 2 of the NBA finals. That’s when the evening went completely off the rails. We were cruising down the highway and someone rear-ended our Uber so hard it felt like the car was standing still. Everyone was shaken up but okay.

The keynote was packed with new stuff. I knew this was going to be a big year, but I was expecting most of the news to be around Marzipan (Catalyst). That ended up being a small part of the morning. I watched the keynote from AltConf and worked on highlighting WWDC-related posts in our new Discover section for the conference.

I was feeling a little out of it most of the morning. As the day progressed and I saw friends or met new folks, I started to feel better. Brent Simmons held a NetNewsWire meetup in the afternoon.

Tuesday at lunch was our Micro.blog WWDC meetup. This is the 3rd year in a row we’ve held the meetup. It was great catching up with everyone. If you made it to the meetup, thank you! I sent an email to everyone who had RSVP-ed.

That night was The Talk Show Live with John Gruber and his guests Craig Federighi and Greg Joswiak. Great show.

Wednesday morning I stopped for coffee on 2nd street for a little work before walking over to AltConf. My flight was in a few hours so I had just enough time for one session: Leah Culver’s talk on making the podcast app Breaker as crash-free as possible. (Leah also co-founded Pownce back in 2006. I’m hoping to interview her for my book, Indie Microblogging.)

This was a bit of a strange year for me. While I’m sorry I missed some people and some events, I think it was good that I was back home early. I’m not going to make any other conferences this year. If you’re looking for places to go, I highly recommend IndieWeb Summit in Portland later this month, and Release Notes in Mexico in the fall.

Apple’s new stuff didn’t disappoint. I’m most excited for Catalyst and Sign In With Apple, which I blogged about here. These are both very practical solutions to real problems. The new iPadOS improvements are also welcome, and I’m looking forward to experimenting with SwiftUI. Overall, a great WWDC.

Micro.blog has been updated on the Mac. Here are the changes:

• Added new Open option when clicking a post to open it in your web browser. Useful for copying the link or viewing the post on the author’s blog.
• Added icons for Reply, Favorite, and Conversation.
• Fixed error reporting when posting fails and during timeline loading.
• Fixed photo compression to be more consistent across Micro.blog platform.

I tried many different UIs for this before settling on “Open”, including a share menu to match iOS. Nothing felt right. By adding icons for all the options, I could make “Open” use the default web browser’s icon, which helps convey what will happen. (It uses stylized versions of Safari, Chrome, or Firefox icons.)

Choose “Check for Updates” or grab the latest version from the download page.

Today I sent the following update to Kickstarter backers. I wanted to give everyone a progress update on writing the book, and a reminder about some of the new stuff in Micro.blog.

When I launched the Kickstarter for Micro.blog, I promised to write a book about independent microblogging. For the last 2 years Micro.blog has needed most of my attention, but as the platform has grown and matured, I’m finding more time to work on the book.

The book is not a simple how-to for creating a microblog. That is part of it, but we already have a help site with tutorials on microblogging. The book is also a history and guide for taking back social networking from massive platforms.

I have been repurposing draft sections of the book to my blog as posts. One of the latest is about open gardens — how we can think about the role of curation in social networks.

There are also interviews in the book. I sat down with IndieWeb co-founders Tantek Çelik and Aaron Parecki to talk about the first IndieWebCamp conference and new challenges, recording the full conversation. Today I have been working on transcribing it.

If you haven’t kept up with Micro.blog news, we were just covered last month in an article by Cal Newport for The New Yorker. And we’ve added many new features, from video hosting and blog categories to custom themes based on Hugo.

No one said that it would be easy to provide an alternative to Twitter and Facebook based on the open web, encouraging thousands of new bloggers in the process. It has been years of really hard work, with more to do.

If you still believe in the mission of Micro.blog, I would love your support. Fire up the Micro.blog app if it has been a while, dust of your blog, upgrade to a paid subscription, and let us know what we can improve next.

Thanks as always.

It was a good week at WWDC. Micro.blog helped sponsor last night’s LIVE near WWDC concert, and we held our 3rd annual meetup on Tuesday afternoon. I just sent the following email to everyone who RSVP-ed to the meetup.

Thanks to everyone who was at our WWDC meetup! If you couldn’t make it, or I missed talking to you in person, you can always send me an email if you have any questions or feedback.

Throughout the week at WWDC, I was asked how Micro.blog is going. New people join the platform every day, thanks to word of mouth, blog posts, and even mainstream stories like the article in The New Yorker. I’m an optimist. I believe if more people blog and use open tools, the web will be better, and platforms like Micro.blog will thrive.

But it doesn’t happen by accident. Facebook and Twitter are massive platforms. Our team at Micro.blog is tiny. Every time you tell someone about Micro.blog it makes a difference. Every paid subscription gets us a little further.

I hope everyone has enjoyed their time in San Jose! Your support of Micro.blog means a lot.

This is one of the most interesting announcements from WWDC for me. Aaron Parecki wrote a detailed technical post for Okta about it, as well as a post on his blog:

Sign In with Apple is a good thing for users! This means apps will no longer be able to force you to log in with your Facebook account to use them.

There are also 2 sessions at WWDC: Introducing Sign In with Apple and What’s New in Authentication, Safari, and WebKit.

I plan to support Sign In with Apple in Micro.blog. We don’t have passwords, and we require verifying an email address before setting up your account on Micro.blog, so using Sign In with Apple should make the initial sign up go more smoothly. It could also be an option for existing users who need to sign in again and don’t want to wait for the confirmation email.

Ben Thompson covered more about sign in on Stratechery this week:

Apple is going to leverage its monopoly position as app provider on the iPhone to force developers (who use 3rd party solutions) to use Sign In With Apple. Keep in mind, that also means building Sign In With Apple into related websites, and even Android apps, at least if you want users to be able to login anywhere other than their iPhones. It was quite the announcement, particularly on a day where it became clear that Apple was a potential target of U.S. antitrust investigators.

I’m generally against the App Store review guidelines becoming even more restrictive. I’d rather developers choose to adopt Sign In with Apple because it’s better than using Facebook and Twitter rather than be required to do so on Apple’s schedule. But in this case, I think the end result will be positive.

People often ask me how we “win” against the big social networks, bringing more open platforms and indie blogging to everyone. It happens in small steps, not overnight. Sign In with Apple can be one of those small steps. Anything that moves people away from signing in with Facebook and Twitter is part of the solution.

The 3rd annual WWDC Micro.blog meetup will be today at 12pm outside Grace Deli & Cafe. If you’re attending WWDC this week, grab a to-go box lunch and meet us there, or you can get a sandwich or wrap first from the cafe. Jean, Jon, and I will be there until 2pm.

It’s less than a block from the convention center: 303 Almaden Blvd. View the location in Google Maps or Apple Maps.

We’ll have some more Micro.blog stickers and we’ll also be giving away a VIP ticket to the LIVE near WWDC benefit concert for App Camp for Girls. We’d love to talk to anyone who is currently using Micro.blog or interested in learning more about indie microblogging.

Hope to see you there! Thanks for all your support.

In technology, the walled garden is a platform where one vendor controls distribution. If you want to make an iPhone app, your only choice is for Apple to approve it and sell it in the App Store. If you want to send a tweet, your only choice is to register on Twitter’s platform.

Walled gardens like the App Store are user-friendly and developer-hostile. They take power away from independent publishers and put it in the hands of gatekeepers. The problem is exclusivity: there is only one gate, and those stuck outside are unable to distribute the same content. You can make Android apps, but not iPhone apps. Nothing exists outside the walls that closely resembles what is inside.

Twitter is also a walled garden. Like the App Store, it is a closed platform with proprietary formats and a limited API. The difference is that Twitter’s garden is poorly curated and full of weeds. The walls are in such disrepair it’s hard to even tell where they are.

Mike Monteiro emphasized this frustration in a post about the problems facing Twitter’s leaders. He talked about meeting in person with Jack Dorsey:

We discussed Twitter’s role in the world stage. And I admired his vision, but feared his approach. Jack, and to an extent Twitter’s pet porg Biz Stone, have always believed that absolute free speech is the answer. They’re blind to the voices silenced by hate and intimidation. The voices that need to be protected. But anyone who’s ever tended a garden knows that for the good stuff to grow, you have to deal with the bad stuff. You can’t let the weeds choke the vegetables.

The issue isn’t that Twitter doesn’t care. It’s instead a design flaw in the platform. Because tweets don’t exist outside of Twitter, when you’re banned from Twitter, you need to start over with a new format or on a new social network. For this reason, and because their business depends on a large user base, Twitter is hesitant to throw anyone off their service. They’re unwilling to tend the garden for fear of pulling too many weeds.

It doesn’t matter who is guarding the walled garden’s gate if increasingly no one wants to go inside. So there’s a better word than “gatekeeper” to describe what we’re really after in building a great community-focused platform. It’s “curator”. Someone who is responsible for maintaining the best experience for users.

The answer to a walled garden is not to create a platform without rules. It’s not outsourcing decisions to algorithms, with recommended users and topics that can be gamed or lead new users astray. That’s not enough for the challenges brought to us by massive, ad-based social networks, where fake news and hate can spread quickly.

We need a new approach. Not controlled only by algorithms, but also not a walled garden that limits distribution of content. We need a system that prioritizes curation while preserving the freedom to publish outside of silos, with APIs based on the IndieWeb that are open by default instead of locked down with developer registration.

I think of this as an open garden. It’s an open platform that also cares deeply about maintaining a healthy environment. Outside of the garden, the soil is the same and the same plants can grow, and you are free to copy flowers and trees from inside the garden and cultivate them yourself or let them grow wild. But inside is well-curated. Inside strives to be a high quality, safe environment.

In my Kickstarter video for Micro.blog, I talked about this for social networking and blogs:

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.

The fundamental problem in walled gardens like the App Store and Twitter is that they are closed. If they open up, they could in fact double-down on curation. There would be no need to loosen their quality standards because there’s an easy path to publishing without review by using the open web.

I first wrote about this in 2014 in the context of learning from Beats Music. For Apple to deemphasize their algorithmic top 200 lists in the App Store they would need to focus on curation. Here’s what Beats was doing:

Instead, they have a bunch of people — musicians and writers who deeply care about music — curating playlists. The top 25 playlists in a genre are so buried in the app that I had to search them out just to write this blog post, because they seem to carry no more weight than any other playlist. Much more common are playlists like “our top 20 of 2013”. That’s not a best-selling list; it’s based on real people’s favorites.

After Apple acquired Beats Music, they brought some of those curation lessons over to Apple Music, and later redesigned the App Store with more featured apps and stories. There is only so much they can do, because the foundation of a walled garden is difficult to change.

Twitter has likewise created an environment that ties their hands on curation, with discovery driven by trending hashtags and retweets. And for each rare time a popular account is banned for hate speech, there are still thousands of trolls who are making life miserable for users. Because there is no alternative, Twitter must allow nearly all content on their service. Because it exists apart from the open web, Twitter must give its worst users too much leeway before banning their account.

The open garden solves this problem. It’s the same web inside a platform like Micro.blog as on the rest of the internet. By adopting open standards but also drawing a line across which we can apply community rules, it’s possible to build features that protect users.

By encouraging the use of personal domain names, when Micro.blog does need to ask a member of the community to leave for violating our guidelines, that blogger can take their domain name and content with them, continuing to post to their own blog but blocked from interfering with the community. The curators of the platform have more freedom to block harassing posts because those problematic users can retreat to their own web site and leave everyone else in the community alone.

To summarize:

• Open gardens have curators instead of gatekeepers.
• Open gardens use standards so that the same formats exist inside and outside the platform.

This is only possible by embracing the open web. I believe it’s an important part of the way forward for all great platforms.

Love this new podcast from Joe Cieplinski. It’s a great example of trying something new with a short-form microcast. The first episode is really well edited, with everything from recording to publishing entirely on iOS:

Edited in Ferrite on iPad Pro with Apple Pencil. Show notes composed in Drafts. Published with Wavelength. No Mac involved. Micro.blog handles all hosting and publishing to the feed.

Seeing this kind of thing is exactly why we added podcast hosting to Micro.blog. There are a lot of people out there with a story to tell or a new way to tell it. It should be easy and inexpensive to start a podcast that you own, with your own domain name, that works with open standards.

Neil Stephenson has written a new book. In an interview with PC Magazine, he talks about the problems with social media:

We’ve turned over our perception of what’s real to algorithmically driven systems that are designed not to have humans in the loop, because if humans are in the loop they’re not scalable and if they’re not scalable they can’t make tons and tons of money.

I think more social networks should do things that don’t scale, prioritizing safety over profit. For example, in Micro.blog the featured posts in Discover are curated by humans instead of algorithms.

Significant parts of Facebook and Twitter run unattended. There was more pushback against Facebook last week after they refused to remove the edited Nancy Pelosi video, choosing instead to try to educate users that the video was fake. Monika Bickert, Facebook’s vice president of global policy management, went on CNN to defend their decision. She described how Facebook works with fact-checking organizations to independently confirm whether something is accurate:

As soon as we get a rating from them that content is false, then we dramatically reduce the distribution of that content, and we let people know that it is false so they can make an informed choice.

I signed in to Facebook to try to understand what they had done. I actually had trouble finding the video at first, maybe because none of my friends on Facebook had shared it. Searching for Nancy Pelosi did include Facebook groups such as “Nancy Pelosi is Insane” and “Americans Against Nancy Pelosi”, featured prominently in the search results. I finally found the video, but there was no callout that it was fake. (The version I saw was captured with a camera pointed at the video playing elsewhere, likely confusing Facebook’s algorithm for finding an exact copy of the video.)

Facebook is trying to solve this problem, but it’s a band-aid on a system that is working as designed to surface “relevant” content for more ad views. It’s not enough.

At the beginning of the month, I started a new blog post series: visiting a city park each day for 30 days. I’m now 23 days in, wrapping up the final week before I leave for WWDC in San Jose. For some parks, we’ve brought a picnic lunch, and for others I’ve sat with my iPad and worked on blog posts or the upcoming book. A few days there wasn’t time for anything but a short walk around and photo.

Unlike my previous 30-day series for libraries and coffee shops back in 2016, I’ve been consistent about taking a photo every day, which I’ve collected together as thumbnails on the main page:

Watching that grid of photos grow from a single photo to dozens is a daily reminder of how progress works on anything. It’s slow, but there’s confidence in seeing a project go from possible to inevitable.

This is really what blogging is all about. It’s not just the individual posts that matter. It’s also the collection, built over time with a system designed to encourage regular posting. I love that at the end of this 30-day series I’ll have a web page with photos of parks all over Austin, and bits of text that capture a small part of what each park was like.

I linked briefly to The New Yorker article by Cal Newport over the weekend, but wanted to add a few more thoughts. The article really does a great job of capturing what the IndieWeb movement is about, and Micro.blog’s role in it:

Even as it offers a familiar interface, though, everyone posting to Micro.blog does so on his or her own domain hosted on Micro.blog’s server or on their own personal server. Reece’s software acts as an aggregator, facilitating a sense of community and gathering users’ content so that it can be seen on a single screen. Users own what they write and can do whatever they want with it—including post it, simultaneously, to other competing aggregators. IndieWeb developers argue that this system—which they call posse, for “publish on your own site, syndicate elsewhere”—encourages competition and innovation while allowing users to vote with their feet.

As we’ve been consistently chipping away at Micro.blog bugs and features, moving the platform forward, I’ve always thought that eventually Micro.blog will get mentioned in the larger narrative about social networks from the mainstream press. We can’t control when we get noticed. We just have to be ready when it happens.

It’s great to see all the new folks joining Micro.blog! Whenever someone new has feedback, I’m reminded what we can improve so that the experience is better for the next person.

There’s one sentence in Cal Newport’s article that I keep going back to:

The Internet may work better when it’s spread out, as originally designed.

I have no doubt that this is true. It’s okay to have centralized services to make things easier for people, because it’s too much to expect that everyone should run their own server. The web can be “spread out” on multiple layers: a more diverse set of platforms, so that not all the power is concentrated in a couple massive platforms like Facebook; and more personal domain names, so that even if Micro.blog hosts 1000s of blogs, each one has its own identity on the web and can be moved.

Domain names are the key to content ownership. This is a fundamental part of Micro.blog’s architecture, not something that was tacked on as an afterthought. I’ve written more about owning your content here, which is one part of the solution to moving beyond today’s social networks.

Advertisements often make broad claims that their products are the “best” or “easiest” or “most popular”. These statements are impossible to prove, and I think make the marketing weaker because they sound like an exaggeration.

We’ve redesigned the Micro.blog home page for new users, to better explain what Micro.blog actually is. I wanted to emphasize that it is both a blogging platform and also a great community, as well as highlight who our team is.

As a sort of tag line, I wrote that Micro.blog is “the fastest way to blog”. I like describing it in terms of speed because it also implies ease of use. If it’s simple and fast, more people will blog. Micro.blog is the blog you will actually use.

But is it true? I’ve used many blog platforms over the years, and I can’t think of one that is faster to go from idea to starting a post to publishing it. In the native Micro.blog app for macOS:

• ⌘-N to start a new post.
• Type something.
• ⌘-return to publish.

It’s the same basic workflow on iOS and the web. By default, you don’t need to worry about a title field or categories or any other UI getting in the way. This focus on simplifying blogging means there’s no tabbing or clicking around unless you need more advanced features.

There is still a lot we can improve, especially how quickly a post shows up in the timeline after publishing it. I just tweaked that today. By stating up-front that performance matters, it’s a constant reminder to make everything faster. But in terms of the workflow of drafting a new post, I think Micro.blog has a clear advantage.

After launching support for Mastodon on Micro.blog, I blogged about how Micro.blog is evolving to support 3 types of usernames: normal Micro.blog users, Mastodon users, and IndieWeb-friendly domain names. This last type of username is where I think we can bring more social network-like interactions to the full web.

Here’s an example. In a post on Micro.blog, you can @-mention someone’s blog by including @domain.com in the post, using their domain name. If that blogger’s site supports Webmention, Micro.blog will send your mention to their blog, where it could be included as a comment.

I’ve been testing a new feature for this type of username in Micro.blog. You can now follow blogs in the Micro.blog timeline, even if the blogger hasn’t yet registered on Micro.blog. On the web, click Discover, then click the search icon, and enter their domain name. Micro.blog will auto-discover their JSON or RSS feed, letting you follow their blog just as you would follow any Micro.blog user.

This feature is designed for blogs with a custom domain name. It assumes one blog, one user, one domain name, so it doesn’t work to follow specific feed URLs yet. You’ll still want a traditional RSS reader for sites that have multiple feeds.

I’ll continue to improve this based on feedback, and start adding it to the native apps. Micro.blog is already one of the most open platforms of its kind, and I think this has a lot of potential to take it a step further.

I introduced the Tweet Marker API in 2011. In the 8 years since, I’ve been lucky to have the support of some of my favorite apps like Twitterrific and Tweetbot, plus popular Android apps, with some developers paying a monthly subscription to help keep the service running. But while Tweet Marker hasn’t changed recently, the Twitter world has changed.

Twitter previewed the next version of their API this week. I don’t see anything so far to contradict what I wrote last year.

I believe strongly that URLs shouldn’t change, and that public APIs shouldn’t just disappear. Owning your content and having your own domain name are important parts of Micro.blog too. So I was committed to running Tweet Marker indefinitely, regardless of what Twitter might do.

But two other factors were nagging at me:

• GDPR made me take a fresh look at some of the assumptions in the Tweet Marker API. Changes are overdue. They aren’t simple and would require coordination with client developers.
• Twitter’s third-party ecosystem has changed a lot since Tweet Marker was created. Twitter apps have a very uncertain future. Timeline syncing is often handled without Tweet Marker, such as via iCloud.

Tweet Marker’s time has come and gone. I’ve notified developers using the Tweet Marker API that I plan to wind down the service by July 1st. I’ve also cancelled all the paid subscriptions. (Actually I haven’t billed anyone in over 6 months, so I’ve been running the service for free.)

Daniel Jalkut and I talked about this back in December on Core Intuition 353. I plan to work on Micro.blog for the next 20 years or more, so it needs all of my attention.

Over a million people have used Tweet Marker. I’m proud of that. If you’re one of those people, especially if you supported Tweet Marker as a developer or with a subscription, thank you.

Bokeh will be a new private-by-default photo sharing app from Tim Smith, on Kickstarter now:

Bokeh will be ad-free, have a chronological timeline, and will be private by default. That means that all accounts will start off as private. Public accounts will have an RSS feed, will have the option to cross-post to other social networks, and will support custom domains. All accounts will have an indie web compatible export so you can self-host if you want to.

Tim has been active in the Micro.blog community from the early days of the platform, and I’ve talked to him about Bokeh leading up to the Kickstarter. I think there is a lot of potential for parts of Bokeh to be compatible with Micro.blog. There is some overlap with what we’re doing with Sunlit, but as I’ve written about, more smaller social networks that can work together is a good thing! I’ve backed it on Kickstarter.

We’ve launched a redesigned home page for new users on Micro.blog today. The old design was a little too sparse and didn’t do a very good job of explaining what Micro.blog is. The challenge is that Micro.blog is really 2 things — a blog hosting platform and a social network for microblogs — so the new design reflects that with a 2-column layout.

To give an example of what posts on Micro.blog look like, we include recent posts from the Discover section directly on the home page. There are also profile photos of the team members at the bottom so that new users have a better idea of who is behind the platform.

We know that of course you can’t watch a Netflix-exclusive show on Hulu or Amazon Prime Video. But wouldn’t it be great if you could? With the current open podcast ecosystem, that’s exactly what we have: any show from any network can be played in any podcast client by default.

You might think with my attack on Luminary that I don’t want big companies to succeed with podcasts, but that’s not it. There’s nothing wrong with trying to make money off of podcasting. I just think it’s possible to make money by working within the podcast ecosystem instead of against it.

Here are several great ways to monetize podcasting that preserve and even strengthen how podcasts work:

• Start your own podcast (or multiple shows on your own podcast network) and build an audience. You’ll then be able to accept sponsors or memberships.
• Offer an easier way to produce and host podcasts. This is what we’ve done with Micro.blog. For $10/month, we’ll host MP3s at your own domain name and give you a podcast feed. Plus we have a companion iPhone app called Wavelength just for recording podcasts on-the-go.
• Help smaller podcasts with a variety of tasks they don’t have time for, like finding sponsors or editing episodes.
• Build a membership platform to make it easier for podcasts to be supported directly by listeners with subscriptions. While the user experience for members-only podcasts is not great yet, it is possible to create private podcast feeds that work in many different podcast clients.

And here’s a way to monetize podcasting that will weaken the ecosystem:

• Leverage the popularity of podcasts by creating a proprietary distribution model with exclusive shows. This requires redefining what a podcast is to include shows that do not have an RSS feed. If you do this, do not call what you’re doing a podcast.

As I wrote in my blog post about Substack:

If we accept calling “any audio on the internet” a “podcast”, we undermine what makes a podcast unique: not just the convenience of delivering audio directly to your device, but the openness that ensures that podcasts work in a variety of players, without a single company with too much control trying to lock down the format.

Companies like Luminary and Spotify will most likely fail to dominate podcasting because listeners want to use their favorite podcast client to listen to podcasts. Try explaining why your exclusive “podcasts” don’t play in Apple’s app called “Podcasts”. But if someone does succeed in creating a “Netflix for podcasts”, it could eventually lead to a couple major problems:

1. An aggregator on the scale of Facebook or YouTube could emerge for podcasts.
2. The market could become fragmented like it is for video streaming services.

If either of those things happen, we will all be much worse off. (For more arguments along these lines, check out episode 323 of the Accidental Tech Podcast.)

In 2016, I tried working from a new coffee shop every day for 30 days, then later followed that with 30 days working from libraries. Each day I would post a microblog post and sometimes a photo. You can find links to all these posts on my 30 days page.

When it was all done, I wrote:

After wrapping up libraries, I thought I’d make it a trilogy of 30-day endeavors, with a final 30 days of working from city parks. This was a suggestion from Daniel Hedrick, who had worked from parks before, tethering to his iPhone since there’s usually no wi-fi. I loved the idea right away because it fit so well with the goal of getting out of the house and discovering something new in my own city. I even spent a couple hours earlier in the month researching parks and planning out whether I could do it.

But I quickly realized that I was burned out on commuting all over town, so I tabled the idea. Fast-forward a few years. This week, I’ve been struggling to stay productive as my attention is pulled in a few directions with tasks for Micro.blog.

I’ve also been working more on my book Indie Microblogging, which I can write from anywhere on my Mac or iPad. I think restarting the “30 days” idea will force me to carve out some uninterrupted time to write, and get me out of a bit of a rut from working at home. It will also be a great use of Micro.blog.

For day 1 of 30, I went to Walnut Creek Metropolitan Park in Austin. It’s a large park with hiking and biking trails. I actually did more walking than writing, but it’s a start. As with coffee shops and libraries, I’ll collect links to all the posts on a new page here.

John Gruber has a great post on Luminary and the trend of companies trying to redefine what “podcast” means. It’s not a podcast if there’s no RSS feed and it can’t work in multiple client apps:

Being client-agnostic is the spirit of the open internet, and I think it’s implicitly part of being a “podcast”. Openness was certainly part of how podcasting came to be.

Substack is another company that initially tried to ride the popularity of podcasts by calling their audio in email newsletters a “podcast”. I wrote about it here. I’m happy to notice that as of this week, Substack has real podcast support by adding private RSS feeds for newsletter subscribers. That’s the right way to go and now their audio shows work in any podcast client.

We do not need the “Netflix of podcasts”. Anyone can create and distribute a podcast — even Micro.blog has support for podcast hosting and a simple app for recording and publishing podcast feeds that work anywhere — so it would be a step back for the industry if a single company tried to control distribution.

The New York Times has an article today about demolishing Penn Station, full of incredible old photos:

With its swarming crowds and dust motes dancing in shafts of smoky light, the station was catnip to midcentury photographers, filmmakers, artists and architects. It was the architectural embodiment of New York’s vaulted ambition and open arms.

In 2016, I wrote a blog post on applying the lessons from Penn Station to the open web and podcasting. It’s still one of my favorite recent posts.

Following Jeffrey Zeldman’s article about the open web, Ben Werdmuller has a great post about how we shouldn’t care so much about startup unicorns, using Micro.blog as an example of another type of business:

Zeldman looks to Micro.blog as a potential answer. It’s a great company that could point to what a more general solution could look like, but not specifically because it works with the indieweb. Instead, it’s worth examining how it’s financially structured. Rather than a unicorn, it’s a zebra.

It would be great to have more small- and medium-sized companies that can move the web forward. They can innovate while still being grounded in somewhat boring business models. It matches one of my points here that we need multiple social networks that interoperate via the web instead of just a couple of huge platforms.

There’s a difference between companies that are paid for directly by users and massive ad-based networks. Ben Thompson outlines this in an article about regulation, arguing that the super-aggregators like Facebook require government intervention, where other companies that are better aligned with users' interests can be “regulated” by the market:

I think, though, that platform providers that primarily monetize through advertising should be in their own category: as I noted above, because these platform providers separate monetization from content supply and consumption, there is no price or payment mechanism to incentivize them to be concerned with problematic content; in fact, the incentives of an advertising business drive them to focus on engagement, i.e. giving users what they want, no matter how noxious.

I’ve been thinking about Ben Thompson’s essay a lot since he published it a couple weeks ago. Micro.blog is a small part of the puzzle — and it’s a puzzle piece of a different shape that doesn’t fit cleanly into Ben’s diagram around free services — but I think it’s an important part to focus on.

I’ve been having fun posting short videos to my blog now that Micro.blog makes it easy. You can see the recent videos on this category page.

And it has been great to see what other people come up with. For example, I love these time-lapse videos: the clouds moving above Fort Tryon Park in New York City from Joe Cieplinski, and this beautiful one of Ha Long Bay in Vietnam from Jordon Wadlington. I sometimes forget that my iPhone camera has a time-lapse feature, and now I’ll be looking for an excuse to use it.

While on a 6-week walk from Tokyo to Kyoto, Craig Mod is disconnecting from social media and instead posting to “followers” using SMS:

What do I mean by “use the network to publish without being used by it?” On most services — Twitter, Facebook, Instagram, etc — in order to publish something you must stare into the maw of its timeline, resist whatever the algorithm has queued up for you, and then, if you’ve remembered what you were going to publish, publish.

At the end of the journey he will collect the photos and comments in a book. I think this could’ve worked as a microblog as well, because then users joining late could read previous posts in the series, but it’s a fascinating use of SMS.

Congrats to Federico Viticci and the MacStories team on 10 years of MacStories. To appreciate how long ago this was, I re-read Federico’s interview with me from 7 years ago. This was 3 years after his first post but the content feels like a lifetime ago.

I really like this interview because I think it captures that time on the App Store and as a Twitter developer. We talked about iOS 5 user interface design, my early indie apps before starting Micro.blog, but also a few things that are still relevant today, like using the iPad for real work and app pricing.

Most importantly, it was a few months before Twitter’s infamous 4-quadrant chart that would set in motion Twitter’s move away from third-party developers. My priorities changed significantly after that, eventually leading to Micro.blog.

We all expected Dark Mode in iOS 13, but according to this rumor from 9to5Mac, the next major version of iOS is also going to feature some major changes to windows and detachable sheets:

There are many changes coming to iPad with iOS 13, including the ability for apps to have multiple windows. Each window will also be able to contain sheets that are initially attached to a portion of the screen, but can be detached with a drag gesture, becoming a card that can be moved around freely, similar to what an open-source project called “PanelKit” could do.

We also get an answer to one of the questions Brent Simmons asked about split views:

Split Views on Marzipan apps based on iPad designs that run on the Mac will get the ability to be resized by dragging the divider and have their position reset when double-clicking the divider, like existing Split View apps on the Mac.

I hope that support for multiple windows maps over to macOS with Marzipan. We’ve been saying on Core Intuition that this WWDC is going to be special. Marzipan is the biggest shake-up to the Mac since the Carbon to Cocoa transition.

There’s a fantastic article by Jeffrey Zeldman in A List Apart this week, starting with the problems of venture capital-backed social networks and ending with the question of whether we can help fix the web:

On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?

I believe strongly that the answer is “yes”. Brent Simmons also responds, using the example of how even focused apps like RSS readers can move things forward without needing to solve all the problems at once:

Do I claim it’s as accessible to ordinary internet users as Twitter (for instance)? I do not. But it’s the step forward that I know how to take.

This is a great attitude. There are steps forward that we can all take individually, from leading the way by blogging more ourselves, to building tools for others to use. Together these steps add up to something significant that really matters.

It has been very encouraging to watch the Micro.blog community grow and new people regularly post to their own blog first instead of the big ad-based social networks. Seeing so much progress — but also knowing how much more work there is still to do — gives me a lot of hope for the future of the web.

If you’re still using Instagram but want to copy your photos and videos to your own microblog, a great solution is OwnYourGram. This is a free service that checks your Instagram account for new photos and videos, then sends them to your microblog automatically. Along with video support in Micro.blog, we’ve also improved support for videos from OwnYourGram.

First, make sure you’re on the podcast + video hosting plan on Micro.blog. For $10/month, we’ll host audio and video for you in addition to photos, and generate a podcast feed for you if you ever want to start a podcast later. You can upgrade here.

Next, follow the instructions on this help page for setting up your Micro.blog account so that it works with Instagram. This just means telling Micro.blog about your Instagram username, and telling Instagram about your microblog.

You can use OwnYourGram to send a specific video from Instagram to Micro.blog to test that everything is working. After that, OwnYourGram will check Instagram for new photos and videos and send them to your microblog. Photos and videos on Micro.blog are real blog posts, so you can always edit the posts later after they are created automatically.

Last week I drove to New Orleans for Peers Conference. It was a bit of a whirlwind because we also released video support in Micro.blog and updated 3 of the apps, which I knew might be a little too much to attempt to do while traveling. In fact, we did miss a couple bugs and updated Sunlit the next day, and a new Micro.blog iOS update will follow this week with more improvements.

I had a great time in New Orleans. The drive from Austin is 8+ hours, but I took even longer to make sure I had enough breaks from driving, for lunch and coffee and catching up on work. I took a few photos which I’ve collected together using Snapthread here to share as a short video.

Sunlit 2.5.1 is now available in the App Store. This update fixes an issue with videos not appearing in the timeline after the major new version we released yesterday to add video upload to the app and Micro.blog hosting.

Here are a couple screenshots of the update with the video preview and new full-screen player:

We’ve updated Micro.blog today with a big feature: video upload to your microblog. The iOS and macOS apps — as well as our iOS app for photos, Sunlit — have all been updated to support video.

Video upload and storage is based on our podcast hosting plan. If you’d like to post video, you can learn more and upgrade here. Just like podcasts, video hosting is designed for short videos, from a few seconds to 1-2 minutes. Each video should be 45 MB or less, but there’s no limit on the number of videos you can upload, and videos are stored at your own domain name.

We are very excited about this and can’t wait to see how people use it. Now that we have this foundation for video, I’m looking forward to expanding it based on feedback. I think there’s a lot we can do. (There were also a couple of last-minute bugs with playback on iOS… We’ll get those fixed soon.)

There’s no shortage of opinions about Apple’s services-related event this week! I’ve listened to a few podcast episodes, and of course I had my own thoughts on this week’s Core Intuition and a separate blog post about News+.

My favorite discussion about News+ so far has been the latest episode of Connected. They talk about the good things Apple brings to this, but also the downsides.

Federico:

I was asked by someone on Twitter, do you plan on putting Club MacStories on Apple News+? The answer is a huge no.

Myke:

Literally every single person who subscribes to Club MacStories would cancel because they’re all users of Apple products!

Federico:

There’s always a cost to adopting a new platform. There’s a technological cost, and there’s an actual cost. And for me, it’s not worth it to rewrite my — what we do for Club MacStories for Apple News format — but it’s also not worth it to lose the money that I’m making from the service that I control.

Federico’s point here gets to the key issue with these aggregation platforms, whether it’s News+, Facebook, or the App Store. When you give up control over distribution, you also give up control over revenue. With publishing on the open web, there’s always an alternative: your own domain name and your own subscribers. (For the App Store, there’s no choice.)

Back to the episode…

Stephen:

I still don’t love how closed off News is. Like on the Mac, you just can’t get a URL to open it in a browser. You just can’t do it. You’ve got to send a text message to yourself or something. And on iOS, or really anywhere, sending content to things like Instapaper is very hit or miss. […] Apple News doesn’t play well with the web, and that’s very frustrating to me as a believer in the open web.

Myke:

We’re all worried about Spotify walling off podcasts. Well, Apple’s trying to do that to news. […] It’s probably good for consumers, but is it good for the industry? We don’t know yet.

Great episode. You should listen to the whole thing, because as I said there are some points in favor of Apple News as well, and the other announcements. But the segment I’m quoting from above was particularly good.

We’ve rolled out some more improvements to Micro.blog. For blogs hosted on Micro.blog, you can now save a post draft to Micro.blog, then come back later to edit and publish it. The macOS app has been updated with support for drafts and a new “Posts” section to make editing or searching your existing posts much easier.

Here’s a short video of the new feature on the Mac:

Most of what Apple talked about today isn’t shipping until the summer or fall. Apple News+ does ship today with iOS 12.2. It’s priced at $10/month for access to hundreds of magazines and newspapers. As I posted about briefly, I’ll stick with paying The New York Times directly for now.

Michael Tsai writes about the larger issue with Apple News:

I continue to find Apple News to be disappointing. It’s like Apple reinvented the RSS reader with less privacy (everything goes through an Apple tracking URL) and a worse user experience (less control over fonts, text that isn’t selectable, no searching within or across stories). So the idea of content that must be accessed from the app—and likely can’t even be opened in Safari—is not attractive to me.

I think there’s great potential for Apple News on the curation side, but the articles are too stuck inside Apple’s apps, and the cost to publishers is too high. You can tell Apple feels like they’re onto something important with Apple News. My concern is that Apple’s solution is based so heavily on what they know how to do well — let’s make everything a native app with a nice UI and leverage our massive credit card database — that they’ve missed an opportunity to solve something more meaningful for journalism and the open web.

Seth Godin blogs every day. Sometimes short posts, sometimes longer posts that read like they could be part of one of his books. Yesterday’s post was one of those longer posts about big, centralized platforms:

Like a landlord who owns every building in town, Google can’t lose. A successful business in the online ecosystem is one that has a few dollars left over after giving the rest of it to Google or Facebook (or Apple).

He’s also been on a roll with his podcast. And for more about Apple vs. Spotify specifically, I enjoyed the latest episode of the Supertop podcast.

We sent an email to some of our Kickstarter backers yesterday, giving people a chance to check out Micro.blog again if they haven’t been active recently. The platform has improved so much in the last year. It’s possible that it didn’t meet someone’s needs a year ago but will today.

One of the links in the email was to the 12 days of microblogging help page, which links to 12 blog posts I wrote in December to highlight how people are using Micro.blog. Unfortunately, most of those links no longer worked! I scrambled to figure out why some of the links on my blog weren’t working, finally discovering that I had broken them myself when testing the Medium.com import feature across multiple test blogs.

In the process, I decided to pull a complete backup of Micro.blog’s database from 30 days ago and use it to fix some of my old blog posts. This was a great exercise. I check the backups from time to time, but it’s rare that I need to go over specific data by hand and actually restore anything.

Last week, Myspace revealed that they had lost all hosted music from 2003 - 2015. I don’t think we can be too careful with the responsibility of hosting people’s blogs, so I’m glad I had this chance for a real-world test of Micro.blog’s backups. (I also recommend enabling the Internet Archive feature under Posts → Design, and occasionally downloading a complete archive of your blog from Posts → Export.)

My heart goes out to the families of loved ones at the mosques in Christchurch. After the Parkland shooting, I drafted a long blog post about gun violence but never ended up posting it. Even after editing it a few times a month later, it felt like the words or timing were always wrong.

Over the last couple of years we’ve seen a growing backlash against social media. I won’t look for the video of this tragedy from New Zealand, and I hope I never accidentally see it. It is heartbreaking enough with words alone. Every story I read last week kept pointing back to the frustration with how Facebook, Twitter, and YouTube are not doing enough to prevent their platforms from amplifying misinformation and hateful messages.

Margaret Sullivan of the Washington Post writes about the problems with social media leading up to and after a tragedy like this mass shooting:

To the extent that the companies do control content, they depend on low-paid moderators or on faulty algorithms. Meanwhile, they put tremendous resources and ingenuity — including the increasing use of artificial intelligence — into their efforts to maximize clicks and advertising revenue.

Charlie Warzel of the New York Times covers this too:

It seems that the Christchurch shooter — who by his digital footprint appears to be native to the internet — understands both the platform dynamics that allow misinformation and divisive content to spread but also the way to sow discord.

Nick Heer links to an article in The Atlantic where Taylor Lorenz documents how after following a far-right account, Instagram started recommending conspiracy accounts to follow, which filled her feed with photos from Christchurch:

Given the velocity of the recommendation algorithm, the power of hashtagging, and the nature of the posts, it’s easy to see how Instagram can serve as an entry point into the internet’s darkest corners. Instagram “memes pages and humor is a really effective way to introduce people to extremist content,” says Becca Lewis, a doctoral student at Stanford and a research affiliate at the Data and Society Research Institute.

Duncan Davidson asks: “What are we going to do about this?”

The last few years, the worst side of humanity has been winning in a big way, and while there’s nothing new about white supremacy, fascism, violence, or hate, we’re seeing how those old human reflexes have adapted to the tools that we’ve built in and for our online world.

I can’t help but think about Micro.blog’s role on the web whenever major social media issues are discussed. It’s almost all I think about. We feel powerless against world events because they’re on a scale much bigger than we are, but it helps to focus on the small things we can do to make a difference.

Micro.blog doesn’t make it particularly easy to discover new users, and posts don’t spread virally. While some might view this as a weakness, and it does mean we grow more slowly than other social networks, this is by design. No retweets, no trending hashtags, no unlimited global search, and no algorithmic recommended users.

We are a very small team and we’re not going to get everything right, but I’m convinced that this design is the best for Micro.blog. We’ve seen Facebook’s “move fast and break things” already. It’s time for platforms to slow down, actively curate, and limit features that will spread hate.

The new version of Sunlit is now available in the App Store. You can download it for free and use it with Micro.blog or to publish photos to an existing blog like WordPress.

Why does controlling our own photos matter? As I wrote in this post about the way out of the mess created by massive social networks, having posts at our own domain names unlocks a few very important features:

• Open standards mean interoperability with multiple tools. I can use IndieWeb tools like OwnYourGram to automatically copy Instagram posts to Micro.blog, or use traditional blogging apps like MarsEdit to upload and post photos.
• Content ownership gives the flexibility to move photos between hosting providers. You can host on Micro.blog or WordPress or some future blogging platform without URLs breaking.
• Smaller social networks get us away from ad-based businesses that sell our data. Because Sunlit is powered by Micro.blog, you can even follow Mastodon or PixelFed users and see their photos in the Sunlit timeline.

I’m very excited about this release and hope you like it. It’s time to move away Instagram. If you need help importing your photos, check out this video I made about batch importing from Instagram to Micro.blog-hosted blogs.

We are getting close to releasing the next version of Sunlit. The app has gone through a bunch of iterations over the years while we searched for the right features and design. This version is my favorite. We’ve simplified posting so that it’s easier and more consistent with Micro.blog, improved profile screens, and fixed even more bugs.

If you’re looking for an alternate to Facebook-owned Instagram that priorities community and content ownership, I hope you check out Sunlit when it’s ready.

Apple responds to Spotify. Daniel Jalkut and I predicted most of this response on Core Intuition a couple days ago. I’m going to quote a few parts of Apple’s response and comment.

Eleven years ago, the App Store brought that same passion for creativity to mobile apps. In the decade since, the App Store has helped create many millions of jobs, generated more than $120 billion for developers and created new industries through businesses started and grown entirely in the App Store ecosystem.

Apple likes to brag about how much money they’ve paid to developers, but they leave out how much they’ve kept for themselves: about $50 billion. To Apple, they are doing us a big favor by letting us ship iOS apps.

We’ve approved and distributed nearly 200 app updates on Spotify’s behalf, resulting in over 300 million downloaded copies of the Spotify app. The only time we have requested adjustments is when Spotify has tried to sidestep the same rules that every other app follows.

It’s very important to remember that Apple’s rules are not laws. Apple’s rules have changed over the years, and especially around in-app purchase it often feels that they are applied inconsistently. Because Apple runs the platform, they can make any guidelines they wish, but there isn’t necessarily any inherent legal or moral justification in specific rules. We shouldn’t accept that all of Apple’s rules are fixed and cannot be improved.

When you get to the scale of the App Store, there are also new monopoly and anti-trust questions. For more about this, see Ben Thompson’s article on Stratechery.

Back to Apple:

A full 84 percent of the apps in the App Store pay nothing to Apple when you download or use the app. That’s not discrimination, as Spotify claims; it’s by design.

In 2011 I wrote a blog post with the premise that Apple made a mistake with how they handle free apps in the App Store, and what followed was years trying to make up for that mistake because of the burden of running the App Store. I think there was some truth to that, but now the business is very different. The App Store is a huge money-maker.

And we built a secure payment system — no small undertaking — which allows users to have faith in in-app transactions. Spotify is asking to keep all those benefits while also retaining 100 percent of the revenue.

And yet in the previous quote, Apple says that 84% of apps pay nothing and they are fine with that. Uber pays nothing to Apple. Games with ads pay nothing to Apple. Why is it wrong for Spotify to also want to limit how much they pay to Apple? The line Apple has drawn around in-app purchase is arbitrary. They could just have easily restricted Uber accepting payments, or banned third-party ads.

Just this week, Spotify sued music creators after a decision by the US Copyright Royalty Board required Spotify to increase its royalty payments. This isn’t just wrong, it represents a real, meaningful and damaging step backwards for the music industry.

This is irrelevant to Spotify’s complaints about the App Store. While I think Spotify’s argument would have been stronger if they had focused on a couple of their core complaints instead of mixing in issues such as Apple Watch development, Spotify didn’t bring up other concerns about Apple’s business that do not relate to the App Store. Apple trying to interject Spotify’s relationship with musicians is whataboutism.

Overall, Apple’s response isn’t very convincing to me. There are still 2 fundamental problems with the App Store: exclusive distribution and exclusive payment. In that post from 8 years ago, I concluded with:

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 think I’ve been proven right about this. This issue will never go away until Apple allows side-loading or makes it easier to let customers pay outside the App Store. In the meantime, I’ve been arguing for a 15% cut instead of 30% for all paid downloads and in-app purchase, which would go a long way to making this easier for developers.

We just sent a Sunlit beta to testers. This new version of our photo-blogging app includes an updated UI, easier posting, and fixes a number of issues. It also simplifies and removes several features, such as the filter and photo editing interface. (We may bring some features back later, but it was important to get back to basics and improve the core user experience.)

If you’d like to try it, you can join the TestFlight beta here.

I’ve been waiting years for this. Bigger companies have finally had enough of Apple’s 30% in-app purchase tax. Spotify founder Daniel Ek writes about Apple’s restrictions on telling users how to upgrade to Spotify Premium outside the app:

As an alternative, if we choose not to use Apple’s payment system, forgoing the charge, Apple then applies a series of technical and experience-limiting restrictions on Spotify. For example, they limit our communication with our customers—including our outreach beyond the app. In some cases, we aren’t even allowed to send emails to our customers who use Apple. Apple also routinely blocks our experience-enhancing upgrades.

Spotify has a companion site TimeToPlayFair.com with more details, and they’ve also filed a complaint against Apple with the European Commission. (As a side note, I hope Spotify’s pursuit of fairness will also apply to how they treat the podcast ecosystem after acquiring Gimlet Media and Anchor.)

Apple’s anti-competitive behavior was also a theme of Ben Thompson’s Stratechery this week:

What is even more striking, though, is that the App Store does have a massive antitrust problem: it is not Apple unfairly competing with app developers, it is Apple unfairly imposing massive complexity and extracting 30% of revenue with its contractual requirement, enforced by App Review, that developers use Apple’s payment mechanism.

Now if only more indie developers would speak out about this, maybe we’d make some progress with Apple. As I’ve said many times: 15% for paid downloads and in-app purchase is reasonable for the value that Apple provides. Just as importantly, Apple should relax the rules against linking to web sites outside the store.

Today is the 30th anniversary of Tim Berners-Lee’s proposal for the world wide web. Reflecting on the web’s success and the new challenges, he writes:

Against the backdrop of news stories about how the web is misused, it’s understandable that many people feel afraid and unsure if the web is really a force for good. But given how much the web has changed in the past 30 years, it would be defeatist and unimaginative to assume that the web as we know it can’t be changed for the better in the next 30. If we give up on building a better web now, then the web will not have failed us. We will have failed the web.

I believe this. The goal of Micro.blog is to make the web a little better. Let’s get back to what made writing and sharing photos online such a wonderful experience, and get away from the problems of the massive social network platforms that dominate so much of our activity online.

Micro.blog can now import blog posts from Medium. You can request a .zip archive of your content from Medium.com, then go to Posts → Import on Micro.blog to upload the file.

Because Medium no longer supports custom domain names, we don’t think it’s a good long-term solution for blogging. If you still want to reach your Medium followers, you can enable cross-posting from any blog to Medium in Micro.blog by clicking Account → “Edit Feeds & Cross-posting”.

Micro.blog does a few things to make transitioning from Medium to Micro.blog hosting easier. Just like the WordPress to Micro.blog import, it automatically downloads any photos referenced in your posts and stores them on Micro.blog. It also cleans up the posts a little, while preserving most of the original HTML. Of course it also sets post titles and published dates.

There was a session at IndieWebCamp Austin about broken links and archiving web sites. As part of the discussion, Tantek mentioned how he saves all his blog posts and tweets to the Internet Archive as part of his posting workflow. I’ve just added a setting like that to Micro.blog under Posts → Design:

This is off by default for now, but if you enable it, any new posts will be saved to the Internet Archive automatically. It waits about 5 minutes before saving them just in case you have any last-minute edits.

I still want to do more with archiving. As amazing as the Internet Archive is, I don’t think we should count on it to have a complete archive of the web. But this is a simple feature you can enable in your blog if it’s hosted on Micro.blog, and we can expand it based on feedback. (For example, maybe archiving pages you link to as well.)

Today Substack announced support for sending audio episodes in email newsletters:

Subscription podcasting through Substack works in the same way as publishing newsletters. Once the feature is enabled, you can create an audio post that is just like a normal post and can go out to everyone or only to subscribers. After receiving the post by email or accessing it on the web, subscribers can listen to the audio through the Substack web player.

This looks like a great feature for Substack customers, but it’s not a podcast. As the podcasting industry grows, with everyone trying to monetize podcasts or build new businesses around podcasting, it’s really important that we keep using the right words to describe it. A podcast has to have a feed so that it’s available in podcast players like Overcast, Castro, and Apple Podcasts.

Michael Zornek said it well earlier this week after Spotify acquired Gimlet and Anchor:

It is not a podcast unless there is a RSS feed.

I’m not splitting hairs about this. If we accept calling “any audio on the internet” a “podcast”, we undermine what makes a podcast unique: not just the convenience of delivering audio directly to your device, but the openness that ensures that podcasts work in a variety of players, without a single company with too much control trying to lock down the format.

Luckily, I think the Substack folks probably know this. In their announcement post, they also added:

We may soon add the ability to add a private feed of episodes to podcast players, but we like the web solution for now. (Give us your feedback, etc.)

Here’s my feedback: please don’t call it a podcast until you have the feed ready, whether it’s a private feed or public. When we added audio uploads to Micro.blog, we had full podcast feeds and everything was available from your own domain name. The web will be better if we encourage the same support of open formats in all new platforms.

We’re changing the official Micro.blog user accounts so that they are easier to follow. It used to be that everyone automatically followed @help, where we posted occasional announcements. From now on, @help will mostly be used for replying to questions, with a new default account @news.

You can unfollow @help if you don’t want to see those replies in your timeline. New users will no longer automatically follow @help.

Here’s a summary of the different accounts and blogs:

• @help: help.micro.blog
• @news: news.micro.blog
• @monday: monday.micro.blog

And for the Micro.blog team:

• @manton: manton.org
• @macgenie: micro.welltempered.net
• @cheesemaker: jonhays.me

In addition, Micro.blog user @simonwoods maintains 2 blogs with updates about Micro.blog and “Today I Learned” for tips:

• @til: til.micro.blog, updates.micro.blog

Email is still a great way to get an answer to a question, but by splitting out these accounts we can be more responsive on @help as well. I think this setup will work better as the community grows.

We released version 1.5 of the Micro.blog app for iOS today. In addition to a couple bug fixes, it lets you pick a category for new posts. You can create categories on the web under Posts → Categories for blogs hosted on Micro.blog.

Tap the gear icon when composing a new post to view your categories:

We are launching several major new features for blog hosting on Micro.blog today. Any one of these features alone is a big change, and together I hope they will serve as a great foundation for years to come. The goal was to make blog hosting faster and more flexible for new features.

Custom templates: All the themes have been rewritten with extensibility in mind. As some of you may know, Micro.blog-hosted blogs were originally built on Jekyll. They now use Hugo. There’s an interface in Micro.blog for editing any of the built-in templates, or adding new ones for your own HTML or CSS. Click Posts → Design → Edit Themes.

Categories: You can create a new category for your blog under Posts → Categories, and those categories will appear when editing a post or when creating a longer post with a title. We hide the category options be default when you are composing a short post, but in the new macOS app you can show the categories by choosing View → Categories. A list of your categories will appear at the top of Archive on your blog for readers to browse.

Auto-filter photos into a category: If you create a category like “Photos” or “Photography”, Micro.blog will offer to automatically assign this category when posting a new photo. Behind the scenes this is based on a new filtering system that will enable more features for other types of content in the future.

API for categories: I’ve added categories support to both the MetaWeblog XML-RPC API and the Micropub API. This means that categories work great with MarsEdit. Categories are also included in your default JSON Feed in the “tags” field.

Sharing themes: When creating a new custom theme, you can choose to clone it from an existing GitHub repository. This will allow someone to create a completely custom theme and share it with other members of the community. There’s a “Blank” design if you are starting from scratch with your own templates.

New theme: I used the open source theme Arabica when testing these new features, and it’s now an option under Posts → Design. It’s a clean, simple design ported from Ghost.

Open source changes: All our themes for Micro.blog are available on GitHub. I have decided to keep the forked Jekyll repositories and completely replace the files with the Hugo version. I have mixed feelings about this, since the themes have diverged so much that they are no longer useful to the original authors, but I felt this was the best way to give credit to them for the designs, in addition to our credits page on Micro.blog.

Moving special pages: Micro.blog has some special pages like “About” and “Archive”. You can now re-order or even delete these under Posts → Pages. Combined with custom themes, this gives much more flexibility in customizing the navigation for your site.

We’ll be writing more about these new features in blog posts and the help site. If you notice any problems, please let me know. Thank you!

We can come up with all the specialized names we want — photo blogs, link blogs, travel blogs, microcasts — but sometimes it’s just a blog. To wrap up the 12 days of microblogging series, let’s talk about blogging.

Blogs can be news sites, corporate sites, travel sites, photo sites, tech sites, and personal journals. They are usually written in an individual’s voice. Readers want to keep visiting a blog because there’s a story, unfolding with each post. The passing of time is a fundamental element to what defines a blog.

This emphasis on time is even more obvious for microblogs. Because short posts are easy to write, there are more of them. But Micro.blog hosting supports any post length: short microblog posts like tweets, or full blog posts with multiple paragraphs and a title.

Micro.blog is a full blogging platform, so it has support for traditional blog editors like MarsEdit on macOS. You can import an archive of posts when migrating from WordPress. Because Micro.blog posts are full blog posts, they support editing, using Markdown or HTML, and natively have RSS and JSON Feeds. They support features you would never expect on a social network, like using a custom domain name or uploading a PDF.

But along with this blogging foundation, Micro.blog tries to learn from the user experience of social networks. Can we make blogging much easier, so that it’s your primary home on the web, and the first place you think to post? There are still many improvements we want to make so that the platform is easier to use and more consistent, but I think the last year has shown that the answer is “yes”. Blogging can be easier, and if it’s easier, more people will do it. And if more people are blogging, we can start to find our way out of the problems created by massive social networks.

That wraps up our 12 days of microblogging series. You can find links to all the posts on the help site.

We’ve seen a lot of people use their microblog as a daily log to track activities, from running or cycling routes, to meditation or posting photos of food. Some apps even make this easier, like indiebookclub.biz for sharing reading progress in a book.

In 2016 when I visited a different library in Austin every day, I found that the microblog format is helpful to stick to a routine. It becomes part of the day, knowing you need a quick post to your blog to record the visit or activity. Encouraging this kind of posting consistency is also why we have special pins you can unlock, such as the “Photo Challenge” pin after posting a new photo each day for a week.

For the last 11 days I’ve been writing about the way people are using Micro.blog: custom designs, microcasts, photo blogs, and more. You can find the rest of the posts in this 12 days of microblogging series over on the help site. Tomorrow we’ll wrap up with a final post.

I woke up this morning, picked up my phone like I always do — to make sure that Micro.blog servers hadn’t quietly burned to the ground in the middle of the night — and the first thing I saw was a notification about Apple’s new campus in Austin. Here’s John Voorhees writing about it for MacStories:

At the center of the announcement though is a new facility that will be located in North Austin not far from Apple’s current Austin campus. The new office will cost over $1 billion to build and sit on a 133-acre site, 50 acres of which will be set aside for open space. Initially, the Austin campus will house 5,000 employees, with the ability to expand to as many as 15,000. The new complex will run on 100% renewable energy too.

I love the contrast to Amazon’s over-hyped search for a 2nd major campus. Apple made a decision and announced it, without leaving the world hanging for months. While Apple has always had other smaller offices outside Cupertino, it’s great to see such a significant new commitment in other parts of the country.

Does anyone know the location for the campus yet? Near the current campus in Austin there are huge stretches of undeveloped property — old ranches that you can see along Parmer Lane or from the other side when taking the train from Lakeline Station. For years I’ve dreamed that this area could be preserved somehow as a park, not just eventually overrun with condos and restaurants. I’m excited that Apple is setting aside 50 acres of the new campus for open space. I hope they consider expanding that even more.

Update: This KUT article has a map of the planned campus.

It’s the 10th day of our 12 days of microblogging series, and today we want to highlight some of the authors who are using Micro.blog. Last month was National Novel Writing Month, and many posts about NaNoWriMo were collected in a special section of Discover on Micro.blog. Congrats to everyone who participated!

Serena finished the month with 50,344 words. Cheri Baker posted updates about her writing and announced her new novel. And for non-fiction, Rosemary Orchard has a new book about OmniFocus.

Josh de Lioncourt is another member of the community who has participated in NaNoWriMo. He joined Jean earlier this summer on the Micro Monday podcast. On Halloween this year, Josh recalled his first NaNoWriMo from 2013:

I’d promised myself that if I finished chapter one that night, I’d continue writing the rest of the book throughout the month of November as a NaNoWriMo project. As it turned out, I did finish chapter one. The next day I wrote chapter two, and by the end of November I had nearly sixty thousand words, fifteen chapters, and about one-third of what would become Haven Lost written in first draft.

We love books and want to do more to support writers. As I wrote about at the beginning of the year when introducing the emoji collections, we started with books:

Today we’re introducing a search collection using emoji, starting with books. Just include ? with your microblog text about a book you’re reading or related topic, and your post will automatically be collected on /discover/books.

For more posts in this series, check out our help page.

For the 9th day in our 12 days of microblogging series, we want to talk about developer blogs. Most developers on Micro.blog use their blogs like everyone else — posting photos, sharing stories, recording a microcast, or linking to articles they’ve read — but some developers use the microblog format as a programming journal, writing about coding problems and eventual solutions through a series of posts.

Brent Simmons helped popularize this format in the iOS developer community back in 2013 when he published 16 posts while working out how to implement syncing. I’ve noticed at least a few developers adopt a similar format during the development of Micro.blog third-party apps, such as Isaiah Carew working on Kiwi earlier this summer, Vincent Ritter on Gluon, and Mike Haynes designing Dialog.

Blogging is a great way to work through an idea. When you take time to write a few sentences or paragraphs about an opinion on almost any topic, you’ll find that you have a stronger understanding of it by the time you hit publish. It can be the same way for a programming challenge.

There have already been 8 other posts in this series, and we link to all of them over on the Micro.blog help site. Three more posts to go this week to finish out the 12-post series!

Micro.blog’s default design for hosted sites is based on an original theme that shipped with Jekyll. It is very plain, but works well on desktop computers and mobile devices. It’s also pretty easy to customize.

I recently set up the new Micro.blog news blog and wanted to apply a few minor improvements to the design: adding a logo to the header and fixing how cramped the quoted text looked. To add a logo to the header, you can use CSS to shift the text to the right, making room for the logo, and then add the logo as a non-repeating background image.

Here’s what my custom CSS looks like:

blockquote {
	letter-spacing: -0.5px;
	line-height: 1.6;
}

.site-title {
	background-image: url(https://help.micro.blog/assets/images/icons/ios/icon-60.png);
	background-size: 30px 30px;
	background-repeat: no-repeat;
	background-position-y: 12px;
	padding-left: 40px;
}

You can edit the custom CSS for your blog by clicking Posts → Edit Domain & Design → Edit CSS. I also posted during out 12 days of microblogging series about other custom designs from Micro.blog users.

It’s the 8th day in our 12 days of microblogging blog post series. Most Micro.blog accounts use the author’s name — personal blogs, writing about everyday topics or sharing stories and photos. But since Micro.blog-hosted blogs can have a custom design, separate pages, and a domain name, you can also have a microblog for your business, or use it as your main web site.

Because one of the goals of Micro.blog is to encourage people to post to their own blog more often, using a blog for your business site can also help keep it up to date, so that when customers visit there is recent news or product updates. The Omni Group has taken this one step further for their microblog at microblog.omnigroup.com, posting not just links to new software releases and screenshots of features, but also fun stuff like what they’re having for lunch at the office and cat pictures.

For Micro.blog, we realized recently that we were missing a company blog. We have the help account and we have my personal blog, but not everyone should have to follow me to get important news such as the latest iOS update or even the blog post series you’re reading now. So today we’re adding a new blog: news.micro.blog.

This new microblog will mostly link to other blog posts from me or Jean or Jon, as a way of collecting everything in one place. As we expand it, we’ll integrate it into the help site and Micro.blog home page.

Previous posts in this series included topics like podcasting, photos, travel blogs, and sharing your content to other social networks, which is particularly useful for business blogs. See the full list here.

For the 7th post in our 12 days of microblogging series, I want to talk about linkblogging. Micro.blog users have a variety of approaches to posting links on their blog. Some people read an interesting article and type in a summary of it, pasting in the URL to the full article, and some people prefer quoting a portion of the text directly in their microblog post.

I blogged a couple of years ago in detail about the technical approaches to links in RSS and how linkblogging has evolved, using examples from Dave Winer and John Gruber:

Instead of just including a URL, authors use a quote from the linked material as the foundation for the post. The majority of Daring Fireball posts adopt this format. While John Gruber is known for his full essays, those longer posts are infrequent today. He keeps his site active by linking to other interesting essays and tacking on his own brief opinion.

Posts on Micro.blog are formatted with Markdown. If you’re reading a web page on iOS, you can share it to the Micro.blog app to automatically fill in the basic structure of a post, leaving the cursor at the beginning of the post to add your own thoughts.

In the screenshots above, I’m sharing from Safari on iOS. Micro.blog adds a Markdown link back to the original post with the web page title. Or if there’s text selected, Micro.blog includes that text as a quote.

Note that Micro.blog will truncate posts in the timeline when they are over 280 characters. For a longer quote, it’s best to give you microblog post a title, turning it into a full blog post.

Previous posts in this blog post series covered photo blogs, microcasting, travel blogs, custom designs, artwork on blogs, and more. Check out the full list on our help page.

I love road trips and travel blogs. We have a family blog that we started a few years ago, adding new daily posts for summer vacations with the kids and other trips. A blog is a great way to combine text and photos to remember a trip, with the flexibility to keep it for yourself or share it on social media.

For the 6th day of the 12 days of microblogging series, we wanted to highlight 2 travel blogs using Micro.blog. Mary Hatfield writes on her microblog with incredible photos of trips across the United States and even to Antarctica:

When we woke up this morning we were in the Neumayers Channel (below Anvers) located on the western side of Wiki Island ready to take the zodiacs onshore. The weather was quite perfect this morning and it was our turn […] We walked across the fresh blanket of snow to the Damoy Hut, which was built in 1975 and kept in use until 1995.  It has now been restored to its original form and is used as a museum. The land here was an airstrip that enabled personnel and stores arriving by ship to be flown on to Rothera Station in early summer when sea ice prevents dirt access to the station by ship

Arin Mearig kept a daily blog for a 3-month trip to Switzerland, posting photos every day with captions for people she’s met and places she’s visited. From day 34:

quick recap - left the house at 5am, went to 4 cities, hitchhiked for the first time, went on buses, trains, cable cars, and a funicular, ate a delicious burger, saw some of the greatest views ever, and just walked in the door at 10:45pm

I’m inspired by these blogs to write more while traveling. Consider capturing some of your next trip on an existing blog or new microblog.

See this help page for previous posts in this serious, covering topics like photos, microcasting, custom designs, and more.

It’s day 5 of our 12 days of microblogging series. Yesterday I highlighted what Micro.blog users are doing to create unique custom designs for their blog. Today we want to highlight how artists are using Micro.blog to showcase their work.

I’ve loved seeing the drawings from Audra Ann Furuichi, who posts web comics and illustrations on her own site. Sky Sandison has sketches from around Edinburgh, Scotland. And Mike Hendley shares digital paintings as he works through them on his iPad.

Plus there’s great sketchnotes from Mike Rohde and Ben Norris, including one by Ben about my talk from Peers Conference earlier this year.

October was also Inktober, with many bloggers posting sketches to their microblogs every day. We have a special section of Discover for Inktober that collects many of those posts together.

While the iOS apps for Micro.blog are designed around JPEG photos, you can use Micro.blog on the web to upload other formats like PNG and GIF, which might be more suitable for illustrations. Just click Posts → Uploads.

Showcasing artwork on Micro.blog uses many of the same features as photo blogs, which I wrote about on day 2 of 12 days of microblogging. For previous posts in this series, check out our help page on Micro.blog.

It’s day 4 of our 12 days of microblogging series. Today we want to highlight how Micro.blog supports blog themes and what people can do to give their blog a unique design.

There are 3 ways to customize your microblog:

Pick from one of the default 7 themes. These themes are based on existing designs using the Jekyll blogging framework, but modified to work consistently with Micro.blog. We’ve open-sourced all our changes to these themes on GitHub.

Edit the custom CSS for your blog. I’ve been really impressed with what creative Micro.blog users have come up with. You can use CSS to change colors, fonts, hide elements, and more. Here are a few examples from Kitt Hodsden, Michael Barrett, and Khaled Abou Alfa.

Add a custom footer. The footer HTML is a good place to put extra information or JavaScript.

If you have any questions about using CSS, ask in the #design channel on Slack. And if you have any tips, write about it on your blog so that others can learn from it. I’m currently working on a major upgrade to the themes on Micro.blog that I can’t wait to share more about.

Previously in the 12 days of microblogging series, I wrote about microcasting, photos, and using your own blog as a home base.

For the 3rd post in our 12 days of microblogging series, we want to highlight how Micro.blog can serve as your social media “home base”. By centralizing your writing, photos, and other web pages at your own domain name, you can control your content but still share it out to other social networks.

Micro.blog has cross-posting for Twitter, Medium, LinkedIn, Facebook, and Mastodon. This feature is available for free if you host your site on Micro.blog, or $2/month if your blog is hosted elsewhere. It includes automatic posting to all 5 of those social networks and any new platforms we may add later.

Here’s how I personally use this feature. I never post directly to Twitter. I publish short posts on my own blog, and Micro.blog automatically sends them to Twitter and other networks. Occasionally I’ll sign in to Twitter and check if I have any @-mentions that need replying to. This way I can avoid the distraction of the Twitter timeline and focus on adding content where it’s most important to me: my own site.

With Mastodon, you have another option beyond cross-posting. Because Micro.blog supports the ActivityPub API, Mastodon users can follow your Micro.blog-hosted blog and you can follow and reply to Mastodon users directly in Micro.blog. I posted more last month about how this works and why it uses your own domain name:

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.

Your blog is also a great place to centralize your photos, while still integrating with Instagram and these other social networks. Instagram doesn’t allow automatically posting from your blog to their service, but you can use OwnYourGram or our Mac app to copy Instagram photos to your blog, and from your blog to everywhere else. More links in yesterday’s post.

For details on how cross-posting works — and the extra rules Micro.blog uses to make sure that your posts look good on other networks — see this help page. Happy cross-posting!

Yesterday we started the 12 days of microblogging blog post series to mark the 1-year anniversary of the public launch of Micro.blog. I posted about making it easier for people to share their stories in audio form with microcasting. Today I want to highlight photoblogging.

Sharing photos is an important part of Micro.blog. I put a custom photo picker and filters in the original Micro.blog iOS app to encourage everyone to post photos to their blog, so that you end up with a great collection of your best photos at your own domain name. Because photos are square by default, they look great in the Micro.blog timeline, and with cross-posting Micro.blog can attach photos to your tweets or send posts to other social networks.

We also have a companion iOS app just for photos called Sunlit. It has an Instagram-like timeline for browsing photos from your Micro.blog timeline, with the focus around blogs that I wrote about in my preview post as we were relaunching Sunlit 2.0:

To play nicely with microblogs, we introduced a new post type in the app for single photos. For longer posts, you can still collect multiple photos together, add text, and post them as a story directly to your blog.

Some people on Micro.blog focus almost exclusively on posting photos, like Robert Brook. Some people have even created separate blogs just for their photos at their own domain name hosted on Micro.blog, like burk.photos. There’s a special section of Discover that features photos from more Micro.blog users.

A couple of weeks ago, Jonathan LaCour on Micro.blog submitted a feature request for a photos JSON Feed. He used this feed to build Microgram, a snippet of HTML that you can paste into your blog to provide a grid of photo thumbnails. You can see my photos page at manton.org using Microgram in this screenshot:

One of the most common questions we get is how to migrate photos from Instagram to Micro.blog. I think we have 2 really good options for this:

• Micro.blog for macOS has a built-in Instagram importer. It will take the archive you get from Instagram and allow you to batch import your Instagram photos to Micro.blog, preserving the original dates and text from Instagram.
• OwnYourGram is a web-based app that connects to your Instagram account to automatically copy new Instagram posts to your own blog. Because it’s based on IndieWeb standards, it can also post directly to Micro.blog-hosted sites.

I hope you enjoy posting and browsing photos on Micro.blog! Tomorrow I’ll have the next post in the 12 days of microblogging series.

One year ago today, after months of feedback from Kickstarter backers, we opened up Micro.blog to the public. In that time, we’ve watched the community grow, seeing more folks than ever writing on their own blogs while sharing in the Micro.blog timeline and participating in conversations. We are proud of maintaining our commitment to a safe community space where harassment is not tolerated while promoting independent blogging.

We’ve also added a lot of functionality to the platform during this first year. To mark the anniversary, we are highlighting 12 features of Micro.blog over the next 12 days. We’re kicking off the 12 days of microblogging with a major hosting feature that rolled out earlier this year: microcasting.

What are microcasts? Just short podcasts. A major idea behind Micro.blog is that if blog posts are shorter and easier to post, more people will stick with writing on their own site every day. Podcasting should be easier too.

As I wrote when announcing microcast hosting and our companion app Wavelength:

Everyone has a story to tell. Whether that’s through short microblog posts, longer essays, photo blogs, conversations with friends, or now through podcasts, I hope that the Micro.blog platform and suite of apps can help.

I’ve been so excited to see new podcasts launch on Micro.blog, including our very own Micro Monday hosted by Jean MacDonald. For today’s episode, Jean interviews long-time blogger and Mac developer Brent Simmons about his podcast The Omni Show and working on the new NetNewsWire feed reader.

You can find recent episodes from a variety of microcasts in the Discover section of Micro.blog. Also check out Microcast.club, a directory of microcasts. Get started with your own microcast with this help article and join our Slack community where the friendly folks in the #microcast channel can help with questions.

Tune in tomorrow for day 2 of our 12 days of microblogging series.

Excellent article today from Ben Thompson. After laying out in detail why Apple has a strong argument in yesterday’s Supreme Court hearing, Ben moves to the larger question of the App Store monopoly:

To put it another way, Apple profits handsomely from having a monopoly on iOS: if you want the Apple software experience, you have no choice but to buy Apple hardware. That is perfectly legitimate. The company, though, is leveraging that monopoly into an adjacent market — the digital content market — and rent-seeking. Apple does nothing to increase the value of Netlix shows or Spotify music or Amazon books or any number of digital services from any number of app providers; they simply skim off 30% because they can.

I’ve been saying for years that the 30% cut is completely out of line with the value that Apple provides to developers. Developers should be calling for a more fair 15% rate across the board for all apps, and more flexibility to sell subscriptions outside the App Store. As I wrote earlier this summer, it shouldn’t sit well with developers when Apple talks about billions in services revenue, at our expense.

As I mentioned on this week’s episode of Micro Monday, we want to add category support to Micro.blog including a special section for photos. As a first experiment with a page for photos, I added a JSON Feed of your photos to all hosted blogs on Micro.blog yesterday at /photos/index.json. (It will be updated automatically next time you post to your blog.)

Jonathan LaCour wrote a JavaScript include called Microgram to take that feed and display a grid of photos. You can see it in action on my blog here.

We still want to do more on Micro.blog with photos, but this is a great solution that’s available today. And I think it shows off how JSON Feed makes these kind of integrations much easier. Thanks Jonathan!

I often say that Micro.blog is a success if more people blog. One of the most important goals is to encourage people to post at their own domain name. For more about why that matters and what I think Micro.blog’s role is among other social networks, see my post about the way out.

But we hear from a lot of people who want Micro.blog to succeed in more concrete terms as well. They want it to be a larger business that can hire more developers and curators. I want that too! Micro.blog is the most ambitious platform I’ve built and as it grows we will need more help scaling it.

If you believe in what we’re trying to do with Micro.blog, here are a few simple ways to support the platform:

• Subscribe to one of the blog hosting plans. You get your own domain name, themes, photo or podcast hosting, the new Mastodon-compatible support, and much more. This is what I use to host my own blog and podcast.
• Give a friend a blog subscription. If you already have a paid subscription yourself, click Plans → “Give Micro.blog” to invite someone to Micro.blog and pay for their first year of blog hosting at a discount.
• Tell everyone what you like about Micro.blog. We don’t have any gimmicky viral features to spread the word automatically. For other people to find out about Micro.blog, you’ll have to post to your blog, tweet a link, or talk about it on your podcast.

We are approaching 2 important milestones: the 1-year anniversary of the public launch, and nearly 2 years since the Kickstarter. Micro.blog has improved significantly since then and it will continue to get better with your support. Thanks!

Josh Marshall of Talking Points Memo has written some good posts about Facebook this year. Here’s part of today’s post about trust:

Facebook’s core problem is that it was a platform based on trust. I don’t mean it acted in a trustworthy way. But it facilitated things that were at core about trust and relationships. So it was in the trust business, regardless of what its corporate culture may actually have been about. Having failed at that and not convinced people it’s trustworthy it now seems committed to a corporate version of acting out, going to war with its own stakeholders, whether those are users, investors, the governments of the countries in which it operates.

See also my post last week about breaking up Facebook and the eventual pushback against Facebook-owned Instagram.

We start this week’s Core Intuition by following up on the Mastodon integration in Micro.blog. From the show notes:

Manton reports back to Daniel about the first week after adding Mastodon integration to Micro.blog. They talk about the merit and necessity of spending time marketing after all the coding work we do. Daniel talks about his recent struggle implementing support for Google’s OAuth2, and finally they talk about Apple’s new Hardened Runtime and the associated app notarization service Mac apps that are distributed outside the Mac App Store.

It’s nice to hit episode 350, but I was just listening to ATP’s 300th episode today and realized that they have reached their milestone in about half the number of years that it took me and Daniel. We didn’t record very often in the early years, and even now usually miss a couple weeks here and there, so I expect ATP will eventually pass us up in total episodes. 🙂

Two related articles about Facebook this week. First, from a huge report in The New York Times:

But as Facebook grew, so did the hate speech, bullying and other toxic content on the platform. When researchers and activists in Myanmar, India, Germany and elsewhere warned that Facebook had become an instrument of government propaganda and ethnic cleansing, the company largely ignored them. Facebook had positioned itself as a platform, not a publisher. Taking responsibility for what users posted, or acting to censor it, was expensive and complicated.

The New York Times interviewed over 50 people for the story, and it shows. There are a lot of interesting behind-the-scenes stories, especially Facebook’s relationship with Washington, and more than I can quote here.

Second, an article from The Washington Post about early Instagram employees becoming disillusioned with the platform:

Three of the early Instagram employees, including Richardson, have deleted it — permanently or periodically, comparing it to a drug that produces a diminishing high. One of the people said he felt a little embarrassed to tell people that he worked there. Two of the other early employees said they used it far less than before.

This is why I don’t ever want to sell Micro.blog. I can’t imagine having to sit on the sidelines and watch with disappointment what it might become if it drifted away from its mission.

I think pushback against Instagram is coming, as more people who have already left Facebook also remember that Instagram has the same leadership, and the platform is far enough off track that even the founders have left. It’s a good time to be posting photos to your own blog instead of Instagram.

In a post earlier this year, Ben Thompson recognized that the threat to Facebook is when it becomes accepted fact that using the app isn’t good for you:

It follows that Facebook’s ultimate threat can never come from publishers or advertisers, but rather demand — that is, users. The real danger, though, is not from users also using competing social networks (although Facebook has always been paranoid about exactly that); that is not enough to break the virtuous cycle. Rather, the only thing that could undo Facebook’s power is users actively rejecting the app.

Having your own domain name for blog posts and photos isn’t just about personal independence from the control of massive social networks. Owning our content is key to the way out of the current social network mess.

Some may call for Facebook to be broken up because it has too much power. But we can’t count on antitrust law to do it. Users must do it. We must do it by moving our attention away from companies we don’t believe in.

Last week we launched support for the ActivityPub API in Micro.blog. This is a major feature to add compatibility with Mastodon, including:

• Mastodon users can follow posts from your blog using a username like @you@yourdomain.com.
• Mastodon users can reply to your posts, and those replies will show up in your Micro.blog timeline.
• You can follow Mastodon users from within Micro.blog.
• You can reply to Mastodon posts in Micro.blog, and those replies will also flow back to Mastodon.

Unlike cross-posting (which Micro.blog also supports), enabling ActivityPub in Micro.blog does not use a separate Mastodon account. Everything can be accessed from within Micro.blog using your custom domain name as your web identity. I’ve mostly been testing with Mastodon, but as we continue to test and improve this feature it should also work with non-Mastodon ActivityPub servers.

There are a few steps to get started:

1. Pick a custom domain name. For me, this was easy: I wanted to use manton.org.
2. After setting up Micro.blog to host your blog, point the domain name to Micro.blog. We have a help page about this.
3. Micro.blog will send an email when SSL is enabled for your blog. If there are any delays, don’t hesitate to email us at help@micro.blog and I will make sure your blog is updated and ready for ActivityPub.
4. Click on Account → ActivityPub → “Set Mastodon-compatible Username”. Here you can choose what username other Mastodon users can find you with.

Thanks to everyone who has already tried enabling this on their Micro.blog account! We have learned a lot and fixed several bugs with conversations across both platforms. Looking forward to where this goes.

Earlier this year I migrated 15 years of posts on manton.org to Micro.blog blog hosting. Today I finished moving over 100 episodes of my podcast Timetable to Micro.blog podcast hosting. I had gotten out of the routine of recording Timetable, and I think moving it to Micro.blog will simplify the setup and make me publish the podcast more often.

Timetable had been hosted on WordPress using the Seriously Simple Podcasting plugin. There were at least a few ways I could’ve moved the episodes, but ultimately I decided on the following:

1. Downloaded all the MP3s to my Mac.
2. Adjusted the WordPress settings to show 120 recent posts in the feeds, then saved the resulting JSON Feed of all episodes. This let me parse the JSON much more easily than working with the WordPress API or XML.
3. Wrote a Ruby script that uses the Micropub API to upload each MP3, then create a new post with an audio tag, preserving the original post content and date.
4. Pointed timetable.manton.org to use Micro.blog.

Even if you don’t know Ruby, hopefully you can see in the script how easy is it to work with Micropub, which Micro.blog uses as its native interface to create posts and upload files. I just call out to the curl command-line tool to do the work.

If you’re new to Timetable, each episode is only about 5 minutes. Some of my recent favorites include episode 91 (Lose yourself), episode 92 (Good, better, best), and episode 100 (One year).

Last year we held the first IndieWebCamp in Austin. I blogged about how the event went, including sessions and topics covered, and what I learned from it:

I’m really happy with the way the event came together. I learned a lot in helping plan it, made a few mistakes that we can improve next time, but overall came away as inspired as ever to keep improving Micro.blog so that it’s a standout platform of the IndieWeb movement.

We’re going to do it again early next year: February 23-24 at Capital Factory. If you’ll be in Austin, mark that weekend on your calendar. I’ll make another announcement when registration is open.

Last year there was a lot of work and last-minute stress deciding on a venue, so this year we’re going to keep a bunch of things the same that seemed to work pretty well. By nailing down the details early, we’ll have much more time for promotion. I’d love to see us double attendance from last year. Hope to see you there!

Micro.blog now has 3 distinct styles of usernames to make the platform more compatible with other services:

• Micro.blog usernames, e.g. @you. These are simple usernames for @-mentioning someone else in the Micro.blog community.
• Mastodon usernames, e.g. @you@yourdomain.com. When you search Micro.blog for these usernames, Micro.blog will look for the user in another federated Mastodon instance so that you can follow them.
• IndieWeb-friendly domain names, e.g. @yourdomain.com. This is where I always thought we’d go for more distributed “the web is the social network” interactions. Replying to one of these usernames will send a Webmention to that user’s external web site.

I’m @manton on Micro.blog, my blog is manton.org, and because Micro.blog-hosted blogs support the ActivityPub API, you can follow me from Mastodon by using @manton@manton.org.

I just rolled out some ActivityPub-related reply improvements. I’ll continue to improve the Micro.blog timeline so that these usernames can all coexist nicely. We’ll also be updating the native apps to better support these usernames, for highlighting and auto-completion.

For some time, we have been considering how we could open up compatibility between Micro.blog and Mastodon. Any feature that could be disruptive needs to be approached carefully. In this post I want to talk about how Micro.blog supports Mastodon, why I think it’s useful, and anticipate some questions that we’ll get about this feature.

We’re launching 2 major features today:

• Micro.blog can now cross-post to a Mastodon user account, in the same way we cross-post to Twitter, Facebook, Medium, and LinkedIn. This takes a copy of your blog posts and sends them to a specified Mastodon account.
• Your custom domain on Micro.blog can now be ActivityPub-compatible, so that you can follow and reply to Mastodon users directly on Micro.blog. This also means someone can follow your blog posts by adding @you@yourdomain.com on Mastodon. (This username is configurable. Mine is @manton@manton.org.)

These 2 features are separate and either can be enabled if you want. I have tried to be very deliberate in how ActivityPub is implemented. It is off by default, and to keep the focus on blogging and content ownership, it only works with custom domain names.

One of the most important goals for Micro.blog is to encourage more people to blog. I wrote last year that it’s a success if more people blog. Based on the feedback we’ve received from the Micro.blog community, we are making great progress toward that goal.

We have a lot of things we want to help solve with Micro.blog, but blogging is a core part of the foundation. It’s not about being the most popular social network. It’s not about competing with every platform that launches. It’s much better for the mission of Micro.blog for us to embrace other platforms (as we’ve always done with the IndieWeb) rather than put up walls between APIs.

I recently published a post with 4 parts to how we get out of the current mess with today’s big social networks. I mentioned Mastodon in that post because while I don’t think Mastodon tackles all 4 parts of fixing this, I do think it has a role to play.

More compatibility with Mastodon lets us support the good things that Mastodon has accomplished, while still carrying forward what I think are the unique strengths of Micro.blog. It also opens up the Micro.blog community to interact with a much larger user base.

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.

As I wrote earlier this year, content ownership on the web is about domain names:

When you write and post photos at your own domain name, your content can outlive any one blogging platform. This month marked the 16th anniversary of blogging at manton.org, and in that time I’ve switched blogging platforms and hosting providers a few times. The posts and URLs can all be preserved through those changes because it’s my own domain name.

If you already have your blog on Micro.blog at yourdomain.com, we can build on that to allow @you@yourdomain.com or @whatever@micro.domain.com. This focus on domain names will continue to guide new features in Micro.blog.

Let me answer some questions:

• How is Mastodon support enabled on my account? In Micro.blog on the web, click Account → ActivityPub. You will be prompted to select a username. A paid hosted microblog is required so that Micro.blog can use your custom domain name.
• How can I find Mastodon users to follow on Micro.blog? As more Micro.blog users interact with Mastodon users, some of those users will naturally show up in conversations or even be featured in our Discover timeline. You can also add a specific Mastodon user by searching for their full username.
• Will Micro.blog now start showing follower counts? No, it’s important to me that we don’t change the Micro.blog user experience to resemble every other social network. When you follow a Micro.blog user from Mastodon, an individual Mastodon instance will have its own follower count just for that instance. Any follower count shown in Mastodon for a Micro.blog user will be wrong. This isn’t ideal, but it’s the best we can currently do with how Mastodon works.
• What about Content Warnings? Micro.blog does not support them. I’ve heard from Mastodon fans who like Content Warnings, but I’m concerned about introducing extra friction in both the posting and reading experience. We’ll reevaluate this feature later.
• What happens to direct messages sent from Mastodon to Micro.blog? Micro.blog does not have any private posts by design. Direct messages sent from Mastodon are converted into a private email.
• Is this going to make Micro.blog just like Mastodon? No, this is not a clone of Mastodon merged into Micro.blog or running alongside it. It’s a from-scratch implementation of a few common APIs that Mastodon uses so that both systems can talk to each other.
• Will third-party Mastodon clients work with Micro.blog? Not currently. We might consider this later, but because of the UI differences, I think it’s a better fit to have third-party apps designed for either Micro.blog or IndieWeb standards.
• What will happen to the Micro.blog community? I hope that this will help grow the community, without taking away from what has worked well on Micro.blog. While you might see some Mastodon posts, and those Mastodon users can interact with Micro.blog users, users from other Mastodon instances won’t know about our community guidelines or expectations for Micro.blog. The community will remain predominantly Micro.blog users who share our goals for the platform.
• How does Micro.blog’s mute feature work with Mastodon? Muting in Micro.blog has been expanded to support muting individual Mastodon users, or entire Mastodon instances based on their domain name. We have also preloaded a common list of Mastodon instances that are muted automatically because of code of conduct violations.

This is a really big feature. I hope you enjoy it! This is just the baseline. I’ll be working on bug fixes and improvements to make this integration work as smoothly as possible. If you have any feedback, let me know at help@micro.blog.

Seth Godin on daily blogging:

For years, I’ve been explaining to people that daily blogging is an extraordinarily useful habit. Even if no one reads your blog, the act of writing it is clarifying, motivating and (eventually) fun.

As he says, you’ve gotta get past the first couple hundred posts to see the most value. This is why indie microblogging is so useful. Start with some short posts, a few photos, and eventually it’s a habit. Stick with it and you’ll really have something.

In Micro.blog we have some pins to encourage people to blog more often. You’ll unlock pins after your first photo, 10 posts, setting up a custom domain, and more. Today, if you mention “Halloween” or “pumpkin” in a blog post you’ll unlock the special Halloween pin.

Micro.blog doesn’t have hashtags, trending topics, or retweets because I think the focus on those features in other social networks has led to people being exposed to harassment, hateful posts, and even fake news. For Micro.blog, it’s more difficult to accidentally stumble on a random post unless it’s part of a conversation you’re in or from a section that is actively curated.

This was an important design decision and we’re not walking away from it, but the downside is that it is more difficult to find older posts without a global search. As the first step in improving this, today we’re rolling out a new search screen. You can now search for users and across any post that has been featured in the Discover section.

Click on Discover from the web version of Micro.blog. I’ll continue to improve this throughout the rest of the year, expanding it to more posts, including in the native apps. Looking forward to hearing your feedback!

The Atlantic, quoting Ben Grosser, after news that Jack Dorsey is reevaluating whether Twitter should even have likes:

“Part of what’s happening in spread of disinformation is that people can essentially repeat what someone else said and spread it to the world, the retweet has an effect well beyond the Like in that regard,” he said. Grosser also indicated that removing just the like button would only make the retweet more powerful. “I fear that if they remove the Like button the fact that there are other indicators that include metrics will just compel users to use those other indicators,” Grosser said.

Removing likes and retweets is of course old news to anyone who has been on Micro.blog. I wrote 2 years ago about the potential harm of retweets. It’s a common theme in the talks I’ve given and in other blog posts since.

When I first started rolling out Micro.blog to early supporters, not having public likes, retweets, or follower counts was a kind of controversial, risky decision. Now it’s almost boring. We’re in the middle of 2 complementary transitions: a move away from massive social networks, and smaller platforms providing the flexibility to remove features and algorithms in service to the community.

A few months ago on Timetable, I talked about how Micro.blog needs the equivalent of a college orientation session to get new people used to how the platform works. I took some time this morning to record a quick intro screencast video. It’s a little rushed because I tried to fit it into 2 minutes, but I’m glad to finally have something. I’ll be working to update it soon.

I’m adding a link to the video at the top of the “welcome” email that new users get when they sign up. You can also watch it on the help site here.

Project Gutenberg is the code name for a redesign of the WordPress post editor. It’s an ambitious change set to ship next month in WordPress 5.0. Taking inspiration from Medium and appealing to web authors who use WordPress more like a CMS than a blog, Gutenberg features a block-based design for visually laying out the text and elements of a web page.

As I test Gutenberg, I keep coming back to one question: is it good for blogging? The goal with Micro.blog is to make blogging easier so that more people will have their own site instead of delegating their web identity to a social network. Gutenberg is more flexible than today’s WordPress, but it’s also more complex for someone who just wants to type in a few sentences and hit publish.

I’ve been talking about this with Daniel on our podcast Core Intuition. Many WordPress users will love Gutenberg, but there will be a significant number who just want a simple posting interface for blogging. This is where a traditional native blogging app like MarsEdit or the focused UI around microblogging seem like much better fits.

Put another way, as WordPress matures I think it moves further away from the ideal blogging interface for someone who wants to write every day. Even as we add features to Micro.blog — domain names, themes, full-length posts, photos, podcasting — the core platform will always be rooted in the simple idea of a text box and a timeline.

Sometimes I hear from people who decide Micro.blog isn’t for them because it’s “just for bloggers”. On the one hand, they aren’t wrong; it is partly a blog hosting platform. But I think that feedback reveals less that there’s a fundamental mismatch and more about how much we still need to improve the user experience. One of the key points of Micro.blog is to encourage more people to post content at their own site, even if traditional blogging tools were too much trouble for them.

There’s evidence that this part of the mission for Micro.blog is working. There are many people who could never get blogging to stick until they tried Micro.blog. Some of them are featured on the Micro Monday podcast.

Whether it’s Twitter-like posting, photo blogging, microcasting, or using Micro.blog as a full web site at a custom domain name, there are millions of people who would post more often if it was easier. If you tried Micro.blog a year ago, consider trying it again! It is significantly better now than it was at launch, and as it continues to improve I hope that many more people who “aren’t bloggers” will find a home at Micro.blog.

Earlier this week I wrote about some behind-the-scenes Webmention changes that improve how replies are handled for external blogs, and yesterday we increased the storage for hosted podcasts. Today I’m rolling out some more visible new stuff on Micro.blog:

• Added special sections of Discover for Inktober and NaNoWriMo. I love seeing the art that has been posted already, and we want to do more to encourage the writers on Micro.blog next month.
• Added new invite link under “Plans” to invite someone to Micro.blog. If you already have a paid subscription you can pay for someone’s blog hosting for a year! We’ve heard from customers who want to offer this to friends or family to make it easier for them to get started blogging. It’s a one-time $50 payment, so $10-off the usual year-long subscription.
• Added a progress spinner when loading the timeline on the web.
• Added “…” button on the user profile page on the web with option to mute or report the user, matching what was recently added to the macOS version of Micro.blog.
• Plus a few bug fixes and cleanup to make things run more smoothly.

After a very busy summer, I feel like I’m able to get back to deploying improvements to Micro.blog on a regular schedule. Still have a couple big features in the queue that I hope will be ready soon. Thanks for the support!

I rolled out a few Webmention improvements to Micro.blog today:

• Fixed the permalink for a reply when you aren’t signed in, which was preventing external sites from verifying the link after receiving a Webmention from Micro.blog.
• Added limited support for accepting replies from external sites that do not have a Micro.blog account. Previously, Micro.blog would discard replies that could not be associated with an existing user. Now, these replies will be included in a thread using the domain name for the author. (Brid.gy replies from Twitter are not supported yet.)
• Improved replying on Micro.blog to send Webmentions to any external site in the reply chain, not just the root post. This more consistently allows replies to be copied to multiple external blogs that are participating in the conversation.
• Behind the scenes, for the last few months Micro.blog has been recording all incoming Webmentions, even if they don’t target a specific reply or just can’t be processed yet. This should allow us to add more reply-related features for hosted blogs in the future.

There may still be some quirks to work out with these changes, but I’m happy to finish more of the plumbing around replies on Micro.blog. Getting closer to the IndieWeb vision for how cross-site replies on the web can work.

There has been a lot of distressing news lately, so it’s refreshing to read a story about developers who are just quietly making the web better. The team at the Internet Archive has fixed 9 million broken links on Wikipedia by scanning pages for broken links and updating them to point to the Wayback Machine’s copy:

And for the past 3 years, we have been running a software robot called IABot on 22 Wikipedia language editions looking for broken links (URLs that return a ‘404’, or ‘Page Not Found’). When broken links are discovered, IABot searches for archives in the Wayback Machine and other web archives to replace them with.

I wrote a blog post in 2012 about how fragile web pages are. This is always on my mind. It has informed a couple Micro.blog features such as our automatic mirroring of your blog to a GitHub repository. I hope that as the web evolves that this issue of broken links can be more directly tackled, so that the full responsibility for fixing this isn’t only on the Internet Archive.

It has been over a year since JSON Feed was announced. There have been a bunch of discussions about expanding the specification, but we are very happy with how well the initial version has worked. It powers all Micro.blog-hosted blogs by default and is also used on many WordPress blogs, home-grown sites, and other platforms, with great support in feed readers like Feedbin.

I haven’t had as much time to maintain the WordPress plugin for JSON Feed, though. David Shanske noticed this and offered to take the lead on merging pull requests and making other improvements to the plugin. Thank you, David! He’s now rolled all these changes into a new version.

You can grab version 1.2 of the WordPress plugin from GitHub or by searching for it in the WordPress plugin directory. Enjoy! And thanks again to David for moving the plugin forward.

I updated Micro.blog with several improvements today:

• Added a Markdown preview button when writing a post on the web, to test what the post will look like when published.
• Added a “Show More” button to the timeline and mentions on the web for scrolling further back.
• Fixed muting users to also hide posts in conversations.
• Fixed reliability of the before_id parameter in more places in the API.

Plus some other tweaks. These changes focus mostly on the web version of Micro.blog. We have updates to the native apps that will follow.

Jean published episode 30 of our Micro Monday podcast today. There have actually been over 30 episodes if you count the bonus episodes, but I wanted to officially mark the 30th episode as a milestone as I reflect on what the podcast has meant for Micro.blog.

This week Jean welcomes @amit:

Our guest this week is Amit Gawande, who codes for a living but lives for reading and writing. He is the creator of Microthreads, a tool for finding users and conversations to follow on Micro.blog. We talk about the many blog platforms he’s used over the years, and why the simplicity of Micro.blog makes it easier to just write.

I love that Micro Monday is so consistent with our values. Everyone has a story to tell and should be able to have their own space on the web to tell it. The podcast makes Micro.blog better at the same time as it gives members of the community another opportunity to talk about what they care about. Thanks to everyone who has been on the podcast so far!

We posted the latest Core Intuition this weekend. It’s a 45-minute episode without sponsor breaks dedicated to the Mojave release and Mac App Store. More from the show notes:

macOS Mojave is out! Daniel and Manton talk about the ephemeral nature of App Store features, and the wisdom of not investing too much stock in being featured, or any other external recognition. They catch up on the state of the Mac App Store and wonder about the expected App Store versions of BBEdit and Transmit. Finally, they talk about their own continuing plans for supporting Mojave, particular with respect to Dark Mode.

As part of hopefully consolidating a couple of my servers, I’ve moved the MP3 hosting to Libsyn. We have 10 GB of previous episodes, so I’m still not entirely sure what the best long-term hosting solution is. We’ve changed our mind a few times over the podcast’s 10-year history.

I watched the entire hearing yesterday, working with my laptop in the living room with the TV on. At several points I tried to type a quick post about what was unfolding, but I couldn’t do it justice in 280 characters. Since shortly after the 2016 election, I’ve kept most politics off my blog, trying to focus as much of my attention as possible on Micro.blog and related topics.

I have thoughts on Judge Kavanaugh’s tone and answers, of course. I have thoughts on how partisan the second half of the day was, so divisive and seemingly irreparable. But ultimately that doesn’t matter. What I’ll remember for the rest of my life is the first half of the day.

If Republicans on the committee thought Dr. Blasey would contradict herself or seem inauthentic, they must have realized within minutes that they had miscalculated. I wrote in my notes while watching it live: I can’t imagine anyone who could be more believable than she is.

It was very brave of her to go through this. I couldn’t stop thinking of all the women who must be watching, who have been sexually assaulted and lived with the memory for years, telling only a few people or no one. I hope when we look back on Dr. Blasey’s testimony that it will be an inspiration for many, even as it was so heartbreaking.

We rebooted the Homebrew Website Club meetup in Austin this summer after a break, and last week we met again at Mozart’s Coffee to talk about the IndieWeb. It was raining when I arrived at the coffee shop. Despite the weather we found some tables on the bottom deck and had a good turnout.

The meeting was informal. After introductions, we talked about the state of social media and silos, with some detours into Mastodon, Micro.blog, and the value of having your own site. The discussion inspired me to finish writing a post about the way out of this mess we’ve found ourselves in with massive social networks.

We’re going to keep the meetup at Mozart’s for now. The next meetup will be October 3rd, 6:30pm. I think it will start to become a little more structured: introductions, demos, discussion, and time for writing or working on projects. Thanks to everyone who made it!

There have been many articles written in the last month about the role of social networks. Some even reach the obvious conclusion: that the top social networks are too big. This interview on Slate was fairly representative, covering monopolies and centralized power.

But these articles always stop short before hitting on a solution. They always wrap up saying “it’s tough to solve this”.

I think there are 4 parts to finding our way out of this mess with massive social networks:

Better features: We should be careful before copying everything from Twitter. I don’t want to take features that failed us and recreate them in a new environment. Micro.blog leaves out features on purpose that we think undermine a healthy community.

Open standards: When I first stopped tweeting 6 years ago, it was largely because of the developer-hostile attitude from Twitter. Proprietary APIs reinforce the lock-in with content silos. This is why so much of Micro.blog is based on IndieWeb standards. It’s why Mastodon uses APIs like ActivityPub.

Content ownership: Controlling the writing and photos you post online isn’t about open source or the technical experience to run a server. It’s about using domain names for identity, so that you can move your data in the future without breaking URLs. I’ve written more about this here and it’s a fundamental part of the book I’m writing about microblogging.

Smaller social networks: Many people are looking for “the next Twitter”, but it’s not enough to replace Twitter with a new platform and new leadership. Some problems are inevitable when power is concentrated in only 2-3 huge social networks — ad-based businesses at odds with user needs and an overwhelming curation challenge. This might be Mastodon’s greatest contribution: getting people used to the idea of many smaller, interoperable communities.

There’s not only one solution. I think platforms like Micro.blog and Mastodon each have a role to play and can be complementary. Mastodon helps by encouraging smaller social networks, distributing the task of moderation, but doesn’t prioritize content ownership. (An account on an instance like Mastodon.social has no more ownership of its content than an account on Twitter. Both let you export your data but both live at someone else’s domain name.)

If you are frustrated with the state of social networks, I recommend blogging more. I love seeing new blogs and photo blogs just as we’re having a serious debate in the mainstream about social networks. The way out isn’t easy, but there’s a clear path waiting for us to take it.

Today we added a new screen to the web interface for hosted blogs on Micro.blog. Click “Posts” and then choose the “Uploads” tab to view your uploaded photos and microcast episodes. You can also upload new photos here to later include in a blog post.

Expect this part of Micro.blog to continue to improve. If you have any feedback, let us know. Thanks for your support!

Of everything you put into social networks, photos are one of the easiest and most rewarding parts to reclaim for your own site. Because we shipped Sunlit 2.2 this week, I want to share a guide for starting a new photo blog that you will actually consistently post to.

The first step isn’t technical. It’s a commitment to posting regularly on your own blog instead of first reaching for Instagram or Snapchat. A commitment to posting to a place you control, to a place you can look back to years from now as an archive of your best photos at your own domain name, regardless of what social networks come and go over the years.

If you already have a hosted blog on Micro.blog or WordPress, you can use that. If you want to start with a new space just for photos, use Micro.blog and click Plans → New Microblog. In the Micro.blog settings, you can map a custom domain to your new photo blog such as photos.yourdomain.com.

Instagram will let you download an archive of all your Instagram photos. If you use macOS, install Micro.blog for Mac. Choose File → “Import from Instagram”. Select the media.json file in the archive you received from Instagram, and Micro.blog will let you select some or all of your photos to import, preserving the dates and captions on your new photo blog. See this help page for more details on importing from Instagram.

To post a new photo, use the official Micro.blog iOS app or our new companion app Sunlit. There are also great third-party apps such as Icro for iPhone and MarsEdit for macOS.

When you post a photo with some text but no title, that photo will show up directly in the Micro.blog timeline.

Another option is to connect OwnYourGram with Micro.blog. OwnYourGram can watch your Instagram account for new photos, then copy them automatically to Micro.blog. Before setting up OwnYouGram, make sure to add your Instagram username in Micro.blog under Account → “Edit Apps”.

For an overview video of the new version of Sunlit, see my post from yesterday. Happy photo blogging!

This week we shipped the new version of Sunlit, featuring an Instagram-like timeline of photos from people you’re following on Micro.blog. You can post photos to a microblog on Micro.blog, or to WordPress and other compatible blogs.

The best way to understand Sunlit is to see it. I’ve prepared a short video below, talking through a few of the main screens, but the app has a lot more depth for editing photos and organizing photos into stories:

Sunlit is a free download in the App Store. There’s no in-app purchase. If you like it, I hope you’ll support Micro.blog with a subscription to a hosted microblog or new photo blog. You can learn more at sunlit.io.

Om Malik has a post on leaving Facebook for good:

Why? Because I don’t need it and don’t miss it. I left, not because of the company’s dodgy approach to privacy, data accumulation or its continued denial of its impact on shaping modern society. I left because it was making me someone I am not — someone who lives life through the eyes of others.

He also mentions Instagram and focusing more on his own photo blog:

I have started a photo blog — where I cross post all photos I share on Instagram. I think it is a matter of time, before it becomes my primary spot for sharing photos.

As I read this, Jon and I are wrapping up Sunlit 2.2, which will ship on Tuesday. It’s a Micro.blog companion app just for photos. I recorded a short preview video here.

NetNewsWire is returning home. Brent Simmons first shipped NetNewsWire Lite way back in 2002 and it played a significant role in the early popularity of RSS on the Mac. I’ve written a few things about it over the years, including this post in 2002 when I switched to using it.

It has been fun to watch Brent start over with Evergreen, document the progress in public on his blog and GitHub, and now it’s fitting to see that work evolve into the next official version of NetNewsWire. NetNewsWire 5 will also have great support for JSON Feed and Micro.blog. Congrats Brent!

We rolled out a few improvements to Micro.blog this week. There’s a new page on the web for managing muted users — click Account and scroll down to the “Edit Muted Users” button — and a new macOS release with a photo upload bug fix and an options menu to mute or report users.

You can download Micro.blog for Mac here, or choose “Check for Updates” inside the app. If you missed it when it was first announced, the app now supports uploading your Instagram archive as microblog posts.

About a month ago we added experimental support for Indiepaper to Micro.blog. It’s in the spirit of Instapaper or Pocket, but built on IndieWeb standards. You can read more about Indiepaper in our help.

I wasn’t sure where this would lead, but people are using it, so we’ve improved Micro.blog to include a page on the web for viewing or managing saved articles. After you’ve added an article to read using Indiepaper, a new link to access it will appear under Account → “Edit Feeds & Cross-posting”.

Thanks for your support of Micro.blog. As expected, we’ve had a bunch of new people join Micro.blog, which always translates to great feedback for making the platform better.

This week we rolled out a few improvements to podcast hosting on Micro.blog. I talked about some of it on yesterday’s episode of Timetable. Here are the changes:

• Increased MP3 upload size to 35 MB. With the default setting in Wavelength for iPhone this is over half an hour per episode. At lower bitrates, it’s over 70 minutes.
• Added custom email address to site settings. Google’s podcast directory apparently likes a contact email in your podcast feed, so this allows it. (But it’s blank by default in Micro.blog for privacy.)
• Updated podcast feed to use your “about me” text as the podcast description.

Speaking of podcasts, check out the latest episode the Supertop podcast. In addition to updates about their podcast client Castro, they cover my blog post about Anchor and other thoughts on what impact Anchor might have on the podcast industry.

Two quick follow-ups on my post yesterday about Apple removing Infowars from their podcast directory, and related actions by Facebook and YouTube. First, Alan Jacobs summed it up really well on his microblog:

What Alex Jones is being deprived of is amplification. Not the right and freedom to speak, but multiple megaphones.

And I love this quote from the Onion:

What we see here really could be the beginning of a slippery slope towards a horrific ordeal in which any citizen who violates hate speech policies or blatantly spreads lies that cause other individuals to receive death threats will immediately be discredited and, perhaps, even asked to host their demonstrably false content on a website that they actually own.

The best satire is often true. We’re seeing a major shift in how mainstream users view the role of these huge social networks.

BuzzFeed has an article about Apple removing Infowars from the Apple podcast directory:

Apple’s decision to remove all episodes of Jones' popular show — rather than just specific offending episodes — is one of the largest enforcement actions intended to curb conspiratorial news content by a technology company to date. Apple did not host Jones' shows, but it offered an index that allowed anyone with an iPhone to find and subscribe to them.

This is the way the web is supposed to work. Alex Jones can continue to host his podcast and his fans can subscribe manually. But Apple has no obligation to index it in their podcast directory and make it easy for people to find it.

More from the New York Times today:

Some tech companies, including Facebook and Google, which owns YouTube, had appeared reluctant to remove Mr. Jones’s pages entirely and were instead taking action against specific videos.

Google has now decided to terminate his YouTube channel. And:

Tech companies have long been wary of censoring speech, but an increasing amount of hate speech and misinformation — and louder protests from critics — have forced them to take action. Moves by the tech companies against Infowars and its peers have spurred a debate over free speech.

Facebook and YouTube are conflicted about how to handle this because their model is wrong. Unlike podcasts and blogs, which can live at a custom domain and move between hosting companies, videos on Facebook and YouTube are served directly on those platforms. If the videos are blocked, especially by YouTube which controls nearly all video on the web, there’s no obvious migration path away.

We’ve also seen this hesitation to curate with Twitter. My post about pulling the weeds covers the same issue.

Over the last dozen years we have let massive centralized social networks gain far too much power. We started paying the price with the 2016 election and the fallout continues today. The solution is clear: post to your own site, encourage other people to get their own domain name, and support smaller social networks like Micro.blog that are empowered by design to curate.

When I started using Twitter again for cross-posting, I made a few rules for myself so that I wouldn’t get pulled back into the platform. One is that I let Micro.blog post everything for me automatically, and I only favorite or reply to people when I get asked a specific question. I don’t follow anyone.

But every once in a while I feel compelled to jump in to a discussion. In reply to Joe Cieplinski’s blog post today about Apple having all the leverage, I posted this tweet:

The sad part of this is that developers actually do have leverage, but we’re just not organized and can’t agree on what is fair. It would take the whole community coming together. Most developers think that Apple’s tight control over app distribution is fine. (Spoiler: I don’t.)

Long-time readers of my blog will notice that I complain about Apple as often as I praise them. I hold Apple to a very high standard because they’ve earned it through great design and products.

I know Micro.blog isn’t perfect yet. There are many things we’d like to improve. But I’m proud that the values for the platform are consistent with everything I’ve been blogging about for 15+ years. Complaints I have against the power of big companies like Apple, Facebook, Google, and Twitter… The entire design of Micro.blog’s architecture is to do the opposite of what those companies do.

Jason Snell posted about Apple’s record services revenue:

As someone who’s interested in products, I find the focus on Services revenue to be a bit dispiriting. I get excited at the prospect of new products and seeing how consumers are accepting or rejecting products in the market. But the discussion of Services, especially in a financial context, is essentially a conversation about how Apple can grind more money out of every single person who uses an iPhone, iPad, and Mac.

Back in 2011 I explored the App Store’s 30% cut from the perspective of supporting free app downloads:

I’ve argued that Apple’s 30% tax is about growing that to significant profit at the expense of developers, but in the back of my head I’ve also been concerned that maybe it’s just to keep the App Store from falling into the red. Maybe they are really struggling under the weight of what they created, and long app review times and lack of focus around the Mac App Store launch are just symptoms of that.

In hindsight, 7 years later with $9.5 billion in services revenue per quarter, my attempt in that post to reconcile Apple’s cut seems like a stretch. To echo what Jason says above, I still believe that services should complement Apple’s core products.

iCloud storage is there to make the experience of saving files or backing up your iPhone better, not to nickel-and-dime users who need more storage for a backup. The App Store is there to make discovering apps easier, not to turn developers into a profit center. The more these parts of Apple’s business dominate their revenue, the more divorced their product planning becomes from what users and developers need.

$9.5 billion. As I’m posting this their stock price just pushed the company to $1 trillion in market cap. Many developers can’t make enough to support even a 1-person indie business full time.

As an exclamation point on the discussion around services revenue, Apple has also cancelled their affiliate program. Stephen Hackett sums up what I think many people in the community are thinking:

Payments made to people linking to apps with affiliate links comes out of Apple’s share of revenue generated by app sales and in-app purchases. How much money it costs them is unknown, but the idea that the reasons behind this move could be financial in nature feels pretty gross. Apple is a for-profit company, and it has no bottom-line reason to keep this program open, but sometimes doing the right thing comes with a cost.

And John Voorhees on Apple’s statement that the App Store no longer needs affiliate links:

If that’s the case, it’s short-sighted, but it’s certainly Apple prerogative to run its programs as it sees fit. Still, it’s not the right way to address the publications, developers, and others that have generated millions of dollars of referrals over the years in exchange for a modest 7% cut.

I’ve argued since the first days of the App Store that Apple’s 30% cut is too high. This tax on developers is completely out of line with the value that Apple provides. The fact that Apple is bringing in so much money from services — nearly as much as the Mac and iPad combined — shouldn’t sit well with developers who are still struggling. It’s even worse now without the affiliate program, which developers could use to recoup some of that 30%.

Note what I’m not saying. I’m not saying that Apple should lower the rate to match Stripe’s 3%, or that Apple should operate the App Store at a loss. It costs real money to maintain the App Store infrastructure and commit to featuring apps every day. But there should be a middle-ground that gives developers the best shot at a sustainable business.

Introducing a 15% tier for in-app purchase subscriptions (after the first year) was a good start. Most developers thought we’d never see that. We should be calling for an across-the-board 15% rate for all App Store transactions. It’s the right thing for Apple to do. As Apple’s services revenue continues to grow — and the TV streaming service will only add to that — the time to make this change is now.

Nick Heer has a comprehensive post on how web pages have become so slow despite huge improvements in our internet speeds. He covers JavaScript tracking, Google’s AMP, and a CNN web page that takes 30 seconds to load:

The vast majority of these resources are not directly related to the information on the page, and I’m including advertising. Many of the scripts that were loaded are purely for surveillance purposes: self-hosted analytics, of which there are several examples; various third-party analytics firms like Salesforce, Chartbeat, and Optimizely; and social network sharing widgets. They churn through CPU cycles and cause my six-year-old computer to cry out in pain and fury. I’m not asking much of it; I have opened a text-based document on the web.

As a contrast, consider my blog post from yesterday. All requests for the page (1 for HTML, 3 for CSS files, and an image) total only 34 K. The page loads completely in 1/3 of a second.

This is how most web pages should be. Lightweight, fast. It’s how all Micro.blog-hosted sites are designed. If you’ve let your blog become too bloated with JavaScript includes or images, it’s worth some time to trim out extra resources that don’t really matter.

Last week I added a new archive page to Micro.blog-hosted sites. It includes dates and the first part of each post, marked up with Microformats. Jonathan LaCour used this to write a script that parses the HTML looking for posts on today’s date in previous years, then pulls the full content for each post it finds and assembles them together.

But it gets better. After Jonathan mentioned that it took quite a while to parse the large HTML file, I added a JSON Feed version of the archive page. If you’ve posted to Micro.blog since yesterday, this has been created for you at your-domain.com/archive/index.json. Jonathan updated the script to use the JSON Feed and it can now return the “on this day” posts very quickly, with no configuration needed because it’s all driven from a JavaScript include on your blog.

You can see this in action on my own blog’s on this day page. It works for any Micro.blog-hosted blog by pasting in a few lines of HTML from the Micro Memories project on GitHub.

This is the potential for indie blogging and simple formats. Adding a feature to Micro.blog-hosted blogs enabled a new tool I hadn’t even thought of. There was some discussion in the IndieWeb chat, but it took very little coordination because all of this is built with web stuff, not proprietary APIs.

Nir Zicherman has a post on Medium about how podcast hosting should be free. Nir is the co-founder of Anchor, a company with $14 million in venture-capital funding. Nir writes:

Back in the day, you would have had to pay to store your photos online. But that outdated business model has virtually disappeared thanks to platforms like Google Photos, Instagram, Imgur, and others. At Anchor, we believe the notion of charging creators to host their content online is antiquated and unfair. And above all else, it serves as a barrier that prevents the podcasting ecosystem from growing and becoming more diverse, because it limits it to only those voices who can afford to pay.

I think Nir misses something important in his post. Many podcasts do not need to be directly monetized with ads, network memberships, or even listener donations. I never want ads on my short-form podcast Timetable, for example. I record Timetable because I enjoy it and because it helps people understand what we’re trying to do with Micro.blog, which in turn indirect benefits the platform. I want my own podcast at my own domain name so that I’m not dependent on a company that may or may not be around in a few years.

(Also, it’s misleading to say that it only costs Anchor $1/year to host a podcast. That might cover hosting, but it skips over all the other business costs including engineering, marketing, and support.)

Anchor seems to be going for the YouTube model. They want a huge number of people to use their platform. But the concentration of so much media in one place is one of the problems with today’s web. Massive social networks like Facebook, Instagram, and YouTube have too much power over writers, photographers, and video creators. We do not want that for podcasts.

Micro.blog podcast hosting isn’t free. It’s $10/month. But for that price you get not just a podcast feed but also a full hosted blog with support for microblog posts or longer essays, photo blogging, custom themes and CSS, posting from a bunch of third-party apps and our iOS microcasting app Wavelength, and most importantly everything at your own domain name so you own the content. The competition for Micro.blog isn’t Anchor; it’s Squarespace and WordPress.

Some things are worth paying for. I share Nir’s goal that podcasting should be more accessible and more affordable to more people, but it’s dangerous to give one company too much control over podcasting. Anchor’s business model demands scale. It’s still unclear how that will play out.

Last week I parked myself at a coffee shop one morning and re-architected how blog publishing in Micro.blog works. As some of you know, hosted blogs on Micro.blog are based on Jekyll. While this has some advantages that I wrote about in 2016, it brings some performance drawbacks as well. I’ve incrementally improved it with tweaks over the last year, but last week I finally blocked out enough time to solve more of the performance trade-offs with using Jekyll.

When you post to Micro.blog now, it will publish your new blog post on the web right away. It will also update the JSON Feed and bring the new post into the timeline. Then in the background, it will update the site index and other related pages.

This should have a dramatic impact to posting and seeing the new post show up in the Micro.blog timeline, especially for blogs with thousands of posts. Moving my own site (and it’s 2700+ blog posts) from WordPress to Micro.blog has been a great way to test these changes.

One reason that IndieWeb Summit was such a success was the range of projects to come out of the second day as attendees worked on their own projects. There were new tools and features of existing platforms, but also personal site updates and just fun stuff. And web rings are fun!

I know, I know… Is it 2018 or 1998? I’ve added a help page on Micro.blog for how to add a web ring to your blog using 🕸️💍. One of the great things about microblogging at your own domain name is you can experiment with features like this.

Daniel and I talk a little more about this on the new episode of Core Intuition out today. Enjoy.

I don’t read Medium often, but I do let the service send me weekly emails with posts I might be interested in. For some reason, this week’s email included a Jason Calacanis post from April about funding a Facebook replacement:

LAUNCH is going to fund seven, purpose-driven teams that want to build a billion-user social network to replace Facebook.

This is the wrong idea. We do not need another social network with 1 billion users. Part of the problem is having so many users and so much power concentrated in one place. And setting out to achieve 1 billion users means it’s an ad-based platform that will inherently revisit many existing problems. (The rest of the goals in Jason’s post I can get behind, though.)

Micro.blog will never be that big. What we need instead of another huge social network is a bunch of smaller platforms that are built on blogs and the open web.

At the beginning of the week I announced several new features in Micro.blog, including a change to show who someone is following on the web version of Micro.blog. While working on this feature, I inadvertently changed the behavior to remove you (while browsing a user’s profile) from the list of who someone was following. If you looked at a user’s profile, you were never in their following list even if they did follow you.

While this was a bug, there was a long thread on Micro.blog with some good arguments for why this change was actually a feature. We shouldn’t have to worry about checking whether someone follows us. After all, an important part of Micro.blog is to never show follower counts, and to never let a feature grow into a popularity contest and source of judgement. The content someone posts should speak for itself.

This created a lot of confusion, though, because it didn’t work like anyone expected. I think even the people who liked it could tell something needed to change.

I was out of town this week and away from my computer most of the day. This left me some time to try to see both sides of this feature, and I kept coming back to this: the whole point of showing who someone is following is to discover new users. It’s not about how many people they are following. It’s not about whether they are following you.

(As an aside, with a platform based entirely on blogs, no one should read too much into followers anyway, because it doesn’t count all the people who might read your blog in an RSS reader or find it from a Google search.)

I’ve now tried to reduce this feature to its simplest form that solves the problem of finding new users. So in the latest version of Micro.blog on the web and native macOS app, I’ve reverted the change from earlier this week and replaced it with a list of who someone is following that you aren’t following already. We’ll be updating the iOS app as well and submitting it to Apple.

From an API standpoint, the previous behavior is still available. Third-party apps can make the best choice for the user experience they’d like to see, although if people like this change I’d encourage third-party apps to also adopt it.

Thanks to everyone who offered feedback on Micro.blog or in email. It means a lot to us that y’all care that we get this stuff right.

I rolled out several new features to Micro.blog today:

• LinkedIn cross-posting. I don’t use LinkedIn very often, but I kept hearing this request enough that it slowly bubbled up to the top of the priority queue as I was making improvements to cross-posting. Micro.blog can now send any new post to LinkedIn automatically.
• Show following users on the web. For a long time you’ve been able to see who someone is following in the native apps, but not on the web version of Micro.blog. Now the web version more closely matches the experience on iOS and macOS. This is a nice way to discover new users to follow. (We still never show followers or follower counts.)
• Better hosted page redirects. Blogs hosted on Micro.blog can have pages in the navigation for things like contact information, a resume, current projects, books you love, etc. If you want to link to an external site, you can just paste the URL into the contents of the page. These redirects work better now without briefly loading the blog layout.
• Indiepaper for saving articles to read later. This is an experimental feature inspired by some ongoing work in the IndieWeb community. There’s a help page if you’re interested in learning more. I’ll have some more thoughts later on how this might evolve.
• Pass-through legacy URL redirects. The last missing piece to migrate my main blog with 16 years of posts to Micro.blog hosting. Because I had accumulated so many random files on manton.org that I didn’t want to migrate, this feature allows me to have Micro.blog host all posts and photos, but if Micro.blog sees a URL it doesn’t recognize it can forward that to a different URL on the old server. (I’ll be enabling this manually for people who need it for now.)

It’s really nice to finally have manton.org hosted on Micro.blog. I’ve learned a lot going through this that I can use to help others migrating away from Wordpress.

I also cleaned up the text on a few pages and made other small bug fixes. Thanks for using Micro.blog! Your support means we can keep making it better.

Tonight I imported all my WordPress posts from manton.org and moved them into Micro.blog hosting. I learned a lot keeping my blog on WordPress even after launching Micro.blog, but as Micro.blog-hosted blogs improved, it just made sense for me to migrate my 2700 posts over to the new platform.

Micro.blog automatically redirects old URLs it finds in the WordPress import, but I’m still sorting out other changes that might be necessary after blogging for 16 years. (I started on Radio Userland, then Movable Type, and then WordPress.) The best thing about this move is that I’ll be able to better understand the needs of users who are also maintaining large sites on Micro.blog.

When I was on WordPress, I had 2 separate RSS feeds: one for short posts, one for long essay-like posts. Micro.blog doesn’t have separate feeds like that, so you’ll likely notice this change in your RSS reader right away. New posts will appear and older posts will likely be marked as unread. Those blips should be temporary and then everything will be back to normal.

I love how fast my site is now. Micro.blog-hosted sites are mostly static and much faster to load in your browser than my old WordPress site.

Great article by Felix Salmon on Wired last month about Twitter, found via Buzz Andersen’s blog:

Twitter is becoming increasingly concentrated on a tiny core of power users. It’s less and less a distributed mode of many-to-many communication, and more and more a broadcasting hub for the elite—a highly unequal place where their least-considered, Ambien-addled opinions get amplified to a global audience of millions.

When Micro.blog launched, not showing follower counts at all seemed like a big risk. Now I think it’s recognized as a great feature. If we want an inclusive, welcoming community, the UI should encourage that by presenting everyone as equals.

Iconfactory has had to make some difficult choices for the latest update to Twitterrific. From the release history:

In the coming months, Twitter plans to discontinue the underlying services that we need to provide both push notifications and live streaming. As a result, we did not feel it was right to keep selling the push notification in-app purchase since we will soon be forced to shut it down. To that end, we've consolidated our in-app purchases to a single "Enhanced" option which eliminates ads and unlocks Google Translate.

More from their blog post:

We sincerely wish Twitter would have offered third party developers a better way forward for our customers. Apps like Twitterrific helped build Twitter’s brand and expand its user base. We even contributed to its lexicon and feature sets (Tweet tweet!) Twitter’s priorities over the last several years, however, have shifted away from end users and toward brands and big companies. We have no choice but to adapt as best we can.

I post tweet-like short posts to my own blog first and then let Micro.blog send a copy to Twitter, so I don’t use Twitter very often except to check replies a few times a day. Looks like Iconfactory is making this as smooth a transition as possible for existing customers. If you were wondering if Twitter’s API changes were ever really going to affect Twitter users, this release of Twitterrific is your answer.

Earlier this week I wrote about making Micro.blog an IndieAuth provider. This allows anyone with a Micro.blog-hosted blog to sign in to IndieWeb-compatible apps. For example, using OwnYourGram to automatically copy Instagram photos to your own blog on Micro.blog.

I’ve now expanded this support to let anyone use Micro.blog to authorize an app even if your blog is hosted outside of Micro.blog. If you host somewhere else, you’ll still be responsible for setting up posting, but having basic IndieAuth support can be useful if you want to connect your blog to tools that don’t need to post, like IndieWeb Ring or the IndieWeb.org wiki.

There are instructions on this Micro.blog help page for adding the appropriate HTML tags to your site.

In my talk at Peers Conference earlier this year I closed with this quote from Brent Simmons:

Micro.blog is not an alternative silo: instead, it’s what you build when you believe that the web itself is the great social network.

I’ve been thinking more about Brent’s post since then, and so for the keynote that Jean and I gave at IndieWeb Summit last week I wanted to start with that quote. Many people have written nice testimonials about Micro.blog, but this one really seems to capture the goal.

It should come as no surprise that I liked Brent’s full post from February about why Micro.blog isn’t like App.net. He made the case even better than I usually do, about how the web is more important than any one platform:

But if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years — but then a few tragedies happened: Google Reader came out, and then, almost worse, it went away. Worse still was the rise of Twitter and Facebook, when we decided it would be okay to give up ownership and let just a couple companies own our communication.

Micro.blog is one of the first platforms to focus on domain names that decouple the timeline from post storage. Anyone can post a Micro.blog-hosted site at their own domain name today and move it all somewhere else tomorrow. It’s a simple, IndieWeb-friendly architecture that we think is essential to the next phase of the web.

I’ve added 2 new features to Micro.blog-hosted blogs:

• There's a new "Footer" button under Posts → "Edit Domain & Design" to enter any custom HTML or JavaScript on your microblog's theme. This is inserted before the </body> tag.
• The pages added under Posts → Pages can now redirect to an external web page. Just enter a full URL beginning with "http" as the contents of the page and Micro.blog will instead send the user to that URL. (Expect some improvements to this in the future.)

Thanks for your support. The $5/month for blog hosting might not seem like much, but it makes a big difference as we grow the Micro.blog platform and add new hosted blog features.

After posting about my time at IndieWeb Summit and the new IndieBookClub support, let me give some more details on what IndieAuth means for Micro.blog. I spent the second day of IndieWeb Summit working on this, and it has now been rolled out to all Micro.blog users. (If you haven’t posted in the last few days, after your next post your microblog will be updated with the new authorization endpoints.)

IndieAuth lets you sign in to other apps using your own domain name. If Micro.blog is hosting a blog for you, you can use that custom domain or your subdomain like yourname.micro.blog to sign in.

While this was possible before with extra configuration to delegate auth to another service, Micro.blog can now be an IndieAuth provider on its own. It’s much easier for IndieWeb apps to work with Micro.blog.

Here are some apps that work great with Micro.blog:

• Quill: web-based interface for posting to your microblog.
• OwnYourGram: automatically post your Instagram photos to your microblog.
• OwnYourSwarm: automatically post your Swarm check-ins to your microblog.
• IndieBookClub: post what books you're reading or want to read.
• Omnibear: Chrome or Firefox extension for quick posting.
• IndieWeb Ring: wait… what?

I’m really happy with the progress over the last week because it makes Micro.blog-hosted sites more useful. As I mentioned in my IndieWeb Summit keynote, the business model for Micro.blog is aligned with what users need. If you pay for Micro.blog hosting, we’ll keep making it better without worrying about ads or other user-hostile distractions.

As I mentioned in my IndieWeb Summit wrap-up, I added support for IndieBookClub while in Portland. IndieBookClub is a little like Goodreads, but built on standards like Microformats and Micropub so that you can post what you’re reading to your own blog.

Now that I’m back in Austin, I’ve tweaked the behavior to be smarter about recognizing the ISBN that IndieBookClub sends to Micro.blog. Posts from IndieBookClub also get the 📚 emoji added automatically so that they show up in the books Discover section on Micro.blog. Here’s a screenshot of what posts look like on your Micro.blog-hosted site:

If the ISBN is specified, Micro.blog will redirect the link to Amazon, although we may change that in the future. And it’s just a regular blog post, so you can always edit it using Markdown in Micro.blog.

Last week I was in Portland for IndieWeb Summit. This was only my second IndieWeb conference (the first was IndieWebCamp in Austin). I had a great time in Portland and got even more than I expected out of IndieWeb Summit.

The first day was short keynotes and sessions led by attendees on a range of topics. Jean and I talked about our experience and goals with Micro.blog in reaching even more mainstream users. I went to sessions on Microformats, timeline algorithms, code libraries for common IndieWeb building blocks, and Microsub. Some of this carried over to the beginning of the next day, including Aaron Parecki leading a discussion about IndieAuth.

We held a Micro.blog meetup at Von Ebert Brewing after the first day wrapped up. Thanks everyone for joining us!

Most of the second day was a hack day to work on our own projects, and at the end of the day everyone could present what they had worked on. I was so impressed with what people had come up with, whether that was improvements to their own site or prototypes for new tools.

It turned out that having this dedicated time was exactly what I needed to turn Micro.blog into an IndieAuth provider. This means that Micro.blog no longer needs to delegate to Twitter or GitHub for authorization when someone is using an IndieWeb posting tool like OwnYourGram or Quill. Users can instead authorize directly with their Micro.blog account. I also added support for the summary fallback parameter in Micropub, which makes Micro.blog compatible with IndieBookClub.

In the morning before I left Portland, I interviewed Tantek and Aaron for my upcoming book Indie Microblogging. We had a great conversation on the founding of IndieWebCamp, the accomplishments and changes in the community, and where everything is going from here.

Portland was great. For this trip I opted for an Airbnb close to the IndieWeb Summit venue. It was also just a block from Coava Coffee, where I spent a couple mornings catching up on work. I hope to be back in Portland for IndieWeb Summit next year.

Great post by CJ Chilvers about blogging regularly, via Micro.blog user @kaa, with a quote from Seth Godin’s podcast. Seth says to blog every day…

…because of the discipline it gives you, to know that you’re going to write something tomorrow. Something that might not be read by many people—it doesn’t matter—it will be read by you. If you can build that up, you will begin to think more clearly. You will make predictions. You will make assertions. You will make connections.

CJ adds:

Nothing has been healthier for my idea generation than to throw out ideas. Once they’re in the public, they feel completely gone. I’m free to come up with new and better ideas. And I do.

For more people to blog more often, blogging has to be easier. That is a key premise of Micro.blog — why blogging UIs should take inspiration from Twitter and Instagram, and why we have little incentives like unlocking the 30-day pin on Micro.blog for blogging every day.

We just posted our pre-WWDC podcast episode:

Manton and Daniel check in just before WWDC to talk about expectations from the conference, and strategies for saving money on the trip. They indulge in a bit more Siri criticism, hope that Apple will announce new MacBook Pros, and question whether Apple will dare to poke fun at Google’s Duplex technology during the keynote.

If you’ll be in San Jose, hope to see you at the Micro.blog lunch meetup on Tuesday. I’d love to talk to listeners about Micro.blog or Core Intuition, and we have a major update to Sunlit in beta that I’ll be showing off.

The writing has been on the wall for years. Now that Twitter plans to move ahead with deprecating APIs that apps like Twitterrific and Tweetbot use, it’s even more clear that there’s no overlap between Twitter’s priorities for the API and what traditional clients need.

When I wrote about Icro, the first third-party app for Micro.blog, I said that I always want to encourage other developers building for Micro.blog. It’s worth exploring how these Twitter API changes compare to Micro.blog and how we can improve.

The streaming API is a big part of this. Twitter apps currently use the streaming API to deliver tweets in real-time without polling, or to notice when someone is @-mentioned so that a push notification can be delivered. Losing this API is especially frustrating because it means developers need to rewrite a bunch of code only to make their apps a little worse instead of better.

Micro.blog doesn’t actually have a streaming API yet. Micro.blog supports multiple APIs, but no persistent connection. The new app Icro doesn’t have push notifications, although the official Micro.blog app does. For a brand new app like Icro, it would be a lot for the developer to also run a server just to do push notifications.

As I think about how we solve this, I remember a discussion in the Twitter developer community when the iPhone first got push notifications. It was an open question: should Twitter third-party developers run their own servers for push notifications, or should Twitter itself deliver push notifications on behalf of third-party apps? Obviously third-party developers have had to run their own servers.

I think a goal for us with Micro.blog should be that third-party developers get access to the same basic tools that we use to build our own apps. Rate-limits should be the same for an app like Icro as they are for the official Micro.blog app, for example.

With that in mind, I’ve mentioned before that I’d like to offer a push notification service for developers. iOS and Android developers could upload their push notification credentials from Apple and Google. Micro.blog would store them and deliver push notifications directly to third-party apps.

This has a few pretty big advantages:

• Third-party developers won't need to run their own servers. This levels the playing field so that any Micro.blog app, no matter how small, can offer basic features like notifications.
• Push notifications are more capable now than at their introduction in 2009. They can be used not just for an alert message but for silently sending data to an app in the background, such as when new posts have been added to someone's timeline.
• It's more efficient. Instead of keeping persistent connections open to Micro.blog servers, Apple and Google handle the persistent connections between devices and the cloud. Micro.blog can simply forward @-mentions to the clients that have requested them via Apple and Google infrastructure.

This is a little bit of extra work for Micro.blog, but Micro.blog is already doing similar processing when a reply comes through. For every reply to a blog post, Micro.blog checks if there is a Webmention endpoint so that it can forward that reply to an external site, such as one hosted on WordPress. Opening up push notifications feels like a natural extension to that.

Some developers might not be comfortable outsourcing this to Micro.blog. That’s fine. In particular I’d like to hear any concerns over security or features where this approach would be too limited. (To be clear, we’d offer this for free. Our business is blog hosting.)

Back to the Twitter news. John Gruber summed it up this way:

Twitter isn’t explicitly saying that they’re shutting down third-party clients, but I don’t know that it’s feasible for them to exist if they don’t have access to these APIs. It’s like breaking up with someone by being a jerk to them rather than telling them you’re breaking up.

That’s a great analogy. Micro.blog is barely a year old, so there is plenty still to do, and there are parts of the API that aren’t as mature yet as they will be. But I think we’re transparent about what we’re trying to do and how we can support developers. We’re not going to be jerks about it.

I’m really excited by what I’m seeing from the community. Icro is in the App Store. Slate is another iPhone app currently in beta. Dialog for Android is in the Google Play Store as a public beta. And then there are all the apps following IndieWeb standards that are compatible with Micro.blog.

WWDC is only a couple weeks away. We’ll have a Micro.blog meetup on Tuesday (June 5th) at lunch. I’d love to talk to developers at the meetup or anytime that week in San Jose to get feedback on how we should handle streaming and notifications.

I’ll have more to say tomorrow specifically about the technical side of Twitter’s streaming API, but for now I want to highlight where this all started. In August 2012, Twitter posted to their blog about upcoming changes to their API. This was the post with the infamous 4-quadrant chart showing which third-party apps Twitter wanted to encourage, and which apps (in the upper-right quadrant) they didn’t want third-party developers to work on anymore.

From the post:

In the upper right-hand quadrant are services that enable users to interact with Tweets, like the Tweet curation service Storify or the Tweet discovery site Favstar.fm.

Although it wasn’t clear in the blog post, Twitter later clarified that Storify and Favstar were fine. Nevertheless, Storify announced last year that the service would be shutting down… tomorrow, actually. Favstar is shutting down next month.

The post from Twitter continues:

That upper-right quadrant also includes, of course, “traditional” Twitter clients like Tweetbot and Echofon. Nearly eighteen months ago, we gave developers guidance that they should not build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” And to reiterate what I wrote in my last post, that guidance continues to apply today.

It has taken nearly 6 years, but it feels like today’s API changes finally wrap up the work that started in 2012. The apps that are possible with the new Account Activity API are exactly the apps that were encouraged in those other quadrants. The pricing makes no sense because it wasn’t designed for traditional Twitter apps like Twitterrific and Tweetbot.

Two months after that post from Twitter, I quit the platform and stopped posting to @manton in protest. I only wish I had started working on Micro.blog immediately in 2012.

I’ll be attending IndieWeb Summit next month. If you’re interested in indie blogging or what we’re doing with Micro.blog, consider joining us for the 2-day conference in Portland. I like how gRegor Morrill highlighted that the group should be more than just programmers:

You don’t need to be a programmer! In fact, I would love to see more non-programmers attending. We need writers, graphic artists, designers, UX engineers, and anybody that wants to reclaim some of their online presence with a personal website.

There’s a lot of overlap between the Micro.blog and IndieWeb communities. As we’re now in Micro.blog’s 2nd year, I expect the platform to become more mature, and I’ll be wrapping up a few loose ends with IndieWeb technologies. IndieWeb Summit will be a great time to reflect on what we’ve been able to do and look to what’s next.

People often write about Micro.blog, but I don’t usually do a good job of pointing to all the reviews. A new blog post this week from Lance Somoza stood out to me:

It reminds me of the earlier days of the Internet, where everything was more whimsical and less threatening than the current status quo. When it comes to free services, we have sadly come to expect a gimmick, trade-off, or worse in exchange for our data. Micro.blog’s opposition to this idea, simply makes it a joy to use.

Thanks everyone for taking a chance on the platform. I’m really happy with how the platform has grown, from new photo blogs and microcasts to third-party apps like Icro. We don’t have ads and we don’t have venture capital funding. The support from the community drives everything.

Last month I gave a talk about microblogging at Peers Conference in Austin. In it I covered Twitter’s changing attitude toward developers, from the early days when everyone wanted to build a Twitter app — as John Gruber wrote in 2009, Twitter apps were a playground for new UIs — to when Twitter started actively discouraging traditional third-party Twitter clients.

For Micro.blog, I always want to encourage third-party apps. We support existing blogging apps like MarsEdit, and we have an API for more Micro.blog-focused apps to be built. I’m excited to say that a big one just shipped in the App Store: Icro.

Icro is well-designed, fast, and takes a different approach to some features compared to the official Micro.blog app. In a few ways, it’s better than the app I built. This is exactly what I hoped for. We wanted an official app so that there’s a default to get started, but there should be other great options for Micro.blog users to choose from.

Here are a few screenshots from Icro:

Thanks to developer Martin Hartl for building Icro and being part of the Micro.blog community. You can download it for free from the App Store here.

I’ve never sent an email to all Micro.blog users until today. As indie developers, sometimes I think we worry so much about accidentally spamming a customer that we err too much on the side of sending essentially no email. As we’re at about the 1-year mark for Micro.blog, it seemed like a good opportunity to send an update. Here’s the text of the email that went out.

A little over a year ago we started rolling out Micro.blog to Kickstarter backers. So much has happened since then — from new Micro.blog platform features to companion apps like Sunlit and Wavelength — that I wanted to highlight a few milestones.

First, thank you for your support. We wouldn’t be able to continue to improve Micro.blog without the feedback from the community. Special thanks to everyone who has supported Micro.blog directly with a paid plan for a hosted microblog.

If you haven’t checked out Micro.blog lately, here are some things that happened just in the last few months:

• We launched a microcast called Micro Monday to feature members of the community. Each week, a different Micro.blog user joins Jean MacDonald for a quick interview about how they blog and what they like about Micro.blog.
• To make it easier for anyone to create a short podcast, Wavelength lets you record, edit, and publish a microcast from your iPhone. You can also upload MP3s from the web and serve a podcast at your own domain name.
• Sunlit is our iOS app for posting photos and discovering photos and new Micro.blog users to follow. It's a free app with more control over publishing stories with photos, text, and different filters.
• There's a new theme for hosted microblogs called Marfa. We use this theme on Micro Monday.
• Medium was added as a cross-posting option. Post to your own blog and Micro.blog will automatically send a copy to Medium.
• Expanded the Discover section on the web and in the native apps to highlight photos, podcasts, and more. It's a great place to see what people are posting about or find new people to follow.

You can always add a new hosted microblog or upgrade a trial by clicking “Plans” from Micro.blog on the web.

Any questions or feedback? Don’t hesitate to let us know: help@micro.blog.

— Manton

We shipped version 1.3.4 of the Micro.blog iOS app. It includes a bunch of photo-related improvements and bug fixes, including better support for non-square photos.

We just wrapped up a bunch of improvements to the initial Wavelength for Micro.blog app. Here are the changes:

• Updated MP3s to 128 kbps, mono. We'll consider adding a preference for quality and stereo in the future.
• Fixed playback volume using correct iPhone speaker.
• Fixed a few potential crashes and improved publishing error messages.
• Fixed Auphonic username field to not use auto-correct.
• Fixed glitches with consistently using external microphones.
• Fixed error sometimes when splitting segments.

I recorded and edited the last 2 episodes of Timetable exclusively with Wavelength on my iPhone X. It’s really great to see some new microcasts pop up over the last few days. Thanks for trying it out!

We have something really big to announce today. Micro.blog now supports hosting short-form podcasts, also known as microcasts, with a companion iPhone app called Wavelength for recording, editing, and publishing episodes.

Before the Kickstarter campaign last year, I started my Timetable microcast to talk about the things I was working on, with a focus on planning what would become Micro.blog. Creating a short podcast is really fun. It’s much easier to record and edit than the longer podcasts we’re all used to. But it’s still not easy enough, and even after nearly 100 episodes of Timetable my workflow was cobbled together with too many apps: Ferrite, Logic, Auphonic, WordPress, a shell script, and sometimes Transmit.

Micro.blog is about making short-form content you own as simple to post as a tweet because we believe blogging should be easier. Podcasting should be easier too.

We’re rolling out a new hosted plan on Micro.blog to accommodate microcasts. When you upload an audio file to your site — either from the web, Wavelength, or a third-party app — Micro.blog will automatically create a podcast feed for your microblog. Listeners can subscribe directly, or you can add the feed to the Apple Podcast Directory and it will show up in popular apps like Overcast and Castro. Everything can be served from your own domain name, just like a normal microblog. We’ve been using this infrastructure for all the episodes of our weekly Micro Monday microcast.

New hosted microblogs with microcasting support will be $10/month. Microcast audio files will be limited to 20 MB. Existing microblogs hosted on Micro.blog can be upgraded to support microcasting for an additional $5/month.

Everyone has a story to tell. Whether that’s through short microblog posts, longer essays, photo blogs, conversations with friends, or now through podcasts, I hope that the Micro.blog platform and suite of apps can help. If you haven’t checked out Micro.blog lately or are learning about it for the first time, now is a great time to join the community. Thanks!

I posted a link to this last week, but it’s worth some additional comments. Apps of a Feather is a new site to spread awareness about upcoming Twitter API changes:

We are incredibly eager to update our apps. However, despite many requests for clarification and guidance, Twitter has not provided a way for us to recreate the lost functionality. We've been waiting for more than a year.

I have a long history with Twitter. I was user #897. I built multiple apps for the platform. I invested so much of my time and code into the Twitter ecosystem.

Then Twitter leadership showed us the future, and it was clear that third-party developers had little or no place in it. It was just a matter of time. And now, maybe time has run out.

If you still love Twitter, absolutely tell them to reverse course and rebuild their relationship with third-party developers. These are great apps and great developers, and I don’t want to see their business cut down because of a developer-hostile platform outside their control.

Meanwhile, we’re working to make Micro.blog better every day. It’s the most ambitious thing I’ve ever worked on. Building for the open web needs to be done in parallel to hoping the other social networks improve, whether you’re still waiting for those sites to do the right thing, or already know it’s time to move on. I only wish we had started sooner.

We just posted Core Intuition 322. From the show notes:

Manton and Daniel react to Apple’s news release about expectations for the Mac Pro coming in 2019. They speculate about what could explain such a long delay, and Daniel devises a theory, or pipe dream, that the Mac Pro may be ARM-based. They also discuss Apple’s disclosure of a Pro Workflow Team comprised of creative professionals, and compare it to Apple’s apparent study of the needs of education professionals. Finally, an update from Daniel about MacBook Pro keyboard repairs, with a surprise twist!

Stephen Hackett also commented today on Matthew Panzarino’s visit to Apple Park to get a status update on the Mac Pro:

There’s also the increased rumors around ARM-powered Macs. Like with the Intel transition, Apple’s pro products will surely be the last to make this move. It may be that 2019-ish Mac Pro will be the Intel Mac’s swan song.

I think Stephen is right, but on Core Intuition today we explored the opposite: what if the 2019 Mac Pro is the first ARM-powered Mac? What it was like to be at WWDC when Apple announced the Intel transition, the value of third-party pro apps, and much more on this episode. Enjoy!

We start this week’s Core Intuition talking about the Apple education event in Chicago. More in the show notes:

Daniel and Manton talk about Apple’s Chicago education event, and Apple’s challenge in breaking into the education market so dominated by Google. They scrutinize whether the special event was “event-worthy” or not. Daniel talks about his motivation problems with shipping MarsEdit updates, and complains again about App Store Review uncertainty. Finally, they talk about the challenge of knowing whether a product with lackluster success is on the brink of something great, or should be moved on from.

Thanks for listening and subscribing to the show.

We released an update to Micro.blog for Mac today with support for multiple accounts. I created a quick screencast video to show off what it looks like:

Naturally because of the goals of Micro.blog, I see a lot of discussion about “owning your content”. It’s an important part of the mission for Micro.blog to take control back from closed, ad-supported social networks and instead embrace posting on our own blogs again.

But what does it mean to own our content? Do we have to install WordPress or some home-grown blogging system for it to be considered true content ownership, where we have the source code and direct SFTP access to the server? No. If that’s our definition, then content ownership will be permanently reserved for programmers and technical folks who have hours to spend on server configuration.

IndieWebCamp has a generations chart to illustrate the path from early adopters to mainstream users. Eli Mellen highlighted it in a recent post about the need to bridge the gap between the technical aspects of IndieWeb tools and more approachable platforms. With Micro.blog specifically, the goal is “generation 4”, and I think we’re on track to get there.

I want blogging to be as easy as tweeting. Anything short of that isn’t good enough for Micro.blog. You’ll notice when you use Twitter that they never ask you to SFTP into twitter.com to configure your account. They don’t ask you to install anything.

More powerful software that you can endlessly customize will always have its place. It’s good to have a range of options, including open source to tinker with. That’s often where some of the best ideas start. But too often I see people get lost in the weeds of plugins and themes, lured in by the myth that you have to self-host with WordPress to be part of the IndieWeb.

Owning your content isn’t about portable software. It’s about portable URLs and data. It’s about domain names.

When you write and post photos at your own domain name, your content can outlive any one blogging platform. This month marked the 16th anniversary of blogging at manton.org, and in that time I’ve switched blogging platforms and hosting providers a few times. The posts and URLs can all be preserved through those changes because it’s my own domain name.

I was disappointed when Medium announced they were discontinuing support for custom domain names. I’m linking to the Internet Archive copy because Medium’s help page about this is no longer available. If “no custom domains” is still their policy, it’s a setback for the open web, and dooms Medium to the same dead-end as twitter.com/username URLs.

If you can’t use your own domain name, you can’t own it. Your content will be forever stuck at those silo URLs, beholden to the whims of the algorithmic timeline and shifting priorities of the executive team.

For hosted blogs on Micro.blog, we encourage everyone to map a custom domain to their content, and we throw in free SSL and preserve redirects for old posts on imported WordPress content. There’s more we can do.

I’m working on the next version of the macOS app for Micro.blog now, which features multiple accounts and even multiple blogs under the same account. Here’s a screenshot of the settings screen:

The goal with Micro.blog is not to be a stop-gap hosting provider, with truly “serious” users eventually moving on to something else (although we make that easy). We want Micro.blog hosting to be the best platform for owning your content and participating in the Micro.blog and IndieWeb communities.

David Smith has shared the stats he’s been collecting on Apple Watch usage from his apps, hoping that Apple will drop support for the original Apple Watch (Series 0) sooner rather than later:

So far the data is looking promising that this dream of mine might actually be possible. The Series 3 is being adopted incredibly quickly and just last week became the most popular Apple Watch overall amongst my users with 33% of the overall user-base. The Series 0 is steadily falling, currently at around 24%.

Federico Viticci adds this in his link from MacStories:

I've been wondering about when Apple could drop support for the original Apple Watch in new versions of watchOS. For context, the original iPhone, launched in 2007, couldn't be updated to iOS 4 in 2010, three years later. The Apple Watch will have its official third anniversary next month.

The big difference between the Apple Watch and the original iPhone or iPad is that many people (perhaps most) do not run third-party apps on the watch. Those people are not even counted in David Smith’s numbers. Unlike the iPhone and iPad, which are significantly improved with new apps, the Apple Watch is pretty good with only the built-in Apple features.

After a few years, I still wear my Series 0 every day. Here’s what I use it for:

• Telling time. Also glancing at the upcoming event.
• Notifications from Slack and Micro.blog.
• Fitness. I don't launch the Workout app. I just let the watch notice when I'm exercising.

For these tasks, performance and API support just don’t matter as much. The way I use my Apple Watch is the equivalent of someone who only tells a HomePod to play Apple Music and asks no other questions. A little sad, but it works fine and I expect to keep the Series 0 for another year or so before upgrading.

I feel for developers who want the Apple Watch to be a much more mature platform. I want that too. But I don’t think it’s as simple as copying what has worked for native apps on Apple’s other platforms.

The future of the Apple Watch isn’t just better widgets; it’s voice. Both WatchKit and Siri need a major shakeup. Apple should make Siri more consistent across Apple Watch, iPhone, and HomePod, with a more flexible server-based API like Alexa. If they can do that while also rethinking WatchKit at the same time, even better.

The latest Core Intuition is out. Daniel and I talk about WWDC and related topics for the full episode:

Daniel and Manton talk about Apple’s announcement that WWDC is officially happening in San Jose again. Daniel struggles to make a financial case for attending, while Manton continues to believe it’s essential to at least be in town for a few days. They talk about the possibility that other conferences would be a better use of time and money. Finally, they indulge a little speculation about WWDC and whether the promo art ever hints at any of the actual news to be announced.

Thanks for subscribing! Looking forward to seeing some Core Intuition listeners out in San Jose.

We’ve started a new podcast! Jean MacDonald will be hosting a weekly show talking with members of the Micro.blog community. I join her on the first episode to talk about our blogs and goals for the podcast.

You can listen to Micro Monday on the web, subscribe in Overcast, or follow @monday on Micro.blog. Thanks for listening! Update: Check out our subscribe page for more links.

We released an update to Sunlit today. Lots of little bug fixes and improvements. (The App Store has been slow this week, but it should show up in your Updates tab soon if it’s not already there.)

I also updated the Micro.blog timeline to add tiny photo thumbnails for Sunlit stories that have a title. Here’s a screenshot:

Because Micro.blog is focused on microblogging, short posts without a title still show directly in the timeline, but longer posts with many photos and a title just link back to your web site. Adding this little preview gives a hint for what is behind those links.

We just published this week’s episode of Core Intuition, talking about the new Sunlit release and other topics. From the show notes:

Manton and Daniel celebrate Sunlit 2.0’s release, and talk about the decision to make it a free app that supports the Micro.blog platform. Daniel admires Manton’s proclivity for shipping new things, and they both despair the difficulty of canceling existing projects. Daniel rants modestly about the difficulty of getting his MacBook Pro keyboard repaired, and finally, they discuss the App Stores and the ongoing disparities between Mac and iOS versions of them.

Thanks for listening!

We rebuilt Sunlit for 2.0 so that it’s focused around blogs. You can collect photos together in stories and publish them directly to a Micro.blog-hosted site or compatible blogs such as WordPress. It’s a free download. (If you need a great place to host your photoblog, consider signing up for a paid microblog on Micro.blog.)

To show off Sunlit in the App Store, I created a few app preview videos. Here’s one of them:

Rewatched the original Blade Runner recently, and finally saw the sequel last night. As with all great films, still thinking about it the next day. The parts that were good, were really good.

There was a conversation on Micro.blog about the length. It would have been an even more powerful movie with a couple scenes cut short. Maybe it could have squeezed into a PG-13 rating too.

Nevertheless, it holds its own with the original. I say this as a compliment: a rare sequel that is no better or worse. Feels unique but consistent — in pacing, visuals, and music — as if 35 years haven’t passed since the first one. Loved it.

The new update to Micro.blog for iOS is now available in the App Store. As I wrote about yesterday, it includes an improved conversations gesture. Here’s the full list of changes:

• Added swipe left on a post to view the conversation.
• Added feed settings button when writing a new post for quickly toggling off cross-posting.
• Added confirmation alert when removing a post.
• Updated character counter to not include Markdown.
• Updated sharing from other apps to not use the current draft or save it.
• Fixed compatibility with some XML-RPC servers.
• Fixed opening conversations from links in the timeline.

Enjoy!

I just submitted a new update to the Micro.blog iOS app. It adds a couple new features, including better support for quickly toggling off cross-posting, but what I’m most excited about is swiping to view conversations. Here’s a 45-second screencast demo:

A couple years ago on a trip, I finally tried Instagram Stories. Because I don’t like posting things that disappear, I planned to keep copies of all the short videos from my story, and then stitch them together in Final Cut, add some music, and publish them to my blog once a week. It didn’t take long to give up on this. Instagram and Snapchat make it easy to share on their network, but difficult everywhere else.

I much prefer Snapthread’s approach. Becky Hansmeyer has created an app that does exactly what I was trying to do, but instead of fumbling around with Instagram and Final Cut, it’s effortless. And it works with live photos. Highly recommend checking this out in the App Store.

DHH writes about how Basecamp is experimenting with removing their “applause” feature — the clap icon that Medium has also recently adopted:

But as I read through the replies from the few dozen people who answered the question on any given day, I was faced with the dilemma of the clap. If I applauded an update from Sam yesterday, but don’t today, does that mean I’m expressing discontent with the most recent work? If I don’t applaud for Javan on the same day as I applaud for Sam, does that mean I’m parting favor of one over the other?

The problem with these “just click a button instead of sending an actual reply” features is that they fool us into thinking we’ve done something meaningful by clicking. Anyone can click a Twitter heart button to show that they’ve noticed a tweet or enjoyed it. It takes very little effort and doesn’t mean much.

On Micro.blog, favorites are private. They are just for your own use, like bookmarks. We’ve found that the lack of public likes encourages people to reply to posts instead, even if it’s just a quick “Thanks!” or “That’s great!” or other comment. It’s a little more meaningful because it requires a bit of effort.

In an interview with Piers Morgan, Trump said something revealing when pressed on his retweets of a racist group:

Well, I know nothing about them. I did a retweet. You know, retweets... sometimes you do... retweets are very different. When you do your own tweeting, when you do your own social media, it's fine. When you do those retweets, sometimes they can cause problems.

What Trump is trying to say is that retweets aren’t as important as a tweet you type yourself. Retweets encourage a sort of thoughtless approach to sharing.

We don’t like retweet counts or follower counts in the UI of Micro.blog, because it’s another place for judgement — “this person must not be very interesting if they have so few followers” — instead of letting someone’s content speak for itself. Likes, claps, and retweets aren’t a substitute for a real conversation. We’ll eventually have some form of public reactions on Micro.blog, but we aren’t in any hurry to get there.

Over the last couple of days we’ve shipped a few improvements to Micro.blog. There’s an update to the Mac version with some bug fixes and better support for showing the title field when you’re writing a longer blog post. The default themes have been updated too.

It’s also much easier to preview themes for your microblog. Under your account there’s now a “Preview Themes” button that lets you click through and test out the themes. Here’s a 10-second screencast recording to show how it works:

Yesterday we sent Sunlit 2.0 to beta testers. The feedback has been great so far. We just pushed a new version with several important fixes, especially to publishing existing stories.

It’s a little overwhelming to ship a brand new app in the middle of everything going on with Micro.blog — opening the platform to new users, trying to stay on top of bugs and feature requests, and planning for the future. But it just feels right that Sunlit should be part of the Micro.blog suite.

We love photos and we love blogs. Sunlit combines those things in a way that accommodates more advanced features than can fit in the main Micro.blog app.

Micro.blog makes it as easy to write a quick short post as it is to send a tweet. The timeline and simple posting interface are part of that. Sunlit supports microblog posts while taking a different approach in the UI, focused around stories and longer blog posts, whether they’re hosted on Micro.blog or elsewhere on the web. And we can do it without much fanfare on the Micro.blog server side because the technical scope of the platform already supports it.

Here’s a short screencast demo of the upcoming version of Sunlit. We’ve rebuilt it for blogging and Micro.blog. You can create stories with photos and text to publish to your blog, with editing and filters, plus a new Discover section for browsing photos.