The TL;DR: ActivityPub is purposefully an incomplete protocol. Communities need to build additional specs on top of it.

New problem: how to collaborate on and discover these community specs.

@ben They don't compete with ActivityPub, they compete on ActivityPub.

@cj ActivityPub is the new standard being invented that doesn't help in this analogy

@ben Ah. I get the jist, but that's a pretty non-specific criticism. 927 gets thrown around a lot. Anything that's a protocol could be criticized this way, the question is what other protocols is ActivityPub redundant of. But that would've been more appropriate for SocialCG while they were standardizing it.

I'm not championing any effort that's meant to unify /replace a protocol, fwiw. Merely suggesting building on an existing protocol. So I don't find 927 too applicable here.

@cj defining a protocol in such a way that you need to define another protocol on top of it to do the thing the first protocol was supposed to do strikes me as "creating a solution and looking for a problem to assign it to".

@ben Did you read my blog post and refuse to accept my philosophy/viewpoint because the philosophy you have is precisely the one I call out and compare it to.

ActivityPub isn't meant to solve any specific domain problems. It just so happens to have a bad "extension" for the social media domain coupled and bundled with the original spec.

If you don't share this view, that's fine.

@cj I haven't read the post yet, just the TL;DR reply so far.

@ben OK, good to know. I was worried if I had fucked up my post and hadn't clearly communicated on this point. I'm not a great writer and I don't put myself out there often so I am a little extra jumpy. Sorry if it comes across as snappy!

@ben Ethernet needs IP on top of it. IP needs TCP (and UDP). TCP needs HTTP (and SMTP and …). And so on; there's nothing surprising about layering protocols.

What it sounds like from Cory's description is that ActivityPub is analogous to mixing up the IP and TCP specifications but then saying, oh, you can take the IP part and build UDP and other protocols on top of it if you like.


@cj sounds like XMPP except without a standards foundation


> New problem: how to collaborate on and discover these community specs.

Indeed a problem. Drawing attention to:

And adding #ActivityPub hashtag ;)

Thanks for writing. Very valid points in the article.

@cj great read! what specs are we talking about tho? forge pub didn't and (seems like) won't deliver anything

@21stio It could be LitePub, ValueFlows, and MoodleNet. That's all I know of now, if ForgeFed is dead.

@cj interesting, as the scope is still very manageable right now, would it maybe make sense to just have a repo with a and a json.ld linking to all the specs for now?

Lately there had been several blog posts about AP. Some days I published one as well:…

@heluecht Yes and I have read it! Great read, very detailed. I wanted to do something similar, but I wound up moving all of mine out of this post for a later one during editing and proofreading.

@cj I don’t share the fantasy you added at the end but your stance of treating it as an incomplete spec that needs elaborating per use case makes sense and explains a lot of the acrimony I’ve seen. Sadly, it also explains why implementing an app for the Mastodon client protocol is so much easier. And personally, I wonder where I could find #wiki developers thinking about a wiki flavor. πŸ˜€

@kensanata Yeah the concrete fantasy I wanted to provide in addition to the abstract philosophy. Because a philosophy that can't be concretely applied in the real world begs the question whether it is useful.

Did you have a different one that seems more realistic?

@cj i was thinking about @kaniini who said the protocol needed work and extensions and that needed coordinating between developers of the various platforms but the next step is organizing. So my fantasy is somebody bringing others onboard, and people meeting at a conference getting onboard, and a proposal written, an old school RFC with two independent implementations, that kind of thing.

@cj i also don’t mind developers implementing something first and then writing about it Dave Winer (RSS, XML-RPC) style. First versions may be flawed but they solve a problem and then better solutions evolve.

@kensanata Gotcha. I am not familiar with all of these examples so I got some history to brush up on.

But basically it's this: to push ahead with something that works, prove its utility, weather the storm of all the people who wanted to have a say but didn't want to put in the hours, and you're right in the middle of all the social conflicts ever. I don't think it's easy, but at the same time I often think this is how stuff gets done.

I think that coordination between the implementers is essential. Additionally to creating a follow up to the current protocol, I guess we need a quick response if some developer wants to implement something that no one had implemented before. For example: Someone wants to implement the XMPP address in the profile, then the question is, how the field should be named. (and such stuff)

@kensanata @cj what would an AP-enabled wiki be like? How would it differ from subscribing to a β€œchanges” RSS feed of a wiki? Honest question, that is the closest analog I can think of to base a diff from :). Also Ward C already has a federated wiki platform , do you see AP working there too? I have to stop or I’ll be back to implementing another wiki engine that never sees the light of day!

@jos Well, my blog is a wiki, and it has comment pages. Currently you can follow @kensanata which is the feed of the blog pages on my wiki, but if you comment on it, nobody gets notified, and the comments don't show up on the wiki, either. That would be a first step, I think.
The next element would be integrating favourites. Those would be interesting activities from other actors back to the wiki.

@jos Other ideas would be spreading the namespace, even without the page content. This allows us to Near Link without federating page content.
But full federation would be interesting, too. I don't think that wiki editors would follow wiki editors on other sites, but one wiki admin could decide to pull in all the pages from another AP enabled wiki, for example. We could do it via a complete import using RSS, though.
@kensanata @cj

@jos Specially since there's a wiki extension for RSS:
So we can get richer meta data from other wikis supporting it. Adding support for remote comments and favourites seem to be the only two things that really require something totally different from RSS.

@cj The article itself is great. I’d suggest some borders left and right though for better readability on mobile.

@melgu Thanks for the feedback, I'll edit the css tonight for the mobile version. My blog is very roughshod.

@melgu I have added padding, please let me know if you still see it without padding on mobile.

@cj i just tested on another phone. It works! Maybe some caching thing on my iPhone.

@cj thanks, I think your article follows the spirit of ActivityPub which is what it is: basis oh which everything else can be built.

@charlag Thanks. I hope the practical example was illustrative as well. I don't intend for it to be prescriptive, but help illustrate that such an abstract viewpoint does have concrete and practical uses.

@cj I think what you've written makes a lot of sense and aligns with the intentions of the people who worked on ActivityPub in the beginning (from what I can tell as an outsider watching the process unfold over years of work). Thanks for writing that.

@cj I think you've hit the nail on the head on all these points. Excellent post.

@cj Could you please set a css color for the text? Right now you're relying on the default one from the User-Agent and in my case (I use dark background and light text) the contrast is very poor. :)

@mariusor Yes, I can do that tonight when I get home! Sorry for the difficult read. :(

@mariusor Could you please double-check the article now with your defaults? I hope the font-color is now set properly.

@cj you added "font-color: black" but it should be "color". :)

@cj perfect. πŸ‘

But I understand now why you're working on libraries. :P

> Oh shit, I'm a scrub.

@cj We can delete the past messages, so nobody will know. :)

@cj I’d love to see ActivityPub kept as dumb as possible and have these extensions built at the messaging level but yes, love the approach.

@aral @cj Borrowing @cj 's transport vs. application layer OSI stack model that makes total sense. Should there be/is there be some standardization at the application layer as well? I guess there will be defacto standardization if one implementation gains critical mass if none is done explicitly...

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!

We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot CafΓ© list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators.

Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!