mleku on Nostr: i had overcomplicated the #realy http router in recent work... latest commit is ...
i had overcomplicated the #realy http router in recent work... latest commit is tagged v1.9.8 and implements the simplest thing, /relayinfo, which is simply just the same as calling / with Accept: application/nostr+json
you have to give the same Accept header as this, but this is going to be required for all the paths associated with the simplified nostr HTTP (and websocket, for subscriptions) protocol
i also retained the existing tagged versions but they are all broken
curdl now does "relayinfo" and i kinda feel like i should not be making so much complication to make it do this thing but then i think meh, this is actually simpler than the complication you will find on v1.9.7 tag so fuck it
the main http server function already filters for the root "/" path and if it sees "application/nostr+json in the Accept it sends nip-11 json
if it sees "/" and "Upgrade" "websocket" it forwards to the standard regarded nostr websocket clown show
if it gets "/" but neither of the above, it just forwards to the unimplemented "relay UI" page which has no content except for basically the nip-11 plus a little "todo" note above it
if the path is not "/" then it goes to the new router, which provides the existing, no-accept header protocol endpoints for export and import, or if the accept header is set to the same as the nip-11 protocol encoder spec, it runs the simplified nostr protocol
which is to be implemented
for today, i just have made it ready for it, everything else is working the same, so v1.9.8 tag is still fine to use for a production realy
not that anyone is using it
i'm honing my API stability promise still, it's not a simple thing, but i feel like i'm at the point with this project where i can now guarantee that it works as a "normal nostr relay" and the "simplified nostr" protocol is now in alpha, as of when i actually start to implement the event, events, filter, and fulltext endpoints (yes i am going to implment a variant of the "search" field that requires at least two filter fields to activate (because it will literally pull those results and then accept or reject if the space separated terms in search are found in the content.
yes, and it doesn't require implementing a full text search index
by requiring at least two filter fields the workload of a search filter is reduced to the level of an average filter search, plus the app can provide an actual competent search
but it will require a small modification of the search form for apps that want to implement it... they will need to decide on two fields that must be present, either a user(s) list and a "since" field or some similar thing like this, i haven't decided, but the point is that we don't have decent search on nostr because nobody thought of making it a subset of a filter, instead it's some hazy foggy notion that nobody has had the balls to define
i'm gonna define it
i think to enable anything less than two of either time bounds, pubkey or tag filter matches with a keyword search is excessive workload, without an index
with an index, it could be ok
so this is also why there is a "/capabilities" endpoint, such things as whether a relay database has a fulltext index can be part of the flags of the endpoint for "/fulltext" and then voila, you can do raw fulltext
if you understand the amount of compute required to do an ad-hoc fulltext search you would understand why it has to have an index, or it can't be so wide open
i want to add a fulltext index, it's just a lot of work to build one, i know in principle how to do it, a table of keywords, with lists of events that have them in it
nobody is paying me to build this, so i'm going to build something that is useful enough that it might even get adopted
you have to give the same Accept header as this, but this is going to be required for all the paths associated with the simplified nostr HTTP (and websocket, for subscriptions) protocol
i also retained the existing tagged versions but they are all broken
curdl now does "relayinfo" and i kinda feel like i should not be making so much complication to make it do this thing but then i think meh, this is actually simpler than the complication you will find on v1.9.7 tag so fuck it
the main http server function already filters for the root "/" path and if it sees "application/nostr+json in the Accept it sends nip-11 json
if it sees "/" and "Upgrade" "websocket" it forwards to the standard regarded nostr websocket clown show
if it gets "/" but neither of the above, it just forwards to the unimplemented "relay UI" page which has no content except for basically the nip-11 plus a little "todo" note above it
if the path is not "/" then it goes to the new router, which provides the existing, no-accept header protocol endpoints for export and import, or if the accept header is set to the same as the nip-11 protocol encoder spec, it runs the simplified nostr protocol
which is to be implemented
for today, i just have made it ready for it, everything else is working the same, so v1.9.8 tag is still fine to use for a production realy
not that anyone is using it
i'm honing my API stability promise still, it's not a simple thing, but i feel like i'm at the point with this project where i can now guarantee that it works as a "normal nostr relay" and the "simplified nostr" protocol is now in alpha, as of when i actually start to implement the event, events, filter, and fulltext endpoints (yes i am going to implment a variant of the "search" field that requires at least two filter fields to activate (because it will literally pull those results and then accept or reject if the space separated terms in search are found in the content.
yes, and it doesn't require implementing a full text search index
by requiring at least two filter fields the workload of a search filter is reduced to the level of an average filter search, plus the app can provide an actual competent search
but it will require a small modification of the search form for apps that want to implement it... they will need to decide on two fields that must be present, either a user(s) list and a "since" field or some similar thing like this, i haven't decided, but the point is that we don't have decent search on nostr because nobody thought of making it a subset of a filter, instead it's some hazy foggy notion that nobody has had the balls to define
i'm gonna define it
i think to enable anything less than two of either time bounds, pubkey or tag filter matches with a keyword search is excessive workload, without an index
with an index, it could be ok
so this is also why there is a "/capabilities" endpoint, such things as whether a relay database has a fulltext index can be part of the flags of the endpoint for "/fulltext" and then voila, you can do raw fulltext
if you understand the amount of compute required to do an ad-hoc fulltext search you would understand why it has to have an index, or it can't be so wide open
i want to add a fulltext index, it's just a lot of work to build one, i know in principle how to do it, a table of keywords, with lists of events that have them in it
nobody is paying me to build this, so i'm going to build something that is useful enough that it might even get adopted