Agree.

Immutability is always a good idea in software.

Eventually one can have some concept of versioning or link to old notes or "this note replace this old one".

3200 bits :)

In Italy apparently it has become a long mess to simply renew IDs and passports in many large cities.

Interesting.

While decentralised technologies get better by the day, the centralised structures of past ~150 years are crumbling at their most basic level.

Every victory has a taste that's bittersweet.

The implementation must follow the nip46 signer protocol, right? https://nostr-nips.com/nip-46#signer-protocol

Yes. And do not write tests either.

Just hack your way to the next release adding one more if/else in the already 5 levels deep function.

Just remember to upgrade the lint rule.

The note starting with "It should indeed return false"? :)

My point is that the library should not assume that everything has been done properly, quite the opposite.

"You should not change the event" is one thing. Assuming that will not happen and returning that an altered event is verified is another.

The semantic of "verified" here becomes: there is a property set as verified: true in the json. While it should not what it should be or at least what I was expecting.

If it does that, as one would expect, why the check returns true while it should be false?

TBC: the integration test "failed" means that the signup HTTP worked despite the modified event being sent through, while it should have returned 401.

I was giving for granted that it behave that way, then today I made an integration test over my signup API to see taht it would fail under an "attack" with a modified event.

The test failed and I got scared so I did dig deeper and wrote that test.

The whole library assembles in the "finalized event" both the original event and the sig/pub/hash properties. So when you call verifyEvent it uses the hashes that one pass as "id" rather than recalculate the hash from scratch from the original event properties.

I am no security expert but that look *very* bad to me.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

If I ask to verify a finalized event but change content and/or created_at, anything at all actually... shouldn't the verification return false?

Or am I missing something huge? :/

```js

const secretKey = generateSecretKey()

const now = Math.floor(Date.now() / 1000)

const event = finalizeEvent({

kind: 1,

created_at: now,

content: 'hello',

tags: [],

}, secretKey)

const isGood = verifyEvent({...event, created_at: now - 10, content: 'something else'})

expect(isGood).toBe(false)

```

https://nostr-nips.com has nicer layout than https://nips.nostr.com

Mostly because the latter have the text span across the entire window width which makes it harder to read.

After last month progress on Frankie, I will have space to focus and build something over Nostr relays in the next weeks.

nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg Why is primal.net website asking me for this authorization all the time?

thanks nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy I will check the nip46 discussion. I am curious to see what is the "question" around the callback_url.

If oauth flows work perfectly with no popups/iframe/modals, I am positive we can build that way as well.

And I do not advocate for removal of the input field, I say that as we have 1/2 providers now, having a click-click solution that just work is a good idea, rather than forcing user to insert the "email" all the time.

And nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 yes there has been a time that we had 40 oauth providers and a couple "bind-them-all" buttons... And almost all were doing the popup thing. It was even cool. The early Web2.0 era.

But what about oauth now? Most website offer 2/3 oauth + email field, and all oauth-flow are pure redirects. Because offers consistent navigation (impossible with popups), does not require to load resources from external websites (which is a bit NO for me both as user and developer), and I think a more clear UI and probably more secure overall.

Also we do not have 68 now, or even 6. We have 1, maybe 2. Designing for 68 is not future proof, is over-engineering.

Ok, thanks for listening guys really appreciate the conversation. Now I'll go back to damn frontend testing setup - the hardest thing of hard things 😉

nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg How can I see only post from people I follow? There seem to be no such option in the feeds...

Thanks.

Sure, but here we are talking about 2 things here

1. the nsec.app flow (or any other provider) which IMO should provide a leaner option - specifically with no modals and no popups.

2. the styled button to "bind them all" has a different purpose and yes, provide great utility as a drop-in solution.

So yes, my "objections" is mostly to the modals/popups in nsec.app flow.

I still owe nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy a proper github issue about that.

In respect of the window.nostr.js button UX I would argue that in the Standard Oauth user click on the familiar Google icon, does not have to type in your email address.

But yes, how would the Login button know which provider to call without the address?

Then maybe an option to just "pick a provider" and show a list would be nice, I guess.

My fav UX flow is:

1) myapp.com show a "login with nsec" button

2) click redirects the whole page to https://use.nsec.app/auth (or some other handle in place of "auth"

3) there it shows all my identities, I pick one and that makes a callback to myapp.com/callback?event=....

No modals, no popups and no mandatory custom login button with style that does not match the one on myapp.com.

It is s nice to provide a convenient styled button.. but not for all situations.

That's also easier than having to remember "username@nsec.app", or whatever identity I am using this week, or whatever provider I am using this week: is it "nsec.com? .app? .gov? .nostr?"

I think that should also be easier to implement for both you - auth service provider or javascript plugin provider, and me using them.