Hey SocialHub! 
This is my first post here. I’ve been exploring Fedi for the better part of two years, but I’ve only recently become interested in properly understanding the spec.
I have a little shell alias to make ActivityPub requests with curl, and I sometimes use it on random links out of curiosity. And doing so has made me curious about the potential of ActivityStreams objects in a C2S context.
If you exposed a client to an ActivityStreams object, I think it’d be pretty trivial to write a client that can render any kind of object. Right?
The biggest problem with Fedi imo is the lack of cohesion. Mastodon is strictly written to handle microblogging, and so that’s all its database will store and all its API is written for. As a consequence of Mastodon being so huge, microblogging has basically become Fedi’s main schtick. Anything outside of that requires a separate ecosystem.
Case in point, when viewing a PeerTube video from Microfedi (microblogging Fedi), it’s just a link to view the video on the original website. But the ActivityStreams object of a PeerTube video contains all the information a client would need to view the video natively. So, why should I need a separate app to view a PeerTube video?
I think ActivityPub implementations are limiting this kind of progress by ignoring C2S. Especially when ActivityStreams is so rich with context that can used by those clients.
We’re also in danger of EEE if corpos create this wholistic version of the Fediverse first.
Federating recipes 
Imagine I wanted to define a Recipe object.
The main purpose of a Recipe object would be to list ingredients explicitly, with a standardized set of names for each measurement. This provides additional context for a client to do some interesting things. Like maybe we want to convert the measurements into metric, or add an ingredient we don’t have to our shopping list.
Under the current paradigm, this object can only be displayed in the context of a “Federated recipe platform!” 
The object might look something like this:
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1"
],
"id": "https://example.com/recipes/8420582323800",
"type": ["Recipe", "Article"],
"name": "Macadamia Nut Cookies",
"summary": "<p>I found this in my grandma's old cook book!</p>",
"content": "<p>In a large mixing bowl, whisk together the flour, baking soda,..</p>.",
"attributedTo": "https://example.com/actor/cat",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://example.com/actor/cat/followers"
],
"attachment": [
{
"type": "Image",
"content": "The cookies in question 😋",
"url": "https://example.org/static/53489992380692642.jpeg"
},
{
"type": "Ingredient",
"name": "All-purpose flour",
"units": "cups",
"measurement": 2.5
},
{
"type": "Ingredient",
"name": "Baking soda",
"units": "tsp",
"measurement": 1
}
...
]
}
Alright, so let’s say I bite the bullet and make a Fediverse recipe platform 
A blog server like Plume might fetch this and recognize it as an article; but the reader can’t view the ingredients, and so they can’t make the recipe!
Ideally, ActivityStreams definitions should contain as much context as reasonable, while also re-using keywords in places where it makes sense to. However, an ingredient really must be expressed and interpretted as an ingredient for this to work.
One alternative is to define an Ingredient additionally as a similar object. Or, you could accept that there will always be some unfederated data. To me, the ideal solution is to offload the rendering of this information to the client.
Retooling ActivityPub could solve problems with the rest of the internet
I’ve spent some time exploring Geminispace, and listening to people complain about the current shape of the web. (Daily reminder that Chromium has 35 million lines of code.) Also, try looking actually looking for a recipe online. Ads galore.
But something about the Gemtext solution of “just simplify the markup” feels wrong.
I think I’ve settled on the opinion that building the internet around a markup language was a bad idea. Sure, it’s cool to zip around from site to site, knowing you’re seeing it as the author intended. However, there are really important things that markup cannot express. This is evidenced by the fact that every service under the sun feels the need to have their own special API.
I think the web should be built around a vocabulary that can express action, intent, and context - like ActivityStreams - instead.
Conclusion
Thanks for reading. I really wanna know what this community thinks about this perspective 
and you are spot on in those observations. On one hand we are quite happy about the growth in numbers and developer interest caused by The Muskening™. OTOH there are fears for corporate capture, upto EEE and changing cultures (Eternal September).
I’m more interested in progressing C2S at the moment.