I disagree. I think most of the people in this thread are promoting Activitypub merely as a starting point. Sure, it could use some tweaks and improvements, but it's a good foundation to build on.
Your previous comment came closer to the truth: ActivityPub may work today _as a workaround_, a half-baked alternative to closed silos; but it doesn't have a solid foundation, its problems can't be solved by tweaks and improvements, and that's what every of its critics say.
I think this is going to be an "agree to disagree" situation. Frankly, I think Activitypub is just fine as the basis for building Twitter alternatives. Most complaints I've read about it are from people who dislike its lack of privacy and of the necessity of trusting servers with regards to private messages. I think those people are trying to fit a square peg in a round hole.
I'm actually building an Activitypub implementation myself. I quite like the protocol and the philosophy of "twitter without Twitter Inc.", but I'm thoroughly sick and tired of the rube goldberg "framework on top of framework on top of framework on top of obscure language for the backend" insanity that comes with the usual implementations. So I decided to do something about it. I'm working on an Activitypub server in Go, sqlite, and a pure vanilla javascript frontend. My goal is to have this be dead simple to install and maintain on a barebones VPS for anyone with a modicum of Linux commandline experience. One static binary, one small config file, one folder with a handful of javascript/css resources and html templates. And that's it. No bloody vue, react, angular, ember, or rails. And definitely no f---ing node.
