Re: The "Social Web" vs the "Fediverse"

That is true. ActivityPub does not need to be the only protocol out there.

For example, in Hubzilla, we use Zot, OpenWebAuth, and ActivityPub. If 
we need advanced privacy features and nomadic identity, we use Zot. If 
we want federated single sign on, we use OpenWebAuth. If we want to talk 
to decentralized social media apps, we use ActivityPub. All three 
protocols can be used in the same project without conflict. ActivityPub 
users get a degraded user experience, but we can work with that.

If ActivityPub wants to remain a social media protocol, then I am fine 
with that. We still have Zot and OpenWebAuth protocols for the social web.

Scott M. Stolz


On 1/3/2024 4:01 AM, Sarven Capadisli wrote:
> 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
>