Avatar
Ademan
2cb30c36438bad4a2a5107bc98f5cebe6a0229b0554d8cfbd1c99aa3cc7ecec1
Neanderthal hacking on Bitcoin stuff. LNHANCE please!
Replying to Avatar Ademan

OK I've created a simple sample page for making NIP-96 uploads the way I am in my larger project. I've also included a variation that generates the Auth header differently (according to NIP-96 where it contradicts NIP-98).

Not sure what I'm doing wrong here...

https://github.com/Ademan/nip96-test

You can run it with

```

npx webpack serve -c webpack.dev.js

```

the "My version" checkbox activates the variant upload, rather than only using stock nostr-tools functions.

nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshszythwden5te0dehhxarj9emkjmn99uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshszymhwden5te0wp6hyurvv4cxzeewv4ej7qgawaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uqzpxvf2qzp87m4dkzr0yfvcv47qucdhcdlc66a9mhht8s52mprn7g9q9v296 any ideas? To the extent I am able as a non-web dev who's very unfamiliar with modern PHP, reviewing the nostr.build source it wasn't obvious to me what is going wrong either.

nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpz9mhxue69uhkummnw3ezuamfdejj7qgnwaehxw309ahkvenrdpskjm3wwp6kytcppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7vf5xqhxvdm69e5k7tcprfmhxue69uhhyetvv9ujumn0wd68ycmgv43kktndv5hszxnhwden5te0dehhxarj9e6xsetnv9kk2cmpwshxjme0qqsgnc2tuj0dqpea4qak0qnee55m5kkcdncqpd4r6xjv8hz25n7aqtq3clwv4 I get approximately the same 400 response with nostrcheck, does anything jump out at you?

I appreciate any help y'all can give, and sorry for the noise. At least, if you're aware of clients that work with your nip96 endpoints specifically, I'd love to see them and compare...

Hodlbod confirmed he's using nip-96 after all, so I can reference his code to figure out what's going wrong on my end. Don't waste your time reading this garbage until I've looked over his code lol

Ah, you're using `file[]` as the form field? I thought I saw something to that effect in the nostr.build source, but afaict that's off spec? nostr-tools uses `file` and that was my reading of the spec as well.

Replying to Avatar Ademan

*possibly* related, although I don't think so:

https://github.com/nostr-protocol/nips/blob/master/96.md says payload should be base64 encoded, but

https://github.com/nostr-protocol/nips/blob/master/98.md says the payload should be hex encoded

This seems to be contradictory?

nostr-tools uses the hex encoding, so if the server is expecting base64 that could be a problem, although like I said, I don't *think* these servers are processing the Auth header at all by the time they send me back a 400.

I'll at least try changing it to a base64 encoded payload hash once I get back from mowing the lawn...

OK I've created a simple sample page for making NIP-96 uploads the way I am in my larger project. I've also included a variation that generates the Auth header differently (according to NIP-96 where it contradicts NIP-98).

Not sure what I'm doing wrong here...

https://github.com/Ademan/nip96-test

You can run it with

```

npx webpack serve -c webpack.dev.js

```

the "My version" checkbox activates the variant upload, rather than only using stock nostr-tools functions.

nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshszythwden5te0dehhxarj9emkjmn99uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshszymhwden5te0wp6hyurvv4cxzeewv4ej7qgawaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uqzpxvf2qzp87m4dkzr0yfvcv47qucdhcdlc66a9mhht8s52mprn7g9q9v296 any ideas? To the extent I am able as a non-web dev who's very unfamiliar with modern PHP, reviewing the nostr.build source it wasn't obvious to me what is going wrong either.

nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpz9mhxue69uhkummnw3ezuamfdejj7qgnwaehxw309ahkvenrdpskjm3wwp6kytcppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7vf5xqhxvdm69e5k7tcprfmhxue69uhhyetvv9ujumn0wd68ycmgv43kktndv5hszxnhwden5te0dehhxarj9e6xsetnv9kk2cmpwshxjme0qqsgnc2tuj0dqpea4qak0qnee55m5kkcdncqpd4r6xjv8hz25n7aqtq3clwv4 I get approximately the same 400 response with nostrcheck, does anything jump out at you?

I appreciate any help y'all can give, and sorry for the noise. At least, if you're aware of clients that work with your nip96 endpoints specifically, I'd love to see them and compare...

What do/should be done when you have p2pks very near to expiring? It seems like you just end up reverting to the "worst case" of the recipient needing to immediately redeem tokens and/or senders needing to redeem them into new p2pks them before sending, which ends up putting load on the mint.

I suppose if users had the timelocks semi-randomly distributed, then only a subset of tokens would need to be urgently redeemed?

This is something I was thinking about the other day when you talked about million TPS. Presumably, an end user won't want to lock a bunch of funds to a service provider with no option to reclaim unused ones.

Do you have thoughts on that? I suppose a timelocked alternate spending path would work, but that becomes troublesome if you have a bunch of timelocked tokens on the verge of expiration, too.

Replying to Avatar Ademan

#nostrdev #asknostr #nostr-tools

I'm unable to complete nip96 uploads across nostrcheck, nostr.build, and files.v0l.io I suspect it's my fault somehow, but I'm burning more time than I'd like troubleshooting. I'm using nostr-tools and afaict based on reading nip-96, examining the nostr-tools code, and looking at the requests, I'm not certain what's wrong here.

Afaict the Authorization form field is non-standard but harmless (hacking it out did not change the responses I'm getting, and reading the void-cat-rs source it looks like it should be ignored anyway).

```

POST /n96 HTTP/2

Host: files.v0l.io

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate, br, zstd

Referer: http://localhost:5000/

Authorization: Nostr REDACTED

Content-Type: multipart/form-data

Content-Length: 24052

Origin: http://localhost:5000

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: cross-site

Priority: u=4

TE: trailers

-----------------------------11234029581503681683701650224

Content-Disposition: form-data; name="Authorization"

Nostr REDACTED

-----------------------------11234029581503681683701650224

Content-Disposition: form-data; name="size"

22933

-----------------------------11234029581503681683701650224

Content-Disposition: form-data; name="file"; filename="2024-07-06-152337_1000x175_scrot.png"

Content-Type: image/png

... snip ...

-----------------------------11234029581503681683701650224--

```

You can see from the size field that the file is quite small.

I get a 400 response from all three services. (Not a 401 or 403 or anything) I'm pretty sure I'm generating the authorization token correctly (also using nostr-tools) and I glanced at the nostr.build source code and I'm reasonably confident the response I'm getting back is generated before the auth header is checked.

Both nostr.build and nostrcheck have some kind of message indicating a problem with the file upload portion. (files.v0l.io gives me a generic 400 html response)

nostr.build example

```

'{"status":"error","message":"Either no file or more than one file posted. Only one file is expected."}'

```

I'm not a web guy so nothing is jumping out at me, but does anyone notice something obviously wrong with the request?

*possibly* related, although I don't think so:

https://github.com/nostr-protocol/nips/blob/master/96.md says payload should be base64 encoded, but

https://github.com/nostr-protocol/nips/blob/master/98.md says the payload should be hex encoded

This seems to be contradictory?

nostr-tools uses the hex encoding, so if the server is expecting base64 that could be a problem, although like I said, I don't *think* these servers are processing the Auth header at all by the time they send me back a 400.

I'll at least try changing it to a base64 encoded payload hash once I get back from mowing the lawn...

#nostrdev #asknostr #nostr-tools

I'm unable to complete nip96 uploads across nostrcheck, nostr.build, and files.v0l.io I suspect it's my fault somehow, but I'm burning more time than I'd like troubleshooting. I'm using nostr-tools and afaict based on reading nip-96, examining the nostr-tools code, and looking at the requests, I'm not certain what's wrong here.

Afaict the Authorization form field is non-standard but harmless (hacking it out did not change the responses I'm getting, and reading the void-cat-rs source it looks like it should be ignored anyway).

```

POST /n96 HTTP/2

Host: files.v0l.io

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate, br, zstd

Referer: http://localhost:5000/

Authorization: Nostr REDACTED

Content-Type: multipart/form-data

Content-Length: 24052

Origin: http://localhost:5000

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: cross-site

Priority: u=4

TE: trailers

-----------------------------11234029581503681683701650224

Content-Disposition: form-data; name="Authorization"

Nostr REDACTED

-----------------------------11234029581503681683701650224

Content-Disposition: form-data; name="size"

22933

-----------------------------11234029581503681683701650224

Content-Disposition: form-data; name="file"; filename="2024-07-06-152337_1000x175_scrot.png"

Content-Type: image/png

... snip ...

-----------------------------11234029581503681683701650224--

```

You can see from the size field that the file is quite small.

I get a 400 response from all three services. (Not a 401 or 403 or anything) I'm pretty sure I'm generating the authorization token correctly (also using nostr-tools) and I glanced at the nostr.build source code and I'm reasonably confident the response I'm getting back is generated before the auth header is checked.

Both nostr.build and nostrcheck have some kind of message indicating a problem with the file upload portion. (files.v0l.io gives me a generic 400 html response)

nostr.build example

```

'{"status":"error","message":"Either no file or more than one file posted. Only one file is expected."}'

```

I'm not a web guy so nothing is jumping out at me, but does anyone notice something obviously wrong with the request?

This is indeed an alt I just created. Since I don't want to copy keys across multiple devices. I think whatever nsecbunker does would allow me to post from other devices but sign from my desktop? Anyway I haven't looked into it enough to understand, and this works well enough for the moment.

What is the currently recommended RAM for a bitcoind node, both for initial block download and steady state? I'll be using -txindex and making infrequent RPC calls, if that affects it significantly.

I'm provisioning a VM on a home server for a new node, so I can always adjust later if need be.

#bitcoin #asknostr

#asknostr #nostrdev

does anyone successfully use the nostr.build nip96 endpoint?

Have you considered any kind of affiliate program for authors of clients if their users sign up for your paid services? I'm sure every nostr dev out there is sitting there scratching their head going "how the heck do I monetize this?" and maybe that's an interesting option.

(Not applicable to my situation, of course, but for people who are building *serious* clients lol)

nostr:nprofile1qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3xamnwvaz7tmsw4e8qmr9wpskwtn9wvhszxnhwden5te0vfhhxarj9ekx2cm5w4exjene9ehx2ap0qywhwumn8ghj7mn0wd68ytndw46xjmnewaskcmr9wshxxmmd9uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qpqnxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzs6u7hl4 I'm working on a for-funsies nostr client that I'll probably abandon fairly quickly and I'd like to integrate nostr.build

If I actually release it, it'll be FOSS and free to use, but the nostr.build github made it sound like I should contact y'all before integrating it.

Happy to provide more details and/or a preview release if you want. (Give me some time to do some cleanup first in the latter case heh) Like I said in all likelihood I'm going to abandon this pretty quick anyway, but I want to be a good steward.

I'm actually more interested in public groups too.

My question is just: Do you really need a NIP-29-aware relay at all, for public groups?

Replying to Avatar Vitor Pamplona

If you are using the following relays, beware that many clients will not connect, upload or download data from them. Amethyst Push Notifications will also not connect to them.

- wss://relay.orangepill.dev certificate has expired

- wss://ca.relayable.org certificate has expired

- wss://nostr.btcmp.com certificate has expired

- wss://nostr.delo.software certificate has expired

- wss://nostr.drss.io Hostname/IP does not match certificate's altnames: Host: nostr.drss.io. is not in the cert's altnames: DNS:nostr.io, DNS:www.nostr.io

- wss://nostr.libreleaf.com certificate has expired

- wss://nostr.mikedilger.com Hostname/IP does not match certificate's altnames: Host: nostr.mikedilger.com. is not in the cert's altnames: DNS:chorus.mikedilger.com

- wss://nostr.onsats.org Hostname/IP does not match certificate's altnames: Host: nostr.onsats.org. is not in the cert's altnames: DNS:onsats.org

- wss://nostr.openordex.org certificate has expired

- wss://nostr.orangepill.dev certificate has expired

- wss://nostr.plebchain.org certificate has expired

- wss://nostr.unknown.place self-signed certificate

- wss://nostr.walletofsatoshi.com certificate has expired

- wss://nostr.zaprite.io Hostname/IP does not match certificate's altnames: Host: nostr.zaprite.io. is not in the cert's altnames: DNS:examplewalk.com, DNS:www.examplewalk.com

- wss://nostr.zebedee.cloud Hostname/IP does not match certificate's altnames: Host: nostr.zebedee.cloud. is not in the cert's altnames: DNS:names-hub.com, DNS:www.names-hub.com

- wss://private.red.gn.net certificate has expired

- wss://relay.nostr.ro certificate has expired

- wss://relay.orangepill.dev certificate has expired

- wss://relayable.org certificate has expired

An automated service that polls known relays periodically and logs some stats (age of the last N notes to estimate usage), logs unusable relays, and has a simple web frontend would be nice. Any additional diagnostics are a bonus but I'm sure people could come up with a bevy of them.

Hey nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcprpmhxue69uhhyetvv9ujucm4wfex2mn59en8j6f0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3kamnwvaz7tmwdaehgu3wdaexzmn8v4cxjmrv9ejx2a30qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp0qqs2rlzal4lleatrezg4tdrxw5d4srg3tcfkutuvjr5fzvu9h0kmrncdcqmdu do you have any experience with https://en.wikipedia.org/wiki/Tithonia_diversifolia ? I'm trying to find a perennial to build a privacy barrier, and also to generate compost. (The flowers are a bonus as pollinator attraction)

The problem is, I'm in Zone 8a like you, where Tithonia supposedly will die off completely in hard freezes.

I was also interested in pigeon pea, since that can even be for human consumption, but the hard freeze is a problem with them too.