Nostr Web Client

We have an AUTH mirror for every non-auth relay, running on NFDB.

TheForest accepts social notes, yes. It accepts almost anything, but only for community members. TheCitadel accepts from anyone, but only certain types.

Anthony Accioly 6mo ago

Got it, makes sense. I had both relays mixed up. The NFDB mirrors are a good idea... Then it becomes Semisol’s problem, and I’m sure he’s dealt with every category of Nostr attack at least twenty times.

Unfortunately, there’s not much we can do about NIP-46 libraries that won’t use AUTH.

Assuming this can be made to work on Nostr1, maybe it’s worth considering whitelisting kind: 24133 without SATS and AUTH on TheForest as well? I have nothing against TheCitadel by any means, but since I’m already using TheForest as a write relay, it would be convenient to use it for NIP-46 too.

If this doesn’t bring too much additional inconvenience (though I’m aware anything public on Nostr comes with some pain), it’d be brilliant for sure.

Reply to this note

Please Login to reply.

Discussion

Silberengel 6mo ago

Okay, added it. nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h That should override the whitelist controls, right nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h ?

Anthony Accioly 6mo ago

Tausend Dank!

Anthony Accioly 6mo ago

On Amber I'm getting "Paid relays are not support message. nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz9mhxue69uhkummnw3ezumrpdejz772u5wm, I assume this will fix it once released? https://github.com/greenart7c3/Amber/commit/8c25535aea8898a61064638a77ba07a0a8dd61f6

greenart7c3 6mo ago

Yes, in the next release it wont show this message

Anthony Accioly 6mo ago

Working well! Just tested with my bastaderised version of nak + Jumble, noStrudel, Amethyst and Nosotros, both bunker and nostrconnect tokens working well over TheForest. I've also tested it with both a npub that is whitelisted and an external one.

I've rebased the PR above on top of Fiatjaf latest changes to nak if anyone else wants it. Thanks a million again!

cloud fodder 6mo ago

yep! this is the right move for these obfuscated pubkey type services.

Silberengel 6mo ago

Thanks 🫂

It turns out that Amber wasn't as hard to implement, as I'd thought. The relay was just unreliable.

cloud fodder 6mo ago

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?

Anthony Accioly 6mo ago

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 `` (emphasis on "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.

Silberengel 6mo ago

Good luck with changing a NIP. 😂

Anthony Accioly 6mo ago

Ah, I have enough side quests, lol. Just trying to rage bait someone else to do this.