nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqer26g8v2gdquxkyk43usmlk7gaqhle08p378ld3ldfd6p5yrt8us3qs2sp I am not talking about this FEP in particular, but about the general principle. Resolv...
@silverpill @nprofile1q... @nprofile1q... @nprofile1q...
I would rather trade an occasional single indexed DB SELECT query that is also in a RAM cache for a short while (at least in the case of Pleroma) for more validation, than trusting input data from a random server on the Internet not checking it is actually correct. There are other avenues for optimization where it doesn't affect validation. And there are also other avenues where you can completely tank remote instances with DB queries with barely any effort.
Tangentially I'm not a fan of the "be strict in what you create, lenient in what you ingest" paradigm that is promoted on this network. It always leads to implementations doing wonky things that others have to fix up and normalize. This way of indicating what side-effects to use without even bothering to check the referenced Object based on an Activity type kinda promotes that behavior/paradigm.
I would rather trade an occasional single indexed DB SELECT query that is also in a RAM cache for a short while (at least in the case of Pleroma) for more validation, than trusting input data from a random server on the Internet not checking it is actually correct. There are other avenues for optimization where it doesn't affect validation. And there are also other avenues where you can completely tank remote instances with DB queries with barely any effort.
Tangentially I'm not a fan of the "be strict in what you create, lenient in what you ingest" paradigm that is promoted on this network. It always leads to implementations doing wonky things that others have to fix up and normalize. This way of indicating what side-effects to use without even bothering to check the referenced Object based on an Activity type kinda promotes that behavior/paradigm.
1