By "the Mastodon API" I'm referring to the REST API used by Mastodon clients, not the activitypub "plus" API used by other servers to federate with them.
> FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone
I understand that it may appear like that from a user perspective, but from a protocol perspective the ActivityPub representation is strictly more generic and extensible. Both directions (from mastodon and too mastodon) are very, very lossy. All mainstream servers (except maybe pleroma derivatives) do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for
>All mainstream servers ... do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for
I understand what you mean by "the Mastodon API" but I think we're talking past each other; this does not seem like a client design problem but a protocol problem.
I would like to contend that the ActivityPub spec is too vague and thus clients are forced to do this "squishing" in order to find a portion of the spec that is sufficiently well-defined as to actually be practical for a specific use-case like a federating Twitter clone.
As far as I can tell, there's an echo of this lack of definition in the ActivityPub (and actually more specifically, in the ActivityStreams) specification if you do a tour of the ecosystem of implementations, you'll find that almost all of them are in dynamically typed high-level languages like Ruby (Mastodon). Implementations in languages like Go where JSON deserialization must be defined per-type have a very hard time with ActivityStreams and you'll find that Go implementations of ActivityPub like go-fed are much more narrowly scoped in their functionality in order to avoid this problem.
I have wasted many, many hours on ActivityPub, and I am extremely sad to make this comment, because I understand why it was invented.. but I'm not sure it's really good enough to achieve its goals.
The fact that some Go libraries use struct-based deserialization for processing ActivityPub is frankly an implementation issue. Your language choice should not make a difference in how easy you find it to implement something. go-fed could have been implemented 10x more easily using maps, without having to resort to reams of code generation to implement things that dynamic languages implement "trivially".
My feeling is that nobody has given a serious AP C2S client implementation (where the narrowing / "squishing" happens on the client side, as defined by the spec, and the server-side is agnostic) a serious effort. It increases client complexity, yes, and there needs to be extensions to the AP spec to make it work, but I think there are a lot of benefits to it that haven't yet been fully explored.
I don't think the future of ActivityPub is locked-down implementations like Go that have super strict type safety rules. That's just at odds with what real decentralized protocols have proven to work (HTML, HTTP, SMTP, MIME—all have "open ended" extension mechanisms). I think a pluggable client infrastructure that allows multiple different "types" of clients to share the same agnostic backend server is a much stronger path forward for future development.
> FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone
I understand that it may appear like that from a user perspective, but from a protocol perspective the ActivityPub representation is strictly more generic and extensible. Both directions (from mastodon and too mastodon) are very, very lossy. All mainstream servers (except maybe pleroma derivatives) do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for