@kaniini There are a couple of good points in here, but this is a really cynical take on AP.

I'd agree it has some blindspots that need to be addressed, but lines such as "In an ideal world, the number of ActivityPub implementations would be zero." is pure hyperbole.

Further I would give it more deference if it presented a viable option as opposed to "this is bad, but I don't know how to do it better"

We gotta do better than this if we are to push forward.

@Are0h That's part of the upcoming series. And it's kinda been hinted at on their timelines (leveraging facets of Zot's apporach, using capability URIs vs implied actions, etc) @kaniini

@jalcine Aight, cool. Hopefully will get better because this isn't a great start.

There are some salient points about security that I absolutely agree with, but most of it just seems like editorializing.

I'd rather see problems identified and then explorations of possible ways to improve.

But I guess they're saving that for later. I hope.


@Are0h @kaniini @jalcine

well, this was meant to be kind of an explanatory post of what my present world view is on activitypub, having spent a year basically bringing up an AP implementation from scratch, and working in a codebase which built on AS2 with some elements of AP as a data model.

so it basically *is* editorializing on the topic.

the next blog post in that series that i'm working out in my head actually has to do with what a merged AP + Zot6 type protocol might look like, and what is good and bad about that. it will also attempt to explain in detail why tying personal identity and cryptographic tokens together is fundamentally unwise (although my post about Blind Key Rotation went into some explanation on why that is unwise too), and introduce a construction of capability URIs and proof responses as an alternative.

@kaniini @kaniini @jalcine

Yeah I know. I just think that's a poor way of going about it.

The proliferation of AP is providing a real opportunity for us to not only think about how we communicate but more effective ways to do it, a couple of which you name, which is cool.

I'm so down w/ the protocol being changed in a way that makes it better, but saying we shouldn't be using it at all is step backwards.

Cool. I'll wait for that. I really want to see viable options. Especially if they work

@Are0h @jalcine @kaniini I think one challenge we have to think about here is how we might be able to positively affect future versions of the protocol spec.

For better or for worse, this whole thing sits in the realm of WC3, and in some ways is the byproduct of attempting to please the multiple groups that populated the SocialWG. You've got Linked Data and IndieWeb people shoehorned into the same space as fedi developers, and many members of the group representing corporate entities that might be interested in a narrow application of it.

So far, the process for advancing the protocol to a new version that is, for example, aware of the notion of OCAP, is largely undefined beyond writing a whitepaper, putting out a CFP, and hoping other people in the space will adopt it.

@sean @kaniini @jalcine AP is popular because it's simple and it works. I absolutely agree the design isn't perfect because it does have some gaping holes, but as a protocol framework, it's really solid.

I say we build on that rather than lamenting the fact an imperfect idea is getting traction.

With all of these big brains floating around the fediverse, I know we can do better than 'this is bad, but I don't know the answer'.

This is such an opportunity to set a positive tone moving forward.

This. The challenge of federation is social, not technical. It's a much better situation to have an imperfect protocol that everyone uses than to endlessly iterate - every fork of the shared protocol splinters the network and gets us further away from the dream of an open, connected web.
@sean @kaniini @jalcine

@jdormit @Are0h @sean @kaniini Forking and splintering won't be too much of an issue with tight collaboration amongst projects and that's something the Fediverse has been pretty okay-ish at thus far. It's not like we're relying on a company to define things for us - it's people-driven

Sure, but what are the chances that competing protocols will actually maintain compatibility with each other? The web is built on a stack of shared protocols - imagine if every website didn't use HTTP! ActivityPub is a 90% solution, and I think the last 10% can be built on top of it without breaking compatibility.

@Are0h @sean @kaniini


@jdormit @jalcine @Are0h @sean @kaniini I think AP is under-specced primarily due to constraints impose by W3C (time and otherwise) and a desire to formally pin down as much as possible while Mastodon was ploughing ahead with its implementation to minimize the risk of it rolling out too many bad ideas ad-hoc. I think Chris (Webber, co-editor of AP) is aware of the gaps and interested in seeing them filled. For example mentioning OCAP here: dustycloud.org/blog/spritely/

@msh @sean @Are0h @jalcine @jdormit

Mastodon indeed has caused some minor damage with their AP implementation by moving too quickly, but I think it's minimal compared to the overall under-specification that has occured.

It should also be noted that Mastodon's damage is also in part because Gargron and company were given bad security advice by the W3C Social CG.

The fact that we have to push for a mitigation in the form of rotating keys due to Mastodon's decision to adopt the highly flawed LDSigs signature scheme is an example of the damage caused by moving too quickly.

But we are moving towards mitigating those problems with Blind Key Rotation.

Of course, in an ideal world, no implementation would use LDSigs, and maybe we will eventually convince people to stick to constructions which make sense instead of just copying what Mastodon does.

But here's the thing, Chris wants to move away from technologies that work and towards the experimental stuff. I wish him all the best, but we need to ship things which people can believe in wrt trust & safety, and where we're at right now is not so great for that. I think before we start integrating I2P and DAT we should talk about getting the fundamentals right.

@jdormit @Are0h @jalcine @sean

I agree Mastodon itself has shown good restraint in only causing "minor damage" considering its out sized influence. That said Eugen seemed to be a bit of a catalyst in pulling such advice out of Social CG. It's good and bad in different ways.

Chris is this deep thinker and I think tried to make sure AP was flexible enough to address future concerns, but is the antithesis of Eugen who forges ahead to scratch itches. @kaniini seems to provide balance.

@msh @jdormit @jalcine @sean And just to piggy back on this comment, if it turns out that what Masto is becoming is not conducive to the changes that need to be made to AP, I will abandon it in a _heartbeat_.

Popularity shouldn't be the defining factor of the what the protocol should be. Stability and security has gotta be at the core of it. That's something I hard agree with @kaniini on

@kaniini People are in part copying what Mastodon does because there's no comprehensible documentation for anything, so the logical next step is to try to understand how the biggest player does it. Real documentation would go a long way to gaining mindshare. @msh @jdormit @Are0h @jalcine @sean

Sign in to participate in the conversation

Hometown is adapted from Mastodon, a decentralized social network with no ads, no corporate surveillance, and ethical design.

<svg xmlns="http://www.w3.org/2000/svg" id="hometownlogo" x="0px" y="0px" viewBox="25 40 50 20" width="100%" height="100%"><g><path d="M55.9,53.9H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,53.9,55.9,53.9z"/><path d="M55.9,58.2H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,58.2,55.9,58.2z"/><path d="M55.9,62.6H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,62.6,55.9,62.6z"/><path d="M64.8,53.9c-0.7,0-1.3,0.6-1.3,1.3v8.8c0,0.7,0.6,1.3,1.3,1.3s1.3-0.6,1.3-1.3v-8.8C66,54.4,65.4,53.9,64.8,53.9z"/><path d="M60.4,53.9c-0.7,0-1.3,0.6-1.3,1.3v8.8c0,0.7,0.6,1.3,1.3,1.3s1.3-0.6,1.3-1.3v-8.8C61.6,54.4,61.1,53.9,60.4,53.9z"/><path d="M63.7,48.3c1.3-0.7,2-2.5,2-5.6c0-3.6-0.9-7.8-3.3-7.8s-3.3,4.2-3.3,7.8c0,3.1,0.7,4.9,2,5.6v2.4c0,0.7,0.6,1.3,1.3,1.3 s1.3-0.6,1.3-1.3V48.3z M62.4,37.8c0.4,0.8,0.8,2.5,0.8,4.9c0,2.5-0.5,3.4-0.8,3.4s-0.8-0.9-0.8-3.4C61.7,40.3,62.1,38.6,62.4,37.8 z"/><path d="M57,42.7c0-0.1-0.1-0.1-0.1-0.2l-3.2-4.1c-0.2-0.3-0.6-0.5-1-0.5h-1.6v-1.9c0-0.7-0.6-1.3-1.3-1.3s-1.3,0.6-1.3,1.3V38 h-3.9h-1.1h-5.2c-0.4,0-0.7,0.2-1,0.5l-3.2,4.1c0,0.1-0.1,0.1-0.1,0.2c0,0-0.1,0.1-0.1,0.1C34,43,34,43.2,34,43.3v7.4 c0,0.7,0.6,1.3,1.3,1.3h5.2h7.4h8c0.7,0,1.3-0.6,1.3-1.3v-7.4c0-0.2,0-0.3-0.1-0.4C57,42.8,57,42.8,57,42.7z M41.7,49.5h-5.2v-4.9 h10.2v4.9H41.7z M48.5,42.1l-1.2-1.6h4.8l1.2,1.6H48.5z M44.1,40.5l1.2,1.6h-7.5l1.2-1.6H44.1z M49.2,44.6h5.5v4.9h-5.5V44.6z"/></g></svg>