Recent searches
Search options
“...It’s okay if not everything gets to every user… It is a constantly evolving network, and there are new kinds of content on the network every day. It’s totally okay if we have different applications on the network, and maybe they don’t quite understand what each other is doing.” - @evan
We shouldn't accept that cross-platform incompatibility is a feature of the fediverse. We could solve this with vocabulary-agnostic servers and the ActivityPub API.
@joshshaked I think the path to getting there is by feeling comfortable putting things on the network even if Mastodon (for example) won't show it correctly. If we limit ourselves to what certain existing platforms support, we can't grow to that more exciting vision of the network.
@joshshaked But otherwise I'm 100% on board. We need ActivityPub API support and more general-purpose servers.
@joshshaked It's also worth noting that literally any Activity Streams object has fallback representations that can be used if the client doesn't recognize the type: `summary` for text, `image` and `icon` for visual. There's no reason to throw away unrecognized activity types.
@evan I didn't know that, I appreciate the knowledge drop. Additionally, I've been trying to figure out what is holding people back from adopting the C2S API. From my understanding, there was a nonzero chance the ActivityPub spec was launched w/o a S2S component!
@joshshaked Yes, the ActivityPub protocol was an optional deliverable for the Social Web Working Group. At the time (2014), the W3C thought that a standard API was more important.
@joshshaked The main thing that has held the ActivityPub API back is the mistaken idea that it's competing with, rather than complementing, per-product APIs like the Mastodon API.
@evan Interesting, I had always thought of them as competing. Are there any examples where a service-specific API has been implemented alongside the ActivityPub API?