2 ms·

>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 understan

>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.

nightpool 3y ago
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.

nightpool 3y ago

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.