Thread - Nostr Hypermedia

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 … 👀

Replies (10)

Repeatedly nuked profile 11 months ago

On point 2, what are your plans?

1 replies ↓

ManiMe manime@npub.bar 11 months 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.

ManiMe

How is this better than “simply” having a “master” key pair (like Bip32 “xpub” and “xprv”) that generates disposable pubkeys for use in any client? (where the “xpub” is actually exposed for anyone to verify the “ownership” of generated pubkeys) AFAF : @npub16v82...eqha

View quoted note →

1 replies ↓

Repeatedly nuked profile 11 months ago

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

Github link:

GitHub

Linked Keys for Multi-Device Nostr · Issue #1810 · nostr-protocol/nips

Right now, using Nostr across multiple devices is a challenge. Either you: Share your master key (risky, especially on a phone). Use separate keys ...

1 replies ↓

ManiMe manime@npub.bar 11 months ago

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

ManiMe

Corect me if I’m wrong … but NOW I see a few major differences in these two “key management” schemes : FROST vs BIP32 … 1: “sub key” derivation via FROST (called “shares”) can be initialized (once or multiple times) from a users EXISTING npub, providing forward compatibility for existing pubkeys to act as “main identities”. BIP32 (afaikt) must generate a fresh xpub as the “main identity”, excluding existing npubs from reaping the benefits? 2: FROST handles a variety of “multisig” scenarios OOTB, allowing increased security if end users desire it. Implementing BIP32 alone would not provide multisig functionality? 3: FROST libraries are currently in development and ready to be implemented in Nostr clients. BIP32 is not? OTHERWISE … - both solve for “disposable” pubkeys which are cryptographically linked to a “main identity” pubkey. - both require additional implementation by signers and native clients. - both require a “connected” signer or native client to request the “main identity” pubkey from some remote service. Forgive my ignorance as I wrap my head around this very real need. Have I missed anything? @npub1s9et...lxzl https://www.frostr.org/

View quoted note →

1 replies ↓

Repeatedly nuked profile 11 months 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.

1 replies ↓

ManiMe manime@npub.bar 11 months 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?

1 replies ↓

Repeatedly nuked profile 11 months 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.

1 replies ↓

ManiMe manime@npub.bar 11 months 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?

GitHub

bifrost/src/types/group.ts at master · FROSTR-ORG/bifrost

Core library for implementing the FROSTR signing protocol. - FROSTR-ORG/bifrost

1 replies ↓

Repeatedly nuked profile 11 months ago

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

1 replies ↓

Repeatedly nuked profile 11 months 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).