@
@Voted "No, but.." against backdrop of #ActivityPub API task force, where issue tracker has an issue on rate limits.
From perspective of "avoiding misconceptions" I was wondering about a range of issues that have been created, and how they relate to Protocol versus Solution design. See also: https://github.com/swicg/activitypub-api/issues/63
I think it may be valuable to define different stakeholder roles, to track people's needs. For #Protosocial thus far I discern in order of importance:
1. Solution developer
2. Protosocial implementer
3. Protocol designer
When asking the question "Should rate limits be part of the protocol?", starting point for design is a firm No.
Solution devs should not be worried about them. Need for rate limits depends on requirements of individual Protosocial impls, and what their goals are.
Protocol-level there's actor introspection. There are no "instances" but Application actors that host Services, including system services, that may expose Rate Limit as metadata.