My plan for Soapbox + Nostr onboarding UX is to have it generate a 12-word seed on the client. You see it once and are told to write it down, then it disappears forever. It gets stored securely in the browser and can then be used to sign events. To recover your session, you need the 12-word seed.
This is the basic normie flow for mass adoption. There are other options, including NIP-07 signing with a browser extension like Alby, and NIP-46 support where you can sign events remotely using a dedicated signer app. You can also import by seed or nsec.
Technical info: I'm making the ServiceWorker a signer. You can send it messages like generateSeed, signEvent, decrypt, etc. When you generate the seed, the ServiceWorker generates it within the worker context and stores it in the Web Cache API. Which is an absolutely insane thing to do, but it will work. It sends the seed back to the client exactly _once_ when you generate it, and you can never retrieve it again because the worker will block fetches to it. But the worker itself can access it and sign your events. This is Vegan Mad Science.
Alex Gleason /
npub108…uyev6
2023-09-08 17:04:52
Author Public Key
npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6Published at
2023-09-08 17:04:52Event JSON
{
"id": "ba2486895e6f197b8bea5fc8e690275ebaf447dc49466882558c393e41da2ee0",
"pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
"created_at": 1694192692,
"kind": 1,
"tags": [
[
"proxy",
"https://gleasonator.com/objects/31baf84a-5fc7-47d3-a309-5c167c7b3680",
"activitypub"
]
],
"content": "My plan for Soapbox + Nostr onboarding UX is to have it generate a 12-word seed on the client. You see it once and are told to write it down, then it disappears forever. It gets stored securely in the browser and can then be used to sign events. To recover your session, you need the 12-word seed.\n\nThis is the basic normie flow for mass adoption. There are other options, including NIP-07 signing with a browser extension like Alby, and NIP-46 support where you can sign events remotely using a dedicated signer app. You can also import by seed or nsec.\n\nTechnical info: I'm making the ServiceWorker a signer. You can send it messages like generateSeed, signEvent, decrypt, etc. When you generate the seed, the ServiceWorker generates it within the worker context and stores it in the Web Cache API. Which is an absolutely insane thing to do, but it will work. It sends the seed back to the client exactly _once_ when you generate it, and you can never retrieve it again because the worker will block fetches to it. But the worker itself can access it and sign your events. This is Vegan Mad Science.",
"sig": "2f68c7001d905f8141e2a357cacc527015439b20f9c939d0b06f43c311a7323ada02b3e4db4cbf8b1b99ea0fdef4d4d89b9b429a28f08da5634e105e8e132302"
}