@julian@activitypub.space @general@activitypub.space @evan@cosocial.ca Again, this is sort of why I'm advocating for supporting timelines as a concept in the ActivityPub API. Instead of repeatedly parsing the inbox, we could do exactly what you're saying with some kind of representation of a timeline. Even if it's just plain old algorithmic time-sort.
deadsuperhero@social.wedistribute.org
Posts
-
I think the #ActivityPub client-to-server API is extremely important and underrated. -
I think the #ActivityPub client-to-server API is extremely important and underrated.@evan@cosocial.ca Yeah, I mostly agree with this. It's just that the buy-in is a little bit of a chicken and egg problem. You need servers to adopt it, but you need a compelling first mover. Bonfire, maybe?
The spec definitely needs love, too. I think one of the harder things is building a timeline out of inbox activities. I feel like maybe a future version of the API could specify timelines somehow, whether it's an endpoint or some kind of basic query? Maybe there's even a way to implement alternative timelines at that level?
These are all just guesses on my part, but I feel like this could be a gateway to universal custom feeds.
-
I think the #ActivityPub client-to-server API is extremely important and underrated.Would love to hear what @evan@cosocial.ca thinks about this.
-
I think the #ActivityPub client-to-server API is extremely important and underrated.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?