{"type":"rich","version":"1.0","author_name":"npub18yq2ukhtlnkuzzykluyjvxap3vtvdqf0arvtag6rx02klk6gymgqp3txp2","author_url":"https://nostr.ae/npub18yq2ukhtlnkuzzykluyjvxap3vtvdqf0arvtag6rx02klk6gymgqp3txp2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-19\n🗒️ Summary of this message: The author suggests that a simple plain text response of an address is sufficient for alias resolution, but worries about future compatibility issues.\n📝 Original message:If alias resolution was guaranteed to always be just the address, then \nyes, I would opt for no serialization at all. A simple plain text \nresponse of an address is about as simple as it can get.\n\nThere are already a lot of good ideas floating around about how the \nalias protocol could be extended. Is it really going to stay that simple \nfor long? I would personally much just have a serialized response \nupfront, rather than having to worry about backward compatibility in the \nfuture.\n\nOn 12/19/2011 10:17 AM, slush wrote:\n\u003e In my opinion, there's not necessary any payload format (json, xml,\n\u003e multipart). In keeping stuff KISS, everything we need is just an address\n\u003e in response + potentially some stuff like HTTP redirects (for providing\n\u003e additional compatibility for proposal of bitcoin URIs with \"amount\",\n\u003e \"label\" and other parts). I don't see reason why we need some extra\n\u003e payload yet."}