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.
See: Server Sent Events (basic spec for streaming messages server to client) and EventStream (JS)
Got my black Premium SeedSigner from nostr:npub1l5pxvjzhw77h86tu0sml2gxg8jpwxch7fsj6d05n7vuqpq75v34syk4q0n, and it is 100% worth it
The buttons are pretty easy to use and are better than the exposed thumbstick, and it’s smaller
Overall, a significant upgrade to the old Open Pill I had from nostr:npub1fft97fnpje9w7rp7apaenjd9wvd23hv2sqexl94ydltlyplgvyaqug6sxp which I had for a very long time
Because any key is bound to leak, with the probability being proportional to how often it is used and the required convenience
It is not. nostr:note17x5gvfkqs4fgw4286pm2zlqw0gmmkc7c2n0mprprrklw0enwucmqmgq3wv
Do you happen to use a network capture tool
“fuck you, no one cares about your use case” most people apparently
do not serve NIP-11 unless it is a perfectly functional relay thank you stupid specs
classic example of how retarded the NIP guardians are:
https://github.com/nostr-protocol/nips/blob/master/11.md
> When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.
shouldn't there be a path qualifier as well? does it mean only for the `/` path or does it blanket cover all possible paths?
i'm writing a router for nostr that also handles websocket upgrades for specific paths
but i think that it's "implied" that they mean the root, or whatever path, that you have set your relay to answer to to listen for websockets
so i think i need to switch on paths first and then protocols
but it's not clear
fortunately almost nobody except nostr.wine uses paths at all anyway (and parameters) so i can pretty much say "nostr+json" is always at "/" so if it's not "nostr+json" then it's not asking for nip-11 info
*sigh*
just saying this because the code in relayer purely switches on the Accept header key being "nostr+json" but it should be switching first on "/" and then "nostr+json"
what this nip needs in that paragraph is "for the nostr websocket path"
Basically all paths you can connect to the relay
They don’t give a shit about Bitcoin it appears like, all it is about is corporate capture of the funding sources (OpenSats), the interactions (Primal, which has already done censorship), the HWWs (Coinkite) and the services they use (things like Fold)
Better codec and bitrate I think
But not by a whole lot
I cannot believe there are real people on Shitter that are excited about being dumping grounds for a VC fund that is actively anti-OSS and against the Bitcoin ethos, by buying shares of a company which is crumbling and scheduled to fail in the next 3-5 years if their enshittification pace continues
https://www.tradingview.com/symbols/NASDAQ-FLD/
can TEN31 let us know when they decide to pump this up before the sale please
doomed to fail
they are already at the late enshittification stage
beyond 256kbps on modern codecs, it cannot be noticed
Noswhere ADP fixes this nostr:note1tvapfg4hak2zpp68949gen6w3mhclvgdwhzrzw4rluvuf09azfnsl58pww
Why legal advice? Cashu is questionable but NWC is not
?width=568Natural selection has worked for a long while
With attack resistant SEs, and high throughput
Not platforms based off of normal processors with no additional security features or extremely weak SEs that do not deserve to be called such
