window.nostr.getPublicKey() outputs your npub. Frostr doesn't change that.
Frostr works with your existing nsec and outputs your existing npub.
Frostr allows you to put your nsec into cold storage, and use it to generate new sets of shares offline. It doesn't change your nsec/npub.
Frostr simply splits your nsec into many shares, so that one device does not hold your entire npub, only a part of it.
BIP32 works with frostr (technically not yet, have to fix a bug first), so you can derive child keys from your nsec, and frostr can sign with those child keys.
BIP32 is not utilized by nostr AFAIK, so child npubs will not be recognized as an extension of your main npub. However if nostr protocol decides to implement BIP32 (or any key derivation scheme really), then frostr will work with it.
Using your nsec with frostr also does not lock you into using frostr. It doesn't do anything strange or proprietary to the final signature, so your bare nsec/pub will validate signatures made with frostr.
From a cryptography perspective, you cannot tell the difference between a signature from frostr, or from your bare nsec. They are the same signature.
I hope this helps.
cmd /
npub1gg…lulq3
2025-03-16 06:00:52
in reply to nevent1q…nh7x
Author Public Key
npub1gg5uy8cpqx4u8wj9yvlpwm5ht757vudmrzn8y27lwunt5f2ytlusklulq3Published at
2025-03-16 06:00:52Event JSON
{
"id": "c588d5afda0ab7a9ead882718084e49dc8aab990771ad1208bba50d4a89fbc00",
"pubkey": "4229c21f0101abc3ba45233e176e975fa9e671bb18a6722bdf7726ba25445ff9",
"created_at": 1742104852,
"kind": 1,
"tags": [
[
"p",
"4229c21f0101abc3ba45233e176e975fa9e671bb18a6722bdf7726ba25445ff9"
],
[
"p",
"df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"d30ea98ea65e953f91ab93f6b30ea51eb33c506f87d49f600a139aef00aa9511"
],
[
"p",
"8172b9205247ddfe99b783320782d0312fa305a199fb2be8a3e6563e20b4f0e2"
],
[
"p",
"df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200",
"wss://nos.lol"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
"ws://192.168.18.7:7777"
],
[
"e",
"0a35e05819db7e4b2e3713802c6ae573ec9e3ebd01aeccc7f5f96be3303f7793",
"wss://nos.lol",
"reply",
"df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200"
],
[
"e",
"1bed61c026408f2f9aa748f4c23c4a064e74e90c0fb1799d91cbb7406da4def0",
"ws://192.168.18.7:7777",
"root",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
]
],
"content": "window.nostr.getPublicKey() outputs your npub. Frostr doesn't change that.\n\nFrostr works with your existing nsec and outputs your existing npub.\n\nFrostr allows you to put your nsec into cold storage, and use it to generate new sets of shares offline. It doesn't change your nsec/npub.\n\nFrostr simply splits your nsec into many shares, so that one device does not hold your entire npub, only a part of it.\n\nBIP32 works with frostr (technically not yet, have to fix a bug first), so you can derive child keys from your nsec, and frostr can sign with those child keys.\n\nBIP32 is not utilized by nostr AFAIK, so child npubs will not be recognized as an extension of your main npub. However if nostr protocol decides to implement BIP32 (or any key derivation scheme really), then frostr will work with it.\n\nUsing your nsec with frostr also does not lock you into using frostr. It doesn't do anything strange or proprietary to the final signature, so your bare nsec/pub will validate signatures made with frostr.\n\nFrom a cryptography perspective, you cannot tell the difference between a signature from frostr, or from your bare nsec. They are the same signature.\n\nI hope this helps.",
"sig": "24f8d7328c2968926acc6561f82790c4e3429ff5ab29dbcfe15893b48a3dc38355c60d7415beaaf5d1218929755da73aeacb9af10f5f999013db9809b70d1340"
}