finally got around to finishing more of the HTTP nostr protocol implementation

i've already tested one method, which is for submitting events... and had used it, but then i was looking at it and realised that http methods should return http error status codes

so i went through and replaced all the ok,false etc envelopes with standard http messages, mainly "NotAcceptable" for cases like trying to delete other users events (need to make an exception for users authed as admins, or maybe just put it inside the main admin interface, just haven't got to that yet) and "InternalServerError" ie 500, which is what it returns if the database fetch fails for whatever reason, errors that likely don't happen very often

i forgot how laboriously complicated the delete event processing was, also, omg... and yeah, that's another reason why i'm probably not going to do anything about enabling admin delete outside of the admin endpoints, it's just for normal users this code, it's basically the same as the EVENT envelope flow but translated into HTTP

i still have to write the actual simple fetch events by id /events in the database, i've sketched it out on the http handler but the database side isn't done yet, but i'm feeling a bit wired this evening and i'm gonna just get me some sleep, it's my bedtime, sun goes down, my brain turns off

tomorrow morning it's fiat mining again for another 5 hours first, and then i can return to the nostr http and implement the simple fetch protocol and probably i may actually have the /filter endpoint, which is the same as a nip-01 filter except without the "ids" field or "search" field

the actual "search" field i'm just gonna put a "NotImplemented" stub in there for now because it requires a separate index to be created, though i can probably make a special case of filter processing but where it requires at least a pubkey, a tag, and since/until boundaries that don't exceed - let's say, a month, because it can then pull those in a standard filter and then include everything that matches one of the keywords on the content field, and basta, full text search without full text index... nah, seriously, i'm not going to do that, too fuzzy to define sufficiently tight requirements for doing an exhausting scan of content fields, so it will stay that way until i do implement a fulltext search

and i will, just not now, it's important for a document repository use case and that's a key target for the #realy in the long term, in association with the #alexandria project

the tricky thing is that i have to implement that index manually, and that requires an index entry for every full word found, and then a second indexing pass to find mashed together words, and then parsing for whether it's case sensitive or not (probably can just have it not, but then check the content match if i want it to be case sensitive) hah... yeah, actually, it's a complicated task, probably a couple weeks work for me to build a full text index

anyway, getting off track, with fetch by id /events and /event for submitting events and /filter for searching events, you have your basic CRUD (when you include delete event processing, which i have) and that will be MVP

second target after that is to add a socket-using /subscribe endpoint that does filter matches on only newly arived events, and a /relay method which ignores the nip-01 idea of kinds indicating an event is ephemeral so the user can dictate that the relay is not to store the event even if it is storable, why? you ask - i'm glad you asked, because i intend to later on revise the event encoding and request encoding scheme to plain text with line separations and other common conventions, and event kinds as path matching like note and note/html and note/markdown and note/asciidoc just as an example of this, so you could search for any kind of note or you can search for specific formatted ones instead, and in this future scheme, there will not be a notion of "ephemeral" or "replaceable" or "parameterized replaceable" events, instead there will just be /relay /replace and parameterized replaceables are just a client side semantics, instead of some nebulous vague nonsense like what plagues the whole nostr protocol specification from top to bottom

anyway, that's my debrief for my day's work today, it was a good day, i've mostly got a matching matrix table implemented for that now, and will be actually building a mock and having it populate the matrix table and then perform a bunch of queries... which then leads to making a specific query API for the recommender which must also store history of recommendations so it doesn't repeat itself

#gn