Yes, this is what I do, and I also store Like and Announce IDs to process Undo activities. This is not a big deal.
In my view protocol simplicity is more important, and the situation where object can be an ID, or a full Follow activity, or an incomplete copy of it without an ID, is not a good one.
This is a good point. But as far as I know, Accept(Follow) is currently the only real use case for Accept activity. Another use case was suggested in FEP-5264 discussion, and yet another one was proposed in FEP-0837, however these are not widely implemented. Are there other examples?
It seems to me that best practices in this area have not been established yet. Discrimination by shape is not the only solution, and shouldn’t be promoted as such. There are at least two alternatives:
- Discriminate by URL structure. Implementers may use
https://social.example/follow-requests/<id>forFollowactivities andhttps://social.example/offers/<id>forOfferactivities. - Discriminate by additional properties in
Acceptactivity. These properties may depend on the type of the original activity, and we can also define a new generic property such as objectType.
All of them have downsides, but I’m slightly in favor of the latter approach and decided to rely on additional properties in my FEP-0837 implementation where application needs to distinguish between Accept(Offer) and Accept(Follow) activities.