sure. just configure your key there. you can use it everywhere.
hehe :) that's the main thing of course. the one thing that we currently have as such a higher-level standard.
this is the mentioned pull requests: https://github.com/nostr-protocol/nips/pull/224 it's worth reading to understand the discussion.
check this out: https://nproxy.zerologin.co/
by @npub1txukm7xckhnxkwu450sm59vh2znwm45mewaps4awkef2tvsgh4vsf7phrl
it would be easy for the client to check this before sending the post and give the user the option to switch.
we should ping the hamstr developers for this.
I am not saying Alby is waiting. As mentioned Alby is committed to push this forward as much as possible.
I personally just believe that some other proposals would have seen faster adoption. It is not ideal that all lightning address providers are required to now make Nostr specific changes. this slows down adoption and is not really the idea of interoperability.
I could not post this from a different account
That's what it looked like to me. I assumed hamstr builds the event with the pubkey of account A, account B signs it and then the validation on the relay(?) rejects this. But I don't know the details.
ah cool, will be interesting to see.
yes this should be improved in the client. but I think relays will reject the message if it is signed with the wrong key.
I don't think that's the case and there is some confusion on how it works. The more complex part (stacker news needs to publish to nostr) is still missing as far as I can see?
AFIK the expensive thing to scale in websockets is having the connection open. Will we see relays that require users to do some authentication to even open the connection?
Or will release always be open and will just reject nodes from unknown users?
In my opinion the spec has problems that I shared in my comments in the GitHub issue.
It adds Nostr specific complexity to the universal LNURL protocol which will make it harder for LNURL providers to implement.
I would have hoped we build on existing interoperable protocols (like LNURL) and not need to invent a new Nostr specific one (which also only works in Nostr). This now means all tools and service providers need to support Nostr to make this possible - this will take time (it took LNURL years to get to the current adoption)
To me interoperable, reusable protocols are key.
And don't forget payments on Nostr are possible. You can tip/zap any lightning address. Only the payment proof (the zap) will not be published on Nostr.
But ultimately adoption and demand will matter. We need to make Nostr big to convince everybody. :)
Alby is for sure committed to support this as much as possible.
actually you can receive payments already with all lightning address tools and providers. Only the publishing of the Nostr specific payment proof is not implemented. I also expect that this will still take some time for some tools and providers.
hamster.to actually has decent multi-account support in the UI.
that's the problematic part of NIP-57. Now all the LNURL tools and providers need to do this.
see the discussion in the pull request: https://github.com/nostr-protocol/nips/pull/224#issuecomment-1426759925
