This seems like a lot of Strong Nos.

I'm glad to hear it. I don't think Bluesky, Farcaster, or any other company should convince everyone to use the protocol they control. Their investors have bet that we will.

I like using and contributing to open standards developed in neutral standards bodies like IETF and W3C.

I will not stop saying that open standard protocols are better for the Internet than proprietary ones.

I will, however, continue trying to learn how to say this in ways that are clear and comprehensible to listeners and don't push people away.

I also think it's *great* when companies implement open standards. That puts them on an even playing field with individuals, families, coops, non-profits, universities, governments, and other parts of civil society. I hope the companies named above find better ways to engage with the wider Internet. I'm happy to help them however I can.

Finally, I am sad that the ActivityPub network is still vulnerable to this kind of attack. No one has launched a startup to challenge HTTP lately. I am taking this as a wake up call to help build the infrastructure and resources ActivityPub needs to be equally ubiquitous.

I don't like conversations about comparing protocols on technical grounds. It's not that I think ActivityPub cannot stand up to others -- it's a fantastic, expressive, flexible, secure and extensible protocol -- but I think the framing ignores the governance issues. I do appreciate the challenges, though -- it helps make ActivityPub better.

I think ActivityPub is flexible enough that experimentation can happen in a huge number of ways. Building an extension on top of AP is very straightforward and extensions carefully designed can easily be backwards-compatible. It's simply untrue that anyone needs to start over from scratch with an incompatible base protocol in order to develop interesting new features.

Lastly, I think a lot of the discussion around ActivityPub in some communities is really negative. Instead of celebrating the immense success of the protocol, and its impressive positive characteristics, there's a lot of picking at flaws around the edges. In those communities, people find my enthusiasm about AP irritating. I understand why people might want to talk that way, but I also prefer to talk about why I love it, and how we can make a good thing better.

@evan this isn't a slight against activitypub but i don't think the comparison to http makes sense. partly because activitypub in a sense *is* http, at least in how it's broadly implemented. but it's just one class of http messages. i don't think it makes sense for all web traffic to be in activitypub format.

@trwnh I don't think you understood the example. I tried to rewrite it to make it clearer in which way I am comparing AP to other protocols.

@evan evan, might this be an unfair framing? the activitypub specification has a lot of positives, but the problems are a) not always at the edges, and b) mostly in how popular implementation ("the fediverse") has diverged from the spec, in some places quite significantly, to the point that anyone wanting to implement "activitypub" to the letter of the spec will not be able to talk to anyone on "the fediverse". webfinger and http sigs are one thing, but the core message semantics are another.

@evan the rewording is better, but i still think that "problem space" is not sufficiently defined. you call out "social networking protocol" specifically, but i think part of the problem is that there are people interested in activitypub that aren't as interested in social networks as you are. the relatively poor adoption of C2S as a standard API for managing web resources is either insignificant or very significant, depending on who you ask.

@trwnh I don't think it's an unfair framing, but I'd be happy to read more positive posts about AP from others, if you think I've missed them.

@evan my point was more that “negativity” is not necessarily targeted at AP, but at the architecture and ecosystem of the present fediverse. people expressing their frustrations or criticisms should be seen as an opportunity to improve pain points at a protocol or profile level. one example is possibly spinning up a task force or report to document the lifecycles of resources and objects as they are created and deleted. another example is mapping out required properties and associated behaviors.

@evan basically, people want to see considerations go into one or more formally defined “protocols” that can be signaled or negotiated client-to-client or actor-to-actor. if i want to do a chess extension, i need to know that the other actor can play. if i want to do e2ee messaging, i need my keys negotiated between clients instead of actors. and if i want to make “posts” then i need to agree with other actors what a “post” is.

i’d be happy to bring this up at the cg meeting next week…

@evan at its core, AP lets you do a lot of really cool stuff — practically unbounded! which is both good from the perspective of what it enables you to do and build, but also it’s a lot to take in for any prospective users of AP in building software. i think as long as AP exists in the domain of the W3C, we have a responsibility to pave those paths so that people have an easier time understanding how everything fits together.

@trwnh If you'd like to convince me that your negativity about AP is justified, and my positivity is off-track, we'll just have to agree to disagree.

@evan your positivity is justified, and also i do not intend it in a negative way when i mention criticisms. i am overall positive about AP, and i want to address identified issues as best as possible and as early as possible. if i didn't fundamentally believe in open standards, then i wouldn't bother putting in any of the work, time, or effort that i have in documentation or outreach, and i would quit my roles in various communities and teams. i **really** don't intend any antagonism or slight.

@evan however, i recognize that this branch of conversation may have ceased being productive, so i'll stop here and raise the aforementioned points on the CG meeting agenda instead.