hodlbod

> Well, it accomplishes the goal of erasing the content. Is that worse than relying on or rendering an event with broken old invalid information that the creator had already...

> Let's write and code this. It is by far the best solution. > Agree, clients should not receive deletes at all. I think these positions are mutually exclusive. What...

This migration has three steps: 1. Signers add support for both nip 04 and nip 44 2. Clients stop sending nip04-encrypted events 3. Signers drop support for nip04 Knowing whether...

Also, I'm confused, are we talking about the nip46 encryption algorithm only, or DMs? Coracle supports new-style DMs, but I can't confidently move my nip 46 implementation to nip44 until...

I added support for using nip46 encryption to welshman this morning, and tested it in Coracle against nsec.app, but it looks like 44 isn't yet supported there. I'm ready to...

Coracle is ready to use nip44 once signers start supporting it

Yep, pretty much everything goes through a function that accepts either and detects 04/44

This is probably necessary, but it will also break clients. Extensions should have some way to detect this feature, maybe by disabling it in the UI if the client doesn't...

This has been tried lots of times on various clients (at least for default profile pictures or relay color codes), and I don't think it works very well. I also...

> I would argue this justifies it being a standard, clearly there is demand Yes, and github does it etc. But I've never once identified someone by their identicon, unless...