yep! this is the right move for these obfuscated pubkey type services.
Okay, added it. nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h That should override the whitelist controls, right nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h ?
Discussion
Thanks 🫂
It turns out that Amber wasn't as hard to implement, as I'd thought. The relay was just unreliable.
nice, i saw nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz9mhxue69uhkummnw3ezumrpdejz772u5wm gave you a code snippit a few days back, do you think this info is easy enough to find on the amber github? if not, maybe you could do us future implementoors a favor and PR it for them?
Beyond Amber-specific code snippets, NIP-46 (https://github.com/nostr-protocol/nips/blob/master/46.md#direct-connection-initiated-by-the-client ) itself needs some love.
For example, while implementing the Direct connection initiated by the client flow, the NIP states:
1. That a secret value must be provided to avoid connection spoofing, and that clients must validate the secret returned in the connect response.
2. That the connect command should return either "ack" or `
So I knew I needed to return the secret in the response… Still, I had no idea that most clients expect a response containing exactly:
```
{
"id": [secret],
"result": "ack"
}
```
I had to reverse engineer this from client libraries. It would be nice to clarify this kind of thing in the NIP itself.