Next Step for ActivityPub  ## Metadata - Author: [[Manton Reece]] - Full Title: Next Step for ActivityPub - Category: #articles - Document Note: ## 📝 Summarize: The article discusses the challenges of achieving interoperability on the fediverse, focusing on server-to-server ActivityPub implementation. The author shares their thoughts after listening to Dave Winer's audio recording and reflects on the complexities of ActivityPub and its impact on platforms like Mastodon and Micro.blog. They question whether a new social web platform can be built solely based on the ActivityPub specifications and still be compatible with Mastodon. The author argues that achieving compatibility is not feasible due to certain ambiguities and lack of precise details in the specs, which results in developers having to reverse-engineer existing servers. They emphasize the need for further simplification and a cohesive guide for developers to ensure compatibility among platforms. The ultimate goal is to enhance interoperability to foster the growth of the fediverse. ## 📝 Bullet Points: - Challenges of Interoperability on the Fediverse: - Difficulty in Implementing ActivityPub: - Ambiguities in Specifications - Lack of Precise Details and JSON Examples - Dependency on Monoculture: - Unavailability of Certain Features Outside Mastodon - Importance of Open Web and Extensions - The Fediverse's Current State: - Impressive Progress Thanks to Mastodon's Polish - Need for a Common Posting API - Focus on Server-to-Server Interoperability - Enhancing Interoperability: - A Comprehensive Guide for Developers - Simplification of ActivityStreams and JSON-LD - Consideration of Making JSON-LD Optional - Future Steps: - Supporting Threads to Join the Fediverse ## 📝 Paraphrase: 1. **Original:** "Is it possible to implement a social web platform by reading the suite of ActivityPub specs, and have that new platform be compatible with Mastodon? I would argue no, it is not possible." **Paraphrased:** The question at the heart of the article revolves around whether it's feasible to create a new social web platform solely based on the ActivityPub specs and still ensure compatibility with Mastodon. The author's viewpoint is that achieving such compatibility is not realistically attainable. 2. **Original:** "A lot of great work came out of the W3C’s Social Web Working Group, including IndieWeb standards, and I don’t think the authors had enough time to get consensus on some parts of ActivityPub before publishing, nor could they predict everything a platform like Mastodon or Micro.blog might need." **Paraphrased:** The W3C's Social Web Working Group has produced valuable contributions, including IndieWeb standards. However, the authors might not have had enough time to achieve full consensus on certain aspects of ActivityPub before publication, and they couldn't anticipate all the requirements that platforms like Mastodon or Micro.blog would demand. ## 📝 Conclusion: The article delves into the complexities of achieving interoperability on the fediverse, specifically focusing on the challenges of implementing server-to-server ActivityPub. The author argues that building a new social web platform solely based on ActivityPub specifications and ensuring compatibility with Mastodon is improbable due to ambiguities and lack of precise details in the specs. They call for a comprehensive guide to aid developers in creating platforms compatible with others. The article highlights the need for further simplification and considers making JSON-LD optional. By enhancing interoperability, the fediverse can continue its impressive progress, making it easier for new developers to contribute and expand the social web. ## ❓ Questions: 1. How can the fediverse overcome the challenges of ActivityPub's complexities to achieve true interoperability among diverse platforms? 2. What specific features or functionalities should be further clarified in the ActivityPub specs to ensure better compatibility with existing platforms like Mastodon? 3. How can developers strike a balance between adhering to ActivityPub specifications and meeting the unique requirements of their own platforms? 4. What are some potential risks of relying on a monoculture within the fediverse, and how can platforms encourage diversity and openness? 5. Besides ActivityPub, what other areas in the fediverse's ecosystem require attention to foster its growth and further enhance user experiences? ## 🔖 Auto-tagging: ActivityPub, Interoperability, Fediverse, Server-to-Server, Mastodon, Micro.blog, Social Web Platform, Specifications, Compatibility, JSON-LD, Simplification, Open Web, IndieWeb, Monoculture, Progress, Developers, Posting API, Threads. ## 📚 Index Creation: - ActivityPub: 3, 6 - Interoperability: 1, 5 - Fediverse: 1, 5 - Server-to-Server: 1, 5 - Mastodon: 3, 5, 8 - Micro.blog: 3, 8 - Social Web Platform: 1, 2, 8 - Specifications: 3, 6 - Compatibility: 3, 6 - JSON-LD: 8 - Simplification: 8 - Open Web: 7 - IndieWeb: 7 - Monoculture: 7 - Progress: 8 - Developers: 8 - Posting API: 8 - Threads: 8 ## 📑 Table of Contents: 1. Challenges of Interoperability on the Fediverse 1.1 Difficulty in Implementing ActivityPub 1.1.1 Ambiguities in Specifications 1.1.2 Lack of Precise Details and JSON Examples 1.2 Dependency on Monoculture 1.2.1 Unavailability of Certain Features Outside Mastodon 1.2.2 Importance of Open Web and Extensions 2. The Fediverse's Current State 2.1 Impressive Progress Thanks to Mastodon's Polish 2.2 Need for a Common Posting API 2.3 Focus on Server-to-Server Interoperability 3. Enhancing Interoperability 3.1 A Comprehensive Guide for Developers 3.2 Simplification of ActivityStreams and JSON-LD 3.3 Consideration of Making JSON-LD Optional 4. Future Steps 4.1 Supporting Threads to Join the Fediverse ## 📚 References: - Dave Winer's Blog: [Link to the article] (insert URL here) ## 🕵️‍♂️ Future Research: - Investigate specific areas in ActivityPub specifications that lack precise details and create guidelines for implementation to achieve better compatibility among platforms. - Explore the potential consequences of relying on a monoculture within the fediverse and propose strategies to encourage platform diversity and openness. - Examine the feasibility of streamlining ActivityStreams and JSON-LD to create a minimalistic version that caters to most server needs without compromising interoperability. - Study the requirements and challenges of implementing a common posting API to enhance the user experience and facilitate seamless interactions between platforms. ## 🕯️ Hypotheses: 1. Platforms implementing ActivityPub can achieve higher compatibility with Mastodon by adhering to both the specifications and Mastodon's own documentation. 2. Simplifying ActivityStreams and making JSON-LD optional would result in increased adoption of ActivityPub by new developers, fostering platform diversity and growth. 3. A comprehensive guide that ties together various ActivityPub specifications would facilitate the development of compatible social web platforms, reducing the need for reverse-engineering. ## 🔬 Methodology - Document Tags: [[ActivityPub]] [[Fediverse]] - Summary: Dave Winer posted a 12-minute audio recording on his blog, addressed to me but applicable to everyone who is creating tools for the social web. Listening to it, I have a bunch of thoughts. In this post, I just want to start with server-to-server ActivityPub, and leave some of the other technologies Dave brings up for later. A few days ago I was revisiting the ActivityPub code in Micro.blog because we have some interoperability problems with Calckey, now called Firefish. - URL: https://www.manton.org/2023/07/25/next-step-for.html Dave Winer posted [a 12-minute audio recording on his blog](http://scripting.com/2023/07/24.html), addressed to me but applicable to everyone who is creating tools for the social web. Listening to it, I have a bunch of thoughts. In this post, I just want to start with server-to-server ActivityPub, and leave some of the other technologies Dave brings up for later. A few days ago I was revisiting the ActivityPub code in Micro.blog because we have some interoperability problems with Calckey, now called Firefish. Firefish is a Mastodon-like platform with a few unique design twists and features. To narrow down where things were going wrong, I read through the ActivityPub spec again and also looked at JSON responses from other platforms like Mastodon and Bridgy Fed. To frame this blog post I’ll put forward this question, at the heart of interoperability on the fediverse: > Is it possible to implement a social web platform by reading the suite of ActivityPub specs, and have that new platform be compatible with Mastodon? > > I would argue no, it is not possible. A new project would only be compatible with Mastodon by accident because there are some things that are not spelled out in precise detail in the specifications, and no JSON examples that exactly match what any server sends or expects. The specs have all the pieces, but not how to fit those pieces together. In addition to the specs, [Mastodon’s own documentation](https://docs.joinmastodon.org/spec/activitypub/) is very good, and it has improved even in the last year. But again, if you ask a developer to implement ActivityPub, they will naturally start at the W3C. I hope this doesn’t sound overly critical. The fact is, ActivityPub is complicated, and by design this kind of architecture can only be simplified so much. A lot of great work came out of the W3C’s Social Web Working Group, including IndieWeb standards, and I don’t think the authors had enough time to get consensus on some parts of ActivityPub before publishing, nor could they predict everything a platform like Mastodon or Micro.blog might need. Recently, Evan Prodromou has been leading the effort to address GitHub issues and move things forward. I said “suite” of ActivityPub specs above because ActivityPub is not really one thing. There’s the [ActivityPub spec](https://www.w3.org/TR/activitypub/) itself, but also [ActivityStreams](https://www.w3.org/TR/activitystreams-core/), [HTTP Signatures](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures), [WebFinger](https://datatracker.ietf.org/doc/html/rfc7033), [JSON-LD](https://json-ld.org), and the working group [note on authentication](https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization). And there are other features, such as account migration between instances, that are not documented outside of Mastodon. This is why the [IndieWeb principles](https://indieweb.org/principles) warn of monoculture. We are lucky that Mastodon cares deeply about the open web, because other dominant platforms might have less incentive to make their extensions work outside their own ecosystem. The current fediverse is impressive. It’s further along than most people would’ve guessed possible a few years ago, largely thanks to Mastodon’s polish and Twitter’s implosion. The next step should be getting to the point where the answer to my question above can be “yes”. How can new developers add support for ActivityPub without feeling like they are reverse-engineering every existing server? We don’t necessarily need a new spec, although it would be helpful to have a single document that ties everything together — a guide that a developer could use to build something and be confident that it has a chance of being compatible with other platforms. I also think we should consider further simplification, such as making JSON-LD optional (!) and drafting a streamlined version of ActivityStreams with only the bare minimum object types that most servers need. There is a lot of work to do, even outside of ActivityPub. As Dave mentions, we also need a common posting API. The most popular Mastodon client apps do not support either ActivityPub or Micropub. But a lot of progress can be made focusing on interoperability for the server-to-server part of the API. That should be the top priority with Threads set to join the fediverse., Next Step for ActivityPub, Manton Reece, 01h66x4293r7gtbqbsyr8ep0m0.