- From: Sarven Capadisli <info@csarven.ca>
- Date: Wed, 3 Jan 2024 11:01:07 +0100
- To: public-swicg@w3.org
On 2024-01-03 08:55, Scott wrote: > If ActivityPub wants to be "the" protocol everyone uses, you have to go > beyond the Mastodon use case. Not all of us are building social media > apps. Some of us are building fediverse-enabled forum software. Some of > us are building a social web. > > When ActivityPub catches up, we will use ActivityPub. Until then, we > will use existing protocols that already work. > > I am a fan of ActivityPub and want it to succeed. But I have projects > that cannot wait for these features to be added to ActivityPub. I'd just like to comment on expectations and design decisions. Extending a specification's capabilities should not be conflated with developing systems that use loosely coupled specifications which evolve independently. Like most specifications, ActivityPub generally describes its functional categories and a classes of products that can be implemented. This tells us that while there are areas where Extensibility can be defined, it also tells us the intended scope of the specification. Hence, ActivityPub doesn't need to encompass everything under the social web sun to work. It needs to do one thing that it is designed to do - which I think it does. Simpler, more concise specifications generally stand a better chance of being implemented and embraced compared to larger, more complicated or meaner ones. It is far easier to manage and evolve the ecosystem by loosely coupling architectural components. I'd argue that ActivityPub itself need not be stretched further to for example also cover Authentication and Authorization, in the same way it doesn't need to further or indefinitely express/model the Data that's transported. In the same way techniques towards Trust and Safety ought to be covered that's compatible with ActivityPub. It is generally more cost effective and healthier to evolve the whole ecosystem by replacing specific solutions when needed instead of replacing the whole thing. Instead of waiting for a specification that may not be covering certain features, it may be more useful to check (or follow up) if it should be in there in the first place, and whether the new needs can be addressed through a separate specification that can work alongside the others. -Sarven https://csarven.ca/#i
Received on Wednesday, 3 January 2024 10:01:16 UTC