an example of the retardation of typical nostr clients and auth

#jumble is fine to cope with my #realy when it's set to "public readable" with "restricted-writes" (ie auth to publish)

the relay doesn't demand auth to do req, it has "restricted-writes" in the nip-11, and if you try to send "EVENT" envelope to it, it answers back with "OK",false,"auth-required" and it duly auths and then realy accepts the submission and voila

#coracle is also fine with this

#nostrudel is not

it reads ok, but it craps itself when i try to publish

cc: nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z

this is why there needs to be a fix not just for auth handling in general (they should just all use nip-98) but also there needs to be a proper delineation of API methods being called in "envelopes" because they are ambiguous as fuck, there is really three different semantics to a REQ, a filter, an event retrieval request, and a fulltext (and filter) search

none of the clients even grok the semantics of full text searches at all, but i have figured out that so long as the filter part is reasonably restrictive, ie, it has either authors, a since/until, or some tags, ideally at least two of the above, you can actually implement a "search" just by scraping through the results with a "contains" search on the content fields on each of the space separated string values, and only return the ones that have at least one word match (they could be "relevance" sorted as well so the more words the earlier they appear in the list.

with no need for a stupid fulltext index.

anyway, that's part of what i'm doing with teh simplified nostr HTTP API

i should also mention that it is actually possible to do subscriptions with plain HTTP, just, not simple, because usually servers and clients get cranky about not getting a "Content-Length" header field for the body.