i haven't quite got to the point of lining up a fully modular modality for the http api, currently it's still a monolith, but maybe i will have to change that later

oh yeah, i can actually already do granular disabling of http api methods though because the huma REST library i'm using uses a registration system and simply by disabling the compilation of a source file containing a method bam it's gone, i just haven't yet added features that may be better to be made modular

also, once i'm done with cleaning up and isolating the publisher unit inside the different types of API i'm looking at building a ful text search index using inverted indexes, that is an example of an api that i might want to make modular, though to achieve that i have to go through the damn event store and make it modular as well, and have it register things maybe... there is a method used in relayer, which i forked from, where if the implementation of an optional method is masked out by build tags and i write the code so it checks if the implementation is present and doesn't find it, it can then report that, and that also applies to the api parts of the relay information document, as they check for this

i actually removed the count method, already, because no client uses it and it doesn't really work to save anyone except maybe some bandwidth, the queries cost as much as if they were to be delivered anyway - and this is why i made the filter api endpoint for http, it only returns event IDs, sorted as per request and can filter pubkeys from the results as well, it was very simple, just a new index that contains pubkeys, datestamp and event id's, so finding them it just locates the event's record key and then it can go straight to this and get the event IDs and filter them