Non-Microblogging Software Design on the Fediverse

Postmarks is a piece of Fediverse software meant to provide a social bookmarking platform along the lines of De.licio.us and its successors. Despite the published ActivityPub spec having in mind a variety of verbs and nouns, and the ability to create "extensions", most software that I found while looking around in the early days of Postmarks looked to be recreating "timeline-based social media", where the primary activity took place on the platform itself and involved reading content from other users and generating more content of the same expectations. This is not to say there are none, but how much they expect to integrate with platforms like Mastodon varies.

When thinking about what that meant for Postmarks, deciding how interoperability should work presents some interesting questions. There are opportunities in interoperability: even if you're not the kind of person to whom the activity of bookmarking and curating links is interesting, you may know someone who does whose work you want to follow, which you can then do from Mastodon. On the flipside, you may be a researcher who spends time collecting information and values the viewpoints of others but doesn't want to take part in a product designed like a traditional social media site. There are also drawbacks: as an individual maintainer with a handful of contributors to my platform, integrating with existing platforms that are already large enough to have abusers, scrapers, and other bad actors opens me up to those problems much sooner than it would if I were creating my own siloed ecosystem. Less urgently, there are new software design questions raised by the functionality of the platforms interacting. How do I make Postmarks content appear on platforms like Mastodon? As I build out the ability to find bookmarkable content from the Fediverse within Postmarks, how do I do that in a way that keeps in mind the ideals of Postmarks rather than the spaces it's connecting to? What choices have been made that add extra requirements on top of the ActivityPub spec in order to make interoperability smooth and consistent? In designing a piece of ActivityPub software designed to have one small "instance" that hosts the activity of one "actor", I also found myself stumbling across design decisions made in the creation of large platforms like Mastodon and Pixelfed that left me with questions about the ethics of designing software that can interact with those places. How do I prevent my software from becoming a tool for bad actors targeting those places?

By looking at the design problems introduced within the early development of Postmarks and an analysis of other ActivityPub platforms that have either dealt with, are still working on, or have not faced these questions, we can create space for discussing what a future looks like where a broad variety of ActivityPub software is out on the internet speaking the same protocol but choosing when and how they interact in a way that cultivates communication and works to minimize harm.