-
@ mleku
2025-02-15 16:06:58
https://i.imgflip.com/9kc9qf.jpg
currently have, theoretically, working nip-98 http auth working now, works in test, so if it encodes, transmits and decodes same as the http request struct does, then, it will work
i had disabled the utility of the http-basic auth for admin ports and simply hadn't used them for anything since i broke it so, sorry if you were inconvenienced but i think that it is convenient that there seems to be nobody using it at this point because this is gonnna be yuge
so, firstly, we have an auth scheme that works over http
i can now just jump in and implement a break-up of the main nip-01 and search nip filter structure into three separate APIs:
- fetch events by ID: this is a http request at a given endpoint containing an array of event IDs, and the response is to return all of those available in their wire encoding as JSONL format
- filter events: this is the pubkey/timestamp/tags search in the nip-01, but with a twist - it only returns an array of the events that match the filter, the client must then call the previous method to get the whole events, this enables them to paginate them by simple count
- fulltext search - i haven't made a fulltext search index so i'm not going to include this feature now, but it's there in theory. it is basicaly a filter events search with one extra field of space separated terms that are matched and events with more of the terms found in the text are returned at the front of the results and it uses AND against the filter match so it should be implemented as filter first, then wordsearch... and this also means the fulltext search could actually be naively implemented right away but i think it's too expensive for memory usage without an actual word index
after these three (really two, icbf doing fulltext search at this point, i could conceive of it but i just want something simple that you can literally query with json and over http, very amenable to doing with curl) then there is the idea of a "subscribe" endpoint which upgrades to websocket if the user is authorised to make this query and then spits back matching event IDs as they are received (subscriptions)
these three (four) API methods will be an effective replacement for all existing nostr client implementations and will allow them to do the auth ath the http level and not deal with it at application level, and the majority of requests will just be filters and event retrieval requests, which means that an app can even do this without being able to handle sockets
most nostr kind 1 twitter clones could then slash most of their source code and just be written as standard http microservice type queries