ActivityPub is popular because it solves a vital problem, which is fine. But the protocol itself as a protocol, in my unfair opinion, is way too loose and basically results in little single-app fiefdoms that communicate outside their borders poorly if at all. I don't know what the solution is, but it definitely is a problem that didn't need to exist in its current severe form.
Yep. Reading the spec gave me the impression that the authors wanted to create something that can do literally everything, not realizing that that makes it impossible to “fully” implement the spec.
Does your application correctly render when I dislike the fact that a user removed a file from a group? That’s something you can represent in ActivityPub.
You can make a protocol that allows for not-yet-defined behavior, or has parts that are prescribed to work in a certain way if you're choosing to implement some certain behavior although you're not required to. The 7-layer OSI model and SMTP-email headers are two good examples. Even grafting encrypted or multimedia email on top worked, more or less, reasonably well and was still interoperable for the most part. They could have used that type of thing as a starting point, instead of doing the equivalent of "well we don't want to constrain what types of networking applications you might want to implement, so we're just gonna specify the from and to addresses. You do your checksumming and MTU management the way YOUR application wants to do it."
I mean I'm not gonna sit too much in judgement of someone who created something which is working and producing good things but it's hard not to be wistful about how much better it could be if the spec was specific enough that the different apps could substantively talk to one another.
fediversity.site
Hot