Nostr Web Client

I see only 2 EXISTENTIAL THREATS for global Nostr adoption … BOTH of which will be addressed in my (upcoming) onboarding client.

1: Unwanted content and users in feeds and searches : This is ALREADY the single biggest issue for social media users today, and why we see such exodus from traditional platforms. Nostr has yet to “fix” this in a consistent and sovereignty respecting manner for users across all clients.

2 : Lost or compromised private keys. This is a problem unique to Nostr, and inescapably embedded within its core architecture. Keys are NOT passwords, but the “resettable password” and “managed account” experience is what people expect, and what Nostr NEEDS in order to scale. And yet we STILL have no standards for key management or data transfer.

No worries. My onboarding app will fix these both. Stay tuned … 👀

Reply to this note

Please Login to reply.

Discussion

Garbage nsec 10mo ago

On point 2, what are your plans?

ManiMe 10mo ago

These are my thoughts so far…

Right now, Nostr already has “event signer” apps and browser plugins (for both web and native clients), which limit exposure to a private key by providing “signing” services for the “numerous” clients that need to sign events.

A new class of “key manager” apps and browser plugins, in addition to offering “event signing”, would primarily limit exposure to a “master” private key by providing “disposable” keypairs that could be used in any client. Such a key manager could “simply” deactivate any of the keypairs it has generated, without effecting the underlying signed events OR the profile that created them. Newly generated keypairs would all be able to sign for the same events.

This technology is already specified and in wide use as Bitcoin BIP32.

An onboarding client, being a users “first” app, would be an ideal client to provide such “key management” services.

nostr:nevent1qqsdlhvctgvfvjnu3sukdxwzpqrc98serd2cdsm0sceka03jq0rxe5gzyr0k07d8usgj2azuheavl0wdqd530qxxg00hhtts7hfppredflpqqqcyqqqqqqgpp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqguwaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skczjpa5z

Garbage nsec 10mo ago

Ah gotcha, thanks. I was thinking something along those lines earlier but was swayed by Vitor's response here.

Github link: https://github.com/nostr-protocol/nips/issues/1810

ManiMe 10mo ago

On second thought … maybe Vítor actually knows better …

nostr:nevent1qqsyawxmknw8ryth234f48e08u83wwdwznn8l2fw2vavzyktclrjgcczyr0k07d8usgj2azuheavl0wdqd530qxxg00hhtts7hfppredflpqqqcyqqqqqqgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgdwaehxw309ahx7uewd3hkcqgnwaehxw309aex2mrp09skymr99ehhyeccnyskg

Garbage nsec 10mo ago

I think the kicker is that Outbox is critical for Nostr's future and this overheats the outbox flux capacitator and blows it up. All client side and all about capacity--nothing really to with cryptography barriers.

ManiMe 10mo ago

I maybe be quite mistaken… but it seems that the “main identity” pubkey can be requested from the “frost signer”, and any (frost compatible) outbox implementation would otherwise work as normal?

Garbage nsec 10mo ago

Oh yeah Frost is all good because Frost avoids subkeys (or slave keys, linked keys, or whatever to call them) entirely, and those are the cause of the Outbox overheating thing. Frost produces the exact same signature as the nsec without requiring that the nsec show itself.

But once you introduce other signatures (i.e. other keypairs) then that's where that client-side overheating kicks in.

ManiMe 9mo ago

Alright … now I’m just getting familiar with frost … but it looks to me like the bifrost implementation generates a unique (group_pk) pubkey for each “group” of “shares”… and it isn’t straight forward how the “main” pubkey would be obtained by a client “signer”, signing with one of the “shares”. What do you know about this?

https://github.com/FROSTR-ORG/bifrost/blob/master/src/types/group.ts#L24

Garbage nsec 9mo ago

It's the same public key and it's the same Schnorr signature. Frost is not generating a new keypair in any sense.

Garbage nsec 9mo ago

Basically "group_pk" is not generated, it's detected. And the thing being detected there is your actual nostr npub in hex format (provided the shares are of splits of your nsec).