Flexible themes in Platypub
Updates for The Sample from last week:
- The "Posts" and "Paid forwards" pages in the publisher console always load quickly now. Previously they calculated all the statistics/history whenever you loaded the page, which made them pretty slow if you had received a lot of forwards. Now the statistics/history are calculated once per day in a batch.
- Also made signup faster for readers. Turns out I was doing something stupid that caused it to sometimes take 10 seconds after people hit the subscribe button on the landing page. It now takes less than half a second.
Those things aside, I spent most of my time last week making a large update to Platypub, my publishing platform. I overhauled the data model to make it extensible by themes. To explain what that means: previously, Platypub was more like Ghost. You could use Platypub to create "posts" and "pages", and you could make themes that took your posts and pages and created a website from them. However if you wanted to create some other kind of thingy, besides just posts or pages—"events" perhaps—you were out of luck. (Of course you can do workarounds sometimes, like create a post and give it an "event" tag.)
Now, everything in Platypub is just an "item." Themes can specify what kinds of items they work with. The default theme works with posts and pages, like before. But now other themes are free to define custom item types, including what kinds of fields those item types have (e.g. an Event item might have a location, a start time, an end time, etc). Any item types they define will show up in Platypub, as in the GIF above.
This will give themes much more flexibility, but there is a downside: themes won't always be compatible. If you start your website with one theme and then you want to switch to another theme, the new theme might not recognize the items that you created with the old theme. You don't have this problem in Ghost (I'm pretty sure?) because the data model is fixed. ("Centralized authority can be good actually" strikes again!)
However, I like the flexibility, and anyone who doesn't care about it that much can always use something other than Platypub. I'm also interested in this sort of as an informal research project. What steps can be taken to help people make themes that are mostly interoperable?
Say you have two different themes that each define an "event" item type, but with slight differences. Maybe the first theme says that events have a "location", but the second theme says that events have a "place." Since we're humans and humans are smart, we can see that they're really the same thing. But the computer won't know that unless we tell it. One solution is for one of the theme authors to update their theme. Maybe the first author has their theme look for both a "location" field or a "place" field and use whichever one is available.
Over time, maybe people who write themes get together and say "if you're making a theme that works with events, just call it 'location', not 'place' or something else." In other words, the community can define a standard. Even though the standard isn't dictated by Platypub, it can still be voluntarily adopted by community members. It just requires more coordination work since there isn't a central authority. In some cases, Platypub could still "lead by example." For example, since Platypub's default theme defines Posts and Pages, it would make sense for 3rd party themes to voluntarily work with Platypub's definition of those item types.
But what about in the early stages? Is there anything we can do to help themes work together even in cases where there isn't yet an agreed-upon standard?
One possibility is to use "lenses." A lens is a set of instructions that says something like "a 'location' is the same thing as a 'place', so if you have a theme that wants a location and you have an item that has a place, you can treat the place as a location (and vice-versa)." You still need a human to create the lenses, but at least it doesn't have to be one of the theme authors. See Project Cambria for a technical deep dive on lenses.
For a real-world example of lenses, try out Zapier. Zapier connects different apps together. A couple weeks ago I made a Zapier integration for The Sample. When you connect it, Zapier shows you that The Sample will provide an "email" field. When you connect to another app, like Mailchimp, you then see all the input fields that Mailchimp recognizes, and you can choose where the "email" field should go. The UI is pretty nice; you don't need to be a programmer to use it. Maybe Platypub could have something similar when you switch to a different theme.
As icing on the cake, AI could help create the lenses. If AI is smart enough to draw pictures and stuff now, it seems quite reasonable that it could figure out that "place" and "location" mean the same thing. Maybe when you switch to a new theme, Platypub checks to see if all your items are recognized by the new theme. If not, it creates a default lens with AI. If you notice that something is off, you can edit the lens manually. (This would be an example of "interoperable serendipity.")
Over time, Platypub could look at all the lens data and say "hey, there are a bunch of lenses that all say 'locations and places are the same thing'—maybe we should suggest that as a possible standard to the community."
This week, I'm finally going to start working on a reader app. To start out, I'm going to have it work with RSS, email newsletters, and Pocket bookmarks. Twitter would probably be the next step, although it's tough because I actually kind of like Twitter's recommendation algorithm, and I'm pretty sure you can't use it from the API (?).
If you're a programmer and you like watching videos of people coding, you can watch me create a few RSS features for the reader app. I've started doing these pair programming sessions twice a month as part of my community-buliding efforts for Biff, my web framework. (I also published the Monthly Biff Update last week.)
Published 8 Aug 2022