opened 08:01AM - 17 Mar 26 UTC
Conduct ["Hammock Driven Development"](https://www.youtube.com/watch?v=f84n5oFoZ…Bc) as per the recommendation of Rich Hickey, creator of Clojure.
Creating this issue in [follow-up](https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130#issuecomment-11737818) to fediverse discussion started by @dahlia ..
<img width="1105" height="808" alt="Slide from the presentation: Most of the biggest problems in software, are problems of Misconception" src="https://github.com/user-attachments/assets/524e1bd7-a04e-420d-b63c-f28b5064d5fc" />
<br><br>
In the README there's the assumption that people know very well what more or less the "Social API" C2S specification offers:
> The ActivityPub API provides an extremely flexible interface for building social applications. Because unlimited kinds of activities can be created by clients, novel applications can be built on top of the ActivityPub network.
>
>Unfortunately, the ActivityPub API has not been widely implemented in its read-write form, even by social platforms that implement the ActivityPub federation protocol.
>
>Instead, they often implement platform-specific APIs, with a narrow range of functionality.
And further on for Non Goals lists:
> Standardize a platform API, like the Mastodon API, for general use
These descriptions are insufficient to remove misconceptions around C2S and what opportunities it holds for the future of W3C ActivityPub technology adoption.
## Avoid misconception
The AP spec offers a social graph of addressible actors that exchange activities with an object payload, fully extensible. The fediverse-we-have supports microblogging, forums, and other existing-but-decentralized common social media functionality. The fediverse has hammered itself in narrow domains of Social Media content publishing. It has forked from the power that AP offers, and became something much narrower. While it satisfies app developers interested in these application domains, it has driven off most innovators who have a broader perspective on the future of social networking than that.
IMHO the ActivityPub API efforts offer the great opportunity to clearly separate..
1. Protocol layer. Where a rigorous design assures interoperability and extensibility requirements.
2. Solution layer. Where solution development builds apps (e.g. Mastodon) and services (e.g. Webshop).
Such that ActivityPub library implementations can guarantee interoperability, and used as a black box to do solution development _on top of_ the protocol by following good extensibility guidelines.
If I look at the issues in the tracker I see HUGE risk that misconceptions are carried over from S2S installed base reality, with all its protocol decay. Simply put:
- Yes, Mastodon should be able to migrate from Mastodon API to ActivityPub API with (near) feature-completeness.
- But if app-specific abstractions leak into the ActivityPub API, mingling protocol with solution design, then C2S efforts will fail to deliver on the opportunity that exists.
The issues are riddled with references to app-specific concepts that should become part of solution design, supported by the protocol, but _not part of it_. For instance the notion of a "post" in the sense of `Note` or `Article`, or the assumption that an actor has an "avatar". These are things they MAY have, but as part a particular solution design.