NIP-07: switching accounts

[pavanjoshi914]

Introduction:

The proposed enhancement to the window.nostr NIP-07 spec aims to improve user experience by introducing event subscription functionality. By allowing users to subscribe to specific events such as accountChanged, we can notify client websites about important changes happening in the connected NIP-07 supported wallet. This will ensure that the client website always displays accurate and up-to-date information, even when users switch between multiple accounts in their NIP-07-supported wallets.

Proposal:

One of the essential events we can introduce is accountChanged. When the user switches between different accounts in their NIP-07 supported wallet, this event will be triggered, notifying the client website about the account change, and then the client website can update information on the website according to the account

1. Subscribe to the event named accountChanged

window.nostr.on('accountChanged', accountChangedHandler);

2. Unsubscribe from the event named accountChanged

window.nostr.off('accountChanged', accountChangedHandler);

where accountChangedHandler is a listener function that will be invoked on firing the event. You can re-request the user's public key to update website content with data related to the new account

output:

2023-08-08.13-54-26.mp4

Additional Information for developers (if required):

EventEmitter API can be used to implement such events within the window.nostr to facilitate event handling. The EventEmitter will allow users to subscribe to specific events and receive notifications when those events occur.

documentation for events: https://nodejs.org/dist/v11.13.0/docs/api/events.html#events_class_eventemitter
packages such as events pkg implements the Node.js events module for environments that do not have it, like browsers.

 window.nostr.on(eventName: "accountChanged", listener: ( ) => void): void 
 window.nostr.off(eventName: "accountChanged", listener: ( ) => void): void

Note: wallets can call the registered event internally using the same provider class as follows

window.nostr.emit('accountChanged', accountChangedHandler);

Benefits:

1. Real-time Updates of the events happening on the NIP-07-supported wallet
2. Improved User Interaction
3. Avoiding Data Staleness

Conclusion:

The introduction of event subscription functionality in window.nostr will significantly enhance the user experience for client websites integrated with NIP-07-supported wallets. By leveraging events like accountChanged, client websites can stay in sync with the connected NIP-07-supported wallet, ensuring accurate and up-to-date information for users. This enhancement aligns with our commitment to providing a seamless and user-friendly blockchain wallet experience for our users.

[staab]

I like this.

One use case that this doesn't cover cleanly (from a UX perspective) is when a user wants to trigger an account selector from within the app. So for example, I recently added account switching to Coracle — to add a new account, the user clicks + Account, then selects their log in method. If they user is already logged in using an extension, clicking "log in with extension" will only log them in using their current account (or show an error). It would be nice to be able to communicate with the extension to ask the user to select an account. Maybe this is too much for right now, just a thought.

[vitorpamplona]

+1 for multiple accounts.

[fiatjaf]

This is fine, but instead of these magic strings can we go with hardcoded functions, like window.nostr.onAccountChanged.addListener(...)?

[pavanjoshi914]

This is fine, but instead of these magic strings can we go with hardcoded functions, like window.nostr.onAccountChanged.addListener(...)?

cool! But most of the events systems I see either use .on method or just use addListeners

References:
nostr-tools : using .on method to handle events
node.js: providing API based on .on method
MDN docs for events This normalizes using addEventListener for events. in our case it might not be a great developer experience to use this.
npm packages : majority of the npm packages providing events prefer.on method

is there any specific use case to use hardcoded functions? also, I think it will be hard to implement. current solution uses a single method to handle every new event.

[fiatjaf]

Yes, but they're all very bad and confusing.

Web extensions use the format I'm suggesting. It's much saner.

[alexgleason]

I think this issue should be renamed "NIP-07: switch account". At first I thought you were suggesting NIP-07 perform the basic work of clients, which makes no sense.

[bumi]

Yes, but they're all very bad and confusing.

Can you elaborate why all are very bad?

I think pretty much any app/library I know work like that and I favor the most adopted/known APIs to behave like developers already know and maybe expect it.
From the top of my head I find it easier to implement such a provider (which could reuse also existing libraries)

But I guess this is a personal preference, what are other opinions?

[Semisol]

since this will break compatibility with old clients that can't recognize this, we should add a enableAccountSwitching call that signals the app supports account switching.

[bumi]

since this will break compatibility with old clients that can't recognize this,

what would it break? wouldn't clients that do not listen to this event simply behave like it is currently?

[Semisol]

what would it break? wouldn't clients that do not listen to this event simply behave like it is currently?

they would not since it is the extension triggering an account switch.
the client will think the extension is still public key A when it has switched to public key B

[bumi]

the client will think the extension is still public key A when it has switched to public key B

this is the bahavior right now. The user can change the accounts and clients currently have no way of knowing that the selected key changed.

there are also clients that cache the key locally and do not get it from the extension which can also lead to the problem of different keys.

[Semisol]

this is the bahavior right now. The user can change the accounts and clients currently have no way of knowing that the selected key changed.

therefore keys should not be changed without a full page reload unless the client is explicitly aware of this feature

[neilck]

I like this idea, and will implement in the AKA Profiles signing extension once finalized and merged.

[neilck]

Implemented in V1.05 of AKA Profiles Extension as
windows.nostr.on('accountChanged', accountChangeHandler)

[pavanjoshi914]

this is the bahavior right now. The user can change the accounts and clients currently have no way of knowing that the selected key changed.

therefore keys should not be changed without a full page reload unless the client is explicitly aware of this feature

Adding an enableAccountSwitching call might not be necessary. enforcing a full page reload for account switching might not be practical, as it's up to the provider to handle this behavior, and users might be on different tabs or even different websites at the time of account switching. Therefore, it's best to leave it to the providers. Alby did that even before supporting nostr. let's avoid unnecessary complications.

additionally, now Alby + aka-extensions supports this spec can we get this merged?

[MoritzKa]

Users with more than 1 account often forget to switch to the right Nostr account in an extension. The consequence is a super frustrating experience for users. We regularly read complaints such as "this app is broken" or "Nostr does not work" etc. in our support channels. We would like to prevent such an experience. This enhancement will improve the UX for users by giving clients the chance to react to account switches and show users in which account they're actually logged in.
There are now two implementations supporting this proposal. Let's move on and merge this.
cc @Semisol