I love #activitypub but seeing how slow its development is compared to #atproto makes it hard to be excited about it.
-
I love #activitypub but seeing how slow its development is compared to #atproto makes it hard to be excited about it. This goes for both protocol development and ecosystem development.
ATproto has many cool projects popping up every month, the vision is clear and platforms integrate with each other.
I don't see this excitement and work on the ActivityPub side
-
I love #activitypub but seeing how slow its development is compared to #atproto makes it hard to be excited about it. This goes for both protocol development and ecosystem development.
ATproto has many cool projects popping up every month, the vision is clear and platforms integrate with each other.
I don't see this excitement and work on the ActivityPub side
Is it because of money? Perhaps. #bluesky having money helps a ton for sure, but there is a big amount of work done from other unpaid folks as well. Idk the attitude just seems way different.
-
I love #activitypub but seeing how slow its development is compared to #atproto makes it hard to be excited about it. This goes for both protocol development and ecosystem development.
ATproto has many cool projects popping up every month, the vision is clear and platforms integrate with each other.
I don't see this excitement and work on the ActivityPub side
@res260 I think part of that is the API.
In our ecosystem, we've normalized that you have to build the whole server side, with data storage and network interoperability and so on, for every single new kind of app.
It'd be great if you could use a standard API to make cool apps, and leave all the plumbing to a general-purpose server.
That's what we're doing in the ActivityPub API task force at w3c.
-
@res260 I think part of that is the API.
In our ecosystem, we've normalized that you have to build the whole server side, with data storage and network interoperability and so on, for every single new kind of app.
It'd be great if you could use a standard API to make cool apps, and leave all the plumbing to a general-purpose server.
That's what we're doing in the ActivityPub API task force at w3c.
@evan That would make sense. For ATProto, not being required to think about the PDS and the relays implementations must help a ton to get projects off the ground quickly. Hope the Social API changes that
-
@evan That would make sense. For ATProto, not being required to think about the PDS and the relays implementations must help a ton to get projects off the ground quickly. Hope the Social API changes that
@res260 you and me both!
-
R AodeRelay shared this topic
-
@res260 I think part of that is the API.
In our ecosystem, we've normalized that you have to build the whole server side, with data storage and network interoperability and so on, for every single new kind of app.
It'd be great if you could use a standard API to make cool apps, and leave all the plumbing to a general-purpose server.
That's what we're doing in the ActivityPub API task force at w3c.
@evan@cosocial.ca 100% agreed on the heavy(-ier) lift that is AP development.
However that's how standalone apps have always been developed, and there is a reason why.
When you rely on someone else's tech, then when they sunset the tech or it otherwise becomes unfavourable, you're fucked (pardon my french)
I've seen entire businesses jump head first into building "Facebook apps" after Farmville exploded. None of them are around now and Zynga is currently worth $8 on the NASDAQ.
-
