Building a nostr client on my own after having a shit ton of set back (unnecessary excuses)
God help me
Conflicted on whether to use React or React native to ship this eventually
What say you nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424
You will get the job done with any such framework (if you want to go for the web).
Depends solely on your experience and skills with them.
Receive #emails as DMs sent diectly to your Nostr address.
Send #emails as DMs directly from your Nostr address.
It's that easy
Available on https://nip05.social
Receive #emails as DMs sent diectly to your Nostr address.
Send #emails as DMs directly from your Nostr address.
It's that easy
Available on https://nip05 social
Check out "NIP05.social". It enables email receiving and sending to/from Nostr.
Let me know if you need a promo code for the PRO plan.
Then it really is a slightly different approach as with NIP07, where the get_publik_key totally makes sense.
Thank you for clarifying.
no, the signer's key is only used for commands meant for the signer (i.e. create_account)
I wrote a simplied spec from the one being currently discussed; hopefully that clears it since it doesn't even mention that the signer can have a pubkey of it's own until those commands are introduced
https://gist.github.com/pablof7z/dc5b08c3e39cb73512473a53f5f83b48
Thanks for the link and your patience.
I think I get the current concept. But it still feels odd to me to "use the user's key for communication". Does that not make the method get_public_key obsolete?
I know that is another discussion as the one currently going on.
I am still trying to understand the discussion you have. What I am not understanding is:
Why has the bunker connection token the remote_user_pubkey? I initially thought that the signer side would have its own keys for communication that don't need to be the same than the credentials a client is requesting (e.g. via get_publik_key).
Looking forward to it.
In general, I want to understand the current specification first.
I did a Nip46 remote signer implementation before the "bunker era" which is now broken. I have several ideas for a new thing but find the current spec unclear and ambiguous.
From a client UX perspective, I find anything with manually copying or scanning not acceptable. So, my new remote signer (service) should be able to be integrated into an automated flow.
I see that the nip is currently undergoing some changes:
I have some questions about #nip46:
Is the "connect" method only a message from client to signer?
The section "# Started by the client" says:
"The signer scans the QR code and sends a CONNECT message to the client..."
This indicates that the connect message could also be from signer to client (besides the event examples for signer and client saying something else).
If that is the case, what would be the two connect params (pubkey and secret)? That does not make sense to me?
#asknostr
I think the concept of "layers" has been beaten to death and stretched way too thin, to the point of meaningless.
With that out of the way, random thought:
Most NIPs are not nostr but protocols on top of it (nostr = NIP-01)
NIP-04 (DM/encryption scheme), NIP-44 (DM/encryption scheme, NIP-46 (remote signing), NIP-47 (wallet protocol), NIP-90 (data vending machines), etc. All different protocols built on top of Nostr.
That's why we can end up with competing NIPs implementing the same functionality, and why worse NIPs with more network effects can prevail.
E.g. Should a new client that wants to implement DMs go with NIP-04 or NIP-44?
I agree with nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c that rewriting NIP-46 in a completely incompatible way was the wrong approach and it would have been better as an independent NIP that should have battled it out against NIP-46 in the market, just like NIP-44 is challenging NIP-04.
Seeing (some) NIPs as protocols, and not simply functionalities might be a good heuristic:
NIP-46 is not just "remote signing" it's "remote signing with this particular protocol", if we want to change the approach it makes sense to do it via a different NIP that needs to earn it's own and dethrone the competing protocol that provides the same functionality.
This totally makes sense. I like your approach.
Angular 17 really is fun working with.
Since #email IN and OUT is now available for users on "NIP05.social", I will contact our registered users and inform them about these new features.
I might also spent some time again on
