Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-14 23:35:07)
@silverpill @general @julian @raphael 
>Usually it's an extra database query. With AcceptFeatureRequest, you can apply side effects right away.

If you are receiving Accept for something, there's probably a check somewhere if the Accepted thing exists to you anyway. Not doing so in the context of this FEP would result in adding a possibly non-existent Object to a Collection. If you store AP Activities/Objects as JSON in your DB the type comes for free with the existence check. If your AP data is more normalized, then yes you would have to join tables using indexes, or possibly re-query the DB to include the type.

Reject might need the same checking as Accept or might not depending on the target.
---Reply---
silverpill@silverpill@mitra.social (2026-06-15 02:48:40)
@phnt I am not talking about this FEP in particular, but about the general principle. Resolving an object may be a SELECT query, while the side effect may be an INSERT query. The details don't matter, it's always two different operations because you don't know what side effect will be needed.

In some cases, the first operation can be avoided by giving activities better names (or by using one of the hacks I mentioned in another post).

There is no associated cost. You get a better protocol and more efficient implementations for free.

@julian @raphael