Improving signing UX while fixing a replay attack in Blossom.
👋 Say hello to Nostr Web Tokens.
Login to reply
Replies (23)
@hzrd149 we can improve blossom auth
thoughts @hzrd149 ?
Interesting.
Those three letter tags look horrible though... 👎 just use the full string
cool! the event is passed clear to the target? No encryption?
You must make sure your NWT does not ends in the wrong hands.
Handy for client to manage their login once and for all, I see it being particularly useful for paid relays if they implement it.
Super interesting. Have to look into it for the details.
View quoted note →
TLS
nip98 should have just followed jwt conventions. thats what this looks like to me. cool
I was thinking nip44 if the target has a pubkey, may be overkill, some will want the option, I don’t know
nostr devs hate jwt. I wrote my original APIs to use that because it's obviously better for user signing experience.. I have since capitulated to nip98.
What replay attack are you experiencing?
Very nice to see, I think this makes sense.
lol it’s true. may as well reinvent the wheel.
I like this, its a lot more structured and thought out than my initial attempt to build authorization tokens for blossom.
I haven't thought through this completely yet, but I think this might be a good standard to move blossom to, and hopefully deprecate NIP-98.
Unfortunately that would mean a breaking change, and no longer using the kind 24242 which I liked :(
Fwiw the zapstore publishing tool only pushes to one Blossom server because it's a pain to prompt the user for many (in browser signing for example)
I think nwt would solve that problem
And the replay attack sounds like a major problem
Can you upload this as a custom NIP to nostrhub.io?
No encryption specified in the spec, but it can use NIP-44, or being sent using White Noise.
GitHub
nips/44.md at master · nostr-protocol/nips
Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.
or whatever other encryption scheme for that matter.
yeah, I tend to agree. I just choose to copy the JWT semantics, but maybe we can afford the full string
Thanks mate, I appreciate.
I think changing kind is the best way to deprecate the old auth, otherwise there will be confusion and people will try to support both the old and the new spec.
tY*
is this a shitcoin
Very cool!