Nostr for Normies:
The status quo of most of the internet is that of full-custody, with no way to exit, or a way to participate in the system if you don’t accept its irrevocably custodial nature.
On the other hand we have nostr, which is the upmost self-sovereign system.
But lit comes with the tradeoff of extreme personal responsibility of holding one’s key in an even more challenging way than Bitcoin (you can’t spend your nostr into a new key if your old key becomes compromised)
Binary.
This work introduces a new scheme, with its own tradeoffs, but one that can fill the gap to help onboard the next cohort of nostr users without asking them to jump through too many hoops.
Learning the ropes of a new system is already challenging enough, asking new users to also learn about key management at the point of onboarding them is a very big ask with no clear benefit.
But I don’t want to become a custodian of a bunch of keys! What if we allow ANY provider to become an interoperable custodian and allow people to choose
This is akin to going from a single Wallet of Satoshi to thousands of @Fedi
In light of this aim, I’m changing the license of nsecBunker to full MIT (from MIT+CC); I want it to be easy for anyone to offer this service. nostr:note1crl44xk24yc2ym5xlyyfjdeumxueyguzxetseg8r0prqzmqts47sghnmgp
https://media.giphy.com/media/CPDbE8X0nEe3u/giphy.gif
PR incoming
The only difference to the current is updating to ndk latest version and adding a signer.on(“authUrl”) to open the challenge url
Wow, that's easy. NDK is going to be a permanent dependency of Coracle soon if I don't keep up
That is great foss nostr news. Thanks 🙏
🫡🫡🫡
Was already playing with an nsecbunker instance last week. But got stuck somewhere. Your work and especially this peace is pushing the boundaries 💪🏻
I'd love to help/see NIP26 adoption with hardware wallets or other secure key stores. Ensuring there is less need to transmit or otherwise handle long-lived irrevocable credentials is crucial.
NIP-26 is dead and should probably be marked as harmful and deprecated on the NIPs repo.
I was an advocate for NIP-26 until I noticed how insufficient it is and how making it better has astronomical costs that would destroy nostr
What are the problems with it? Is it mostly solved by 46, or something else?
I'm primarily concerned about that if identity is tied to a particular key pair, and that private key cannot be revoked or at least failed to renew without the public key changing, a bad client can permanently irrevocably compromise your "account."
as always Pablo doing cool stuff but as a "normie" I have no idea what the heck he's saying. keep on, friend! I need more knitting and baking friends on here.
nostr:nevent1qqs9vrkdyxsyg7x0ld97tw5e3y26dumxgk64adewed9evp97kkty0kspz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzp75cf0tahv5z7plpdeaws7ex52nmnwgtwfr2g3m37r844evqrr6jqvzqqqqqqywn37d9
Been kicking this around a bit and will be looking to implement asap.