@PuercoPop @thisismissem You raise a really good point. You're right that different types of applications have different needs, and a one-size-fits-all approach probably isn't ideal.

I think this actually aligns with what I was considering—not a universal API for the entire fediverse, but rather domain-specific standardized APIs that share common patterns where it makes sense.

For example, we might have:

• A standardized GraphQL API for microblogging platforms (Mastodon, Pleroma, Misskey)
• A different standardized API for discussion/forum platforms (Lemmy, Mbin, PieFed)
• Yet another for media-centric platforms (PeerTube, Pixelfed)

Each domain would have APIs optimized for their specific use cases, but they could share common patterns, authentication methods, and even some base types.

This approach would still give us the benefits of standardization within each domain (better tooling, consistent developer experience) while acknowledging the fundamental differences between these application types.

@hongminhee @thisismissem @PuercoPop

For your information, I recently opened an issue to track current #ActivityPub C2S implementations.

This is the list thus far:

#ActivityPods
#Epicyon
#Onepage.pub
#Pleroma
#RDFPub
#Vocata
#FedBOX
#Mitra
#streams
#forte

https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130

Client-side #AndStatus is a well-known attempt to implement it:

https://github.com/andstatus/andstatus/issues/499