Oddbean new post about login | logout Working hard on a esp32 based hardware nsecbunker. Currently unencrypted comms are supported. Much more needed to make it more friendly: Admin interface Configurator Nip4 support Nip44 support ??? nostr:nevent1qqsd3f7g05m0w8qvep2tmcu6jjq7sy8nv2rms2e33cxr6puhuhnnfggpz9mhxue69uhkummnw3ezuamfdejj7q3qu4ttmenr2uymgpq27c0hyvkkdrdktd6nrjexljzc4rjtr5gk5y6sxpqqqqqqz5wtj3a
nsec bunker is just a signing device, what does that have anything to do with except NIP-01 and everything that comes from that? ie, signing events???? ie the whole thing
Please explain in a non ranty way. Is this even a question? Remember there's a person on the other side of your posts.
a person? do you know what "sign" means? an nsec bunker is a web server that holds your secret key and signs events for you for some reason the nobs in the rockstar brigade, the super sexy 25 year old nostr devs, think that sending your secret key to a foreign web server is a great idea search me how they come up with that idea, seems like a really dumb idea to me if that web server is on my phone or my pc, ok, but come on it's like trusting the worst used car salesman to be your power of attorney
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.
Does this mean we have a hardware wallet for nostr?
looks like it.
Based af
nostr on esp32 was one of the first things that came to mind when I learned about it. Do you think it's a stupid idea to do IoT communications using nostr? Feels like it could be a good way to control your stuff when you're away from home without needing to do cloud polling or opening up your HomeAssistant to the internet.
It works well. Whether it's a good idea or not, I'm not decided yet. The data use something like MQTT is much much higher. I built a proof of concept for Nostrasia that proved it can work.