Oddbean

Sure...why not? I'm more interested in the person. The person is the content, not the other way around. We all have interests, and those outside interests are what make relationships deeper. Having two accounts seems counterproductive...

One feed* just doesn't make any sense Look at reddit- the most common alternate accounts are either throwaways or novelty accounts. Nostr has plenty of both. These don't serve the purpose of splitting interests as much as specifying a "role" or "personality," or maintaining privacy. Look at nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75sprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0y8qdrm - He has two accounts. One is personal about climbing and the other represents the "developer/influencer Pablo". Is this beneficial for him as a user? Probably Is it ideal? I would argue not for me, and likely not for others. Can't speak for Pablo but I think Nostr can offer more flexibility that would defeat this inherently bastardized, single-feed structure. Nostr says "discovery is a manual feature" and to that I say "feeds are the garbage can for discovery". I leverage my feed to discover often, so it is not inherently a problem of feeds themselves. The problem is single-feed silos. So we can manually segregate feeds with a tool like Listr which integrates with Amethyst. But this process is pretty much the same as it was 3 years ago. Unless another client is offering better list curation. I haven't seen anything change in this regard. There is a bounty out for CRUD lists in amethyst and I really hope someone can pick up that lead. Not here to complain, just my two cents. The resolution would be native list management in my eyes. Splitting the user between tools does not feel intuitive with an app like amethyst. Just about everything else is miles ahead. Our feeds should be able to designate their own relays in my opinion. Let us filter by relay first, then by users, then by content.

Would love to see more and more development for multiple key management nostr:nevent1qqsq6enqcl80h0md3s2mw67dp3jm8d4dvj6g7pds5se0gc95gwqqjnqpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzcpurnt

NostrKeyring already solves this issue but needs someone to contribute to implement sign event. If you implement it, ill pay you a lot of sats. The repo is on to website. https://www.NostrKeyring.com

ESBuild compiles nostr-tools into nostr-tools.js. Background.js imports this file but you could cut the middle man and put tools inside background.js and compile it together. I'm unable to find proper documentation on how the logic of signEvent works. I'm pretty sure I'm implementing this function wrong and that's all I need help with. https://github.com/dankswoops/NostrKeyring/blob/a9d16a57567121c2090738203199b867e1c83f2d/extension/background.js#L9 I'm happy to put $100 of btc on it. To get the test environment setup, npm i, npm run build, put the extension into firefox using manifest json at about:debugging#/runtime/this-firefox Then create a user profile, log into that user to pass the keys to background.js and now you should be able to edit bg.js, test a nip-07 signEvent login. to retest: change the code, refresh the extension, log out then in of the user, and try to signEvent. That's all you need to know dev on it.

If it’s too easy, I will be accidentally shitposting from my Satoshi account. https://media0.giphy.com/media/VbnUQpnihPSIgIXuZv/giphy.gif?cid=6c09b952nn3winc803r4o6df4l5pcwnwqw0msfr14yb422s1&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g

You can run multiple profiles with firefox. That has been a thing for I think 20 years or more. You may have to launch it with a command-line parameter, but you used to be able to have it ask which profile you want as it starts up.