Goofed Home

@smallcircles @julian I think we might have different ideas about what the ActivityPub API task force is for.

To me, it's about making it possible for clients to use different servers, and different implementations of the API. That's going to include the social API defined in the ActivityPub standard, but it will also encompass things like rate limits, authentication, caching, CORS, and so on.

How that all gets documented will probably be in one or more community group reports.

@evan @julian

The extent to which the default profile becomes a 'straightjacket' impact scope, applicability, and usability. I guess its alright as long as there's sufficient flexibility and extensibility taken into account. Guess the "sufficient" does the heavy lifting here.

@smallcircles @julian I think that's always a tension in standards! How do you make it explicit enough that developers can build interoperable software, but extensible enough that they can try new things?

I think one pattern that works well is some base-level standards assumed, and easy ways for extensions to be discoverable and negotiable. If your preferred extension isn't available from the software on the other side of the line, you fall back to the base-level standard.

@evan

> Rate limits are a common part of APIs.

Yes, of API *implementations*, and they may become part of the public interface of these implementation. Whether they should be part of an open standard protocol specification is a different matter imho. Perhaps in a separate implementation guide, suggesting recommended practices.

Or perhaps there may be some way to formulate a generic mechanism in the protocol specification that makes rate limits an extension point, without pinning to a particular method, esp. if it is only a de facto standard.

(Other example. The fediverse is still pinned to an expired draft of HTTP signatures.)

OTOH if the goal of the task force is to mostly just provide implementation guidance, and maybe a reference impl, then I guess examples of rate limiting may be provided.

@julian

@smallcircles @julian the point of the API task force is to make using the API across servers possible. That's why we're doing the OAuth work. I think rate limiting is part of the basic profile; it's one of the things you need to support to use the API across different servers.

@julian There are 3 main clusters.

They're linked here for the ActivityPub API task force, but they also apply for the federation protocol:

https://github.com/swicg/activitypub-api/issues/4#issuecomment-4083573914

@julian @benpate

> who says fediverse accounts need to be people?

Certainly not me. I'm thinking on an actor-based service-oriented fedi, which more closely represents actor model. Where the social network is a pure social graph of addressible actors, that can be introspected for the services they provide.

Yes, a book might be an actor, as well as the shelf :)

@julian @evan

Well.. atm all options have 25% of the vote 😅

@smallcircles @julian

https://evanp.me/pollfaq#itdepends