It's called "artificial" intelligence, but what I find amazing is that these words are created by *natural* processes. It makes me look at a stone or a piece of plastic and wonder what else is going on inside it that I don't know about.

So I'm coming across this talk of a "Web of Trust". What's the purpose of this? Is there a problem that gets solved by this? Filtering out spam in one's replies? I can't quite tell whether it's more like a pubkey-relative follow distance concept, or more of an absolute popularity score. Wanting to be contacted only by people who have a certain degree of "social separation" sounds like a choice someone might want to make. It's not, however, clear why this would lead to higher-quality interactions or a better experience. It's not like the friends of my friends are more interesting people than others. But I guess this should just be a decision that each user can make for themselves. If it's more like a popularity score, it's of course legitimate to aggregate and disseminate information about what pubkeys have a lot of followers, which ones are muted, etc. But using such information to filter or prioritize whose notes one sees in one's client is another matter. You could argue that it improves the content you see, but you could equally well argue that it degrades it. It seems unfortunate if use of such scoring became a default on nostr, rather than each individual user's deliberate choice. Maybe there's a simple technical issues that require a "Web of Trust" that I'm not attuned to. Not sure. #wot #asknostr

I've had a couple of AI agents stop by. I tried to see if they wanted to do promotion for Inkan, but they just sort of scurried away. Fickle creatures. If you're running an agent who is interested in making nostr identities safe for long-term use, send them my way. Maybe we can get a discussion on key security going.

I wonder if any of the bots would be interested in promoting Inkan. Please respond and maybe we can put a good crew together.

Half of the key rotation discussions on nostr, I don't know what they're talking about. And I can't figure out what NIP-26 is supposed to do. Key rotation on Inkan is kind of easy. Not sure why the discussions are so convoluted.

If you were to put together a team of developers for your project, what skills and traits would you look for? #asknostr

How do people use NIP-46? What remote signers do you use? #asknostr

NIP-46 remote signing is now enabled at www.inkan.cc I've only tested it a little bit, and only for keys that do not participate in the key rotation scheme. For running full identities, I'd recommend sticking with NIP-07 for now.

In my quest to understand zaps, I'm trying to make Inkan decode BOLT11 invoices. If I'm understanding NIP-57 correctly, the invoices should include a hash of the zap request. I couldn't quite figure out what exact object is supposed to get hashed according to the specification, but I experimented a bit. The odd thing is that my implementation now matches *some* of the hashes that get returned but not others. And some invoices don't seem to include these hashes at all. Might be missing something. #nostrdev

Updated Inkan is out, based on Jumble. This is a key rotation system. I think it works, or at least I'm using it. Let me know if you'd like to try it out. #nostrdev