The Big Calendar here in Bloomington is one fed by other calendars kind enough to syndicate themselves through publishing feeds. It is put together by my friend Dave Askins, who writes and publishes the B Square Bulletin. Technically speaking, it runs on WordPress, and uses a plug-in called ICS. Dave is steadily improving it, mostly by including more feeds. But he also has a larger idea: one that satisfies the requirements I’ve been outlining in posts about deep (and deeper), wide, and whole news, plus a community’s (and journalism’s) need for facts and not just stories.
What Dave suggests is a whole new platform, just for community calendars. He calls it DatePress (modeled on WordPress), and describes it this way:
A bigger idea for community calendars
WordPress is a fantastic platform for running all kinds of websites—from news sites that generate lots of chronological posts, to websites that are mostly static, and serve up encyclopedic information.
For added, very specific functionality, WordPress fosters a robust ecosystem of plugins.
But there’s one kind of plug-in that is worth developing as a platform in its own right: a feed-based calendar. What if the whole point of the website is to host a feed-based community calendar? Such as this one here. We can do that with the WordPress ICS Calendar plug-in, as we do at that link. But why use a plug-in to do a platform’s job?
DatePress
Let’s call this as yet undeveloped calendar platform DatePress, just as a placeholder. DatePress would be a calendar hosting web engine that is built from the ground up to host feed-based calendars. Maybe some enterprising soul develops a plug-in for DatePress that allows a user to add a blog to their calendar. But the one job for DatePress would be: Publish community calendars.
DatePress does what?
What kind of functions should DatePress have? For starters, it should have the kind of features that the WordPress ICS Calendar plug-in already includes. Specifically:
- It should be easy to add feeds to a calendar, and specify a background color and label for each feed.
- The published display should include ways for a visitor to the published calendar to filter by typing into a box.
- The published display should make it possible to add any individual feed displayed by the published calendar to their personal calendar.
But there should be so many more tools for calendar administrators..
- For any calendar feed, it should be possible to add a prefix to any event title in a specific feed, to help people who visit the published calendar understand what kind of event it is, without clicking through.
- For any calendar feed, it should be possible to assign multiple tags, and it should be possible for calendar visitors to filter by tag.
- For any view that a visitor to the published calendar generates with a filter, the parameters for that view should be passed to the URL window, so that a visitor can send someone a link to that view, or embed that specific view of the calendar in their own website. That view should also define a new feed, to which someone can subscribe.
DatePress itself should know all about the content of feeds:
- Duplicate events across feeds should be automatically identified and collapsed into a single event.
- When a feed is slightly non-compliant with the standard, behind the scenes, DatePress should be able to convert the feed into one that is 100-percent compliant.
Why does DatePress need different levels of logged-in users, which really demands that it be a platform? Here’s how that looks:
- Only some users, like the administrator, should be able to add or delete feeds from the calendar.
- A curator should be able to manually flag events across all feeds—and all the events flagged by some curator would define a new feed. Visitors to the published calendar should be able to look at events by curator, and to add the curator’s feed to their own personal calendar. A curator should be able to embed a display of their curated calendar into their own website.
- Annotators could add information to event displays, especially after an event is over. After the events are over, their status will change to “archived.” Annotations could include a simple confirmation that the event took place. Or maybe an annotation includes a caution that the event did not actually take place, because it was canceled. Annotations could include links to published news articles about the event. The calendar archive becomes a draft of a historical timeline for everything that happened in some place.
Let’s please build this thing called DatePress.
I think this is a great idea that can start to do all of these things and more:
Please add your own.
The images up top are among the best of the hundreds I’ve had Bing Create produce using DALL-E3. The prompt for these four was, “A library building with the name Date Press (spelled exactly that way) over the door. The roof and walls are calendars.” I insisted on exact spelling because without it the AI left out letters, obscured them, or added extra ones. I also separated Date and Press because it always screwed up “DatePress” when it was prompted with that as a word. And it never liked lower case letters, preferring always to use upper case. Visual AI is crazy and fun, but getting what one wants from it is a little like steering a cat by the tail.
Welcome to my new old blog.
My old-old (but not oldest) blog—the one I’ve written since 2007—is still there, in complete archival form, at blogs.harvard.edu/doc, where it has always been. It is now also here with a different URL: doc.searls.com, which had pointed at blogs.harvard.edu/doc for many years. Now it points here, to its native location. No more redirecting.
Put another way, doc.searls.com was a Harvard blog until yesterday (and again, everything until that day remains so: that’s its legacy). From now on, it’s mine alone. It has crossed from one state to another. I’m not sure yet how it will change, if at all. But I feel energized about what I might do with it.
So, before I hit the gas here, I want to thank Dave Winer for getting me going as a blogger in the first place with my original blog (archived at weblog.searls.com) in 1999, again with this one in 2007, and now in this new location on the Web.
I also thank old and new friends who helped me make all the transitions involved—especially the Berkman Klein Center. It is as good a friend and colleague as an institution can be.
And yes, I know this blog needs a fresh new theme. Recommendations are invited.
Glenn Fleishman has a lucid and helpful introduction to Mastodon in TidBITS that opens with this:
Cast your mind back to the first time you experienced joy and wonder on the Internet. Do you worry you’ll never be able to capture that sense again? If so, it’s worth wading gently into the world of Mastodon microblogging to see if it offers something fresh and delightful. It might remind you—as it does me, at least for now—of the days when you didn’t view online interactions with some level of dread.
Mastodon isn’t a service but a network of consensually affiliated, independently operated servers running the Mastodon software. It’s the best-known example of the so-called Fediverse…
Then, a few paragraphs later, he provides the best metaphor I’ve yet seen for what Mastodon is and how it works:
You can think of Mastodon as a flotilla of boats of vastly different sizes, whereas Twitter is like being on a cruise ship the size of a continent. Some Mastodon boats might be cruise liners with as many as 50,000 passengers; others are just dinghies with a single occupant! The admin of each instance—the captain of your particular boat—might make arbitrary decisions you disagree with as heartily as with any commercial operator’s tacks and turns. But you’re not stuck on your boat, with abandoning ship as the only alternative. Instead, you can hop from one boat to another without losing your place in the flotilla community. Parts of a flotilla can also splinter off and form their own disconnected groups, but no boat, however large, is in charge of the community.
Since my day job is working as a visiting scholar in the Ostrom Workshop at Indiana University, and Customer Commons has been imagined from its start as a potential commons for customers (or as many commons, flotilla style), I find myself wondering if each of Mastodon’s boats is a commons. Or if some of them could be, or already are. Or if Mastodon itself is one.
My first experience with Mastodon came early on, in a boat that I abandoned before it sank. But now that Mastodon is hot again, I’ve jumped with two crowds onto two boats: twit.social (here) and journa.host (here). TWiT.social’s occupants are the community of hosts, co-hosts, and participants in the TWiT network. Journa.host’s occupants are a collection of journalists. The two communities are different, though not entirely: journalists abound in both of them.
The question for me here is if any of these boats qualify as a commons. Or if Mastodon itself is one.
To qualify as a commons, a canonical list to check off is provided by Elinor Ostrom. In Governing the Commons (Cambridge, 1990), she outlined eight “design principles” for stable local common pool resource (CPR) management. I’ll make notes following each in italics:
Ostrom and others have also gone deeper and wider than that, for example by examining socio-ecological systems (SESes), defined here in 2004. I’ll leave digging into that up to scholars more schooled than I (or to a later post, after I finish schooling myself). Meanwhile, I think it’s important, given the sudden growth of Mastodon and other federated systems with flotilla-ish qualities, to examine how deep research and writing on commons apply.
This work does matter: Ostrom won a Nobel Prize for it, and it may matter more now than ever.
And help is welcome.
About the photo up top: Lacking a royalty-free visual for a flotilla of boats, I settled on the collections of people you see through bubbles in the photo above, which I shot on the grounds of Versailles. Kinda works, methinks.
