Oddbean new post about login | logout Nsec.app doesn't work like this. Nsecbunker.com does but you can run your own on docker very easily. I'm working on a hardware nsecbunker that stores your sk on the device and signs events when requested. That is all.
oh yeah, and what kind of tunnel are you using, are you trying to patronise me? you think i'm so dumb i don't know how to already run my own relay on my own machine right now because oh yeah, i'm building one! that throws up an auth envelope if configured to do so, the moment the websocket opens so, please, what tunnel, or get the fuck out
Why would you need a tunnel? There's no direct communication from client to bunker it's communication via relays. Read the spec and please stop being so rude.
Have you read the specification yet?
Nip46 signer (which is what nsecbunker is) does not need a tunnel. it does not need a public IP, does not need a reverse proxy. Nip46 client sends requests to some public relay, and signer reads those events from public relay, signs, and sends replies to the same relay, which client reads. Nsec.app runs this nip46 signer in your browser service worker.
so the relay acts as a tunnel, and how many relays support this?
IMO a simpler flow literally would be a wireguard tunnel on an internet routable IP address, far far far simpler
Any relay that supports ephemeral events.
no, they have to do the forwarding, that's why i'm like "duh needs a tunnel" ... or a proxy i this case i assure you, khatru does not have this facility
No, they don't have to do any special forwarding - peers just use REQ to subscribe to the requests/replies they need. Nip46 describes it pretty well.
well, i don't think it really solves any problem tbh yes i read through the NIP and it's overly complicated considering it's just a proxy protocol i remember actually suggesting the idea not long ago that NIP-42 auth should use encryption known only to the recipient and vice versa, which would enable proxying the signatures, and then i read today, i mean, i can't spend all my time reading all these things - that the content of NIP-46 messages are NIP-4 encrypted messages. well, duh, but funny in a way as well i think nostr suffers from too many elements where two or more domains are jammed together into one protocol, tags on events, for example, and how many other NIPs involve using NIP-4, which is supposedly deprecated? for which use? DMs only, but NIP-46 apparently not typical beginner architectural mistakes, mixing up features into one section and then when it turns out that is inconvenient, no way to separate them, and/or nobody adopts the isolated version because integrated version exists, which should never have been there in the first place
Wut? You REQ in one side You EVENT on the other side 😂
ephemeral events that have to be held for an indeterminate amount of time is not in the definition of ephemeral
anyhow, i haven't read the nip that close, but i just wonder why so much more energy goes to it than NIP-42 which actually solves an immediate problem for relays, i think we should have both working, for sure, but i don't know whether this is overly complicated because i had to scroll through three screenfuls of text which seems like a lot of stuff for a simple proxy process
and upon a reread, it really does jam way too many things together i don't think that bitcoin would have ever been built without none of this, it's only been the post-established-working-protocol that this has been adopted this specification process should be a wiki you know, like that thing you been working on @PABLOF7z
if you think nip 42 needs more energy, then contribute to it. it's not up to you to decide who works on what.
do you feel dumber after this interaction Pablo? i did.