So far, we’ve explored the idea of an itemized OS a good bit in these lab notes. But a huge part of personal computing today happens beyond your local personal computing domain.

Let’s start moving towards the internet: What might the internet look like when we introduce items? We will spend some weeks exploring this question, starting this week with publishing items.

The itemized OS treats everything as an item. But now let’s say people can publish items and bring published items into their systems.

You might publish something as a one-off thing, like one article. But since items are made up of other items, you could also publish an item of items, such as an item of many articles. This could be a blog-shaped thing, a book-shaped thing, or something else entirely.

You could publish ongoing feeds of items if you wanted to: they could be split by type, topic, length, etc.; it’s up to you (especially since items can be collected regardless of type); the publisher decides how and what they publish via these feeds, and the subscriber can decide what they subscribe to (which could even be a filtered set of some feed).

A recording artist could publish a feed of their music, which they can add to as they release new songs and albums. Fans can subscribe to receive new music whenever it’s published, and they can bring tracks into their local libraries as they wish, where they can live along with tracks from other artists.

The recording artist could also publish a feed of their events, which your system could automatically filter and notify whenever they’ll be performing in your area, potentially with user-defined notifications (LN 019) using automations (LN 021) under the hood.

Transclusion as a primary property of an itemized OS (LN 002, LN 003) means that published items can be richly embedded within others. If you’re writing an article, it could have items of any type embedded within it, such as an episode of a podcast that you’re referencing, which your readers can play inline for greater context. Then, a paragraph from your published article could be transcluded into another article in the future.

And since items can reference any other, the recording musician could include a note with their latest song release to share some details or thoughts with their fans, or an item that points to their merch store or a music video for the track.

In the itemized OS, items are rendered by item views. You can swap or modify views that render your items (LN 006), or even create entirely new ones (LN 009). When publishing an item, you can design an item view to go with it, and users can view your item with that view by default. And since we already have view builders for item views, that means we’d have easy tools for users to lay out their published items without code, if preferred.

If you load something of a type you have your own item views for, you could use those views instead. You might prefer to read an article in a view that is more legible for you, for example, using specific contrast or type settings. Or if you prefer to see the item as the publisher designed it, you can view it with their included item view.

If you find a published item of a type your system has never seen before, your system loads the item with the item view that the publisher included. In a way, this lets your system learn new abilities, and it lets item publishers provide remote systems with instructions on how to render new kinds of data. This means that all the itemized systems connected to the itemized internet are evolvable systems: they can learn new things from each other without a software update.

This arrangement means that something resembling a website inherently has the sitemap published with it, and something resembling an RSS feed can be viewed as RSS feeds are today, or with the aesthetic styling provided by the author (something I’ve long wanted as a user of RSS, to enjoy people’s articles with the basic styling that they’ve chosen for their websites).

This arrangement also advances support for a vast landscape of accessibility needs; instead of mapping interfaces designed for one set of abilities into other interfaces, an often inferior result, the right interfaces can be designed for use with consuming others’ published items.

In LN 024, we explored mutations, which describe the changes made to items. Your system can use mutations to allow you to set up notifications or other automations on the things that matter most to you. You could add a published item to your system, and receive their mutations whenever they are changed or updated, if you wish.

For example, you might be attending an event, or catching a flight. The item representing the event or flight would be published with all the pertinent details. You could set up a notification if the item changes (which you could limit to just one field, like status or time, or keep it open to any change). This way, your devices would watch for mutations to let you know if the flight or event has changed.

You could set up automations based on these mutations beyond notifications (which are automations themselves — similarly, “subscribing” to some feed of things could be, under the hood, simply an automation that responds to changes of the root item).

And of course, much of the power with itemized, published things is in the fundamentals we’ve already explored. For example: when you bring published items into your own workspaces, you can work with them alongside the items of your own, as we saw in LN 004.