Yeah, this UX would definitely be a challenge.
Keychat probably doesn't follow the NIP-EE, but I think it's something worth considering. nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8
Yeah, this UX would definitely be a challenge.
Keychat probably doesn't follow the NIP-EE, but I think it's something worth considering. nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8
At first glance it looks to me like you follow NIP-EE in order to interop then you have to follow that NIP super carefully. So many checklist items in there that you cannot not tick.
When creating a brand-new application-layer spec, is it better for one team to define the spec first and have others build apps around it? Or should multiple teams start by building apps independently and then work together to converge on the best possible spec?
One thing a lot of specs could benefit from is ecash stamps.
We strongly recommend reading the MLS specification directly, rather than relying solely on NIP-EE.
I read this MIMI doc, traumatic flashbacks to Feynman diagrams in old textbooks.
https://www.ietf.org/archive/id/draft-ietf-mimi-protocol-01.html
I don't quite get your point. NIP-EE also follows the MLS specification, it just standardizes the use of Nostr events to send mls messages.