I think NIP-05 aliases are far from being a must have!

Some people with personal registered domains may find it useful to add a domain alias to their pubkey.

Or maybe in a Company it could be useful as a way to announce their official pubkey.

But I don't see any value on it for the normal user.

I even think assigning a checkmark in the UI to every user with a defined NIP-05 alias is misleading and helping the spammers and scammers.

If the domain is owned, I believe there is proof of work.

It's just proof that you have access to the domain. There is no verification.

I understand, but I believe it's PoW

Username is not unique, better nip05.

Should Amethyst stop displaying usernames?

Today:

Display Name @username

user@nip05domain.com

Proposal:

Display Name

user@nip05domain.com

Andre, are you planning to go forward with Zebedee nostr integration?

🫂

The concern isn’t around public keys needing to be private or even anonymous - it’s more targeted toward publishing lots of event kinds by default (without opt-in, or even not being obvious is client UX, including new ones), when all I actually want to publish are kind 0,1,3,7,42,1984,etc (profile, notes, contact list, reactions, channel messages, spam reports, etc).

Pubkeys may be cheap, however I’m not going to create 100 just to segment or try obfuscate my data. Pubkeys if stored correctly, shouldn’t be throw away use for people - unless that’s their intention.

I have no issue with 1,000 NIPs that may content private/sensitive information being drafted - that’s 100% fine - the issue is that data being published by default by client apps - and not opt-in and clear in UX.

"WHY DO PEOPLE KEEP CONFUSING OUR ECASH PROJECTS????"

#[0] 🤝 #[1]

What if nip-05 was used for invalidating keys?

ex: array of keys, last key in array is considered valid and clients should consider all previous pubkeys as invalid.

More or less, I'm still working out the details as I go along, and the model itself isn't very well defined. Below is a diagram by

npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk that tries to simplify, but I don't follow it to the letter.

Hey Lightning Wallets, you have done an amazing job integrating zaps!! 👏 Wonderful job!

What about stepping up your nostr integration?

What about allowing the user to opt-in to this integration defining his npub?

With that npub the wallet could get from nostr relays information about the user's sent and received zaps, and fetching info of the sender or receiver.

That information could be used to enrich the corresponding Lightning transactions history with the name and pfp of the sender/receiver.

What do you think?

Does it make sense?

cc: #[0] , Alby, #[1] , Stacker News , #[2] , #[3] , #[4] , #[5] , Strike(army), #[6] , etc.

True.

As there's no one Mempool in Bitcoin, there's neither a Global Feed in nostr.

- Each bitcoin node has its own mempool.

- Each nostr relay has its own global feed.

I love that Romanesco does in fact come up when you google ‘psychedelic broccoli’

Reference please