Piero Bosio Social Web Site Personale

@deadsuperhero@social.wedistribute.org thanks for posting.

I think what makes it hard for existing implementations to support it is that if you're not AS-native (that is, consuming ActivityStreams activities directly without converting to some normalized form for your software), then it's possibly a big lift to "level up" your code to do it that way.

Like Mastodon, NodeBB ingests the activity, extracts the juicy bits, and discards the rest. It makes it hard to later on recall an activity because they were ephemeral (at least in our chain of custody).

So an entire new middleware layer needs to be built for NodeBB to catalog and store (and later, recall) these activities for ActivityPub API support.

Correct me if I'm wrong @evan@cosocial.ca!

Finally, I think there are some serious improvements we can bring to fill the gaps that the current spec is missing. What if we had a standard endpoint for notifications?

Suppose we also developed a standard way of doing timelines as well, and used it as a springboard for custom feeds that could work with any app, any client, and any server?

There's a lot of useful stuff we could do here to make the whole thing extremely compelling for anyone building on this network.

Why do I care so much about this? A few reasons.

One, I don't want to have a dozen different accounts across separate types of applications on the same network. I really hate that, it's messy and does nothing to unify my identity across all the spaces I'm active on.

Two, a seamless login across the entire network could be very powerful for discovery. Instead of having to find people to follow on Pixelfed and PeerTube, the folks I'm already connected to would already be there, right when I sign in.

Three, we could develop a new generation of rich clients that all do really different things, but all tie back to a singular identity. "Sign In With ActivityPub" could work for the entire network, and it wouldn't have to be a hack using Mastodon's API.

Bluesky absolutely got it right with ATproto: you can make any kind of client, not just microblogging, and it will seamlessly work with your Bluesky identity. Everything you post goes into your personal storage, and the clients that know how to interpret special data types are able to reach into your PDS and the timelines you're following to present that stuff.

ActivityPub API needs to follow a similar story.

Here's the thing: Mastodon already has a really good API. There's a whole ecosystem of clients around it, to the point that many other Fediverse implementations adopted it, so that they can use the apps.

I don't think this is a bad thing in and of itself. But, if we want projects like Mastodon to support it, the value proposition has to provide things that the Mastodon API does not.

I think a killer feature to focus on would be identity management.

I think the #ActivityPub client-to-server API is extremely important and underrated. I'm glad to see the SWF and W3C group prioritizing it, because I think it has the potential to fix something that's kind of broken on the #Fediverse: too many accounts, on too many platforms that really ought to be clients.

Here's the rub, though: you need the big players in the space to support it. Mastodon needs to support it. Pixelfed and PeerTube need to support it.

So, how do you get the big existing projects to all implement it? How do you justify it?

Well that was fun, can't believe Pixelfed has over 1M people in our community!

Looking forward to building bridges for the next million or two people to join the #fediverse

We have some important work to do this year!

Nobody speaks for "The Fediverse."

I keep seeing posts declaring what The Fediverse believes, wants, or demands, often with ALL CAPS and a wall of #hashtags. It often slides into outright gatekeeping.

The fediverse is decentralized by design. Its opinions are too.

#Fediverse