Jordan Mack [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-19 🗒️ Summary of this message: The author ...
📅 Original date posted:2011-12-19
🗒️ 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.
📝 Original message:If alias resolution was guaranteed to always be just the address, then
yes, I would opt for no serialization at all. A simple plain text
response of an address is about as simple as it can get.
There are already a lot of good ideas floating around about how the
alias protocol could be extended. Is it really going to stay that simple
for long? I would personally much just have a serialized response
upfront, rather than having to worry about backward compatibility in the
future.
On 12/19/2011 10:17 AM, slush wrote:
> In my opinion, there's not necessary any payload format (json, xml,
> multipart). In keeping stuff KISS, everything we need is just an address
> in response + potentially some stuff like HTTP redirects (for providing
> additional compatibility for proposal of bitcoin URIs with "amount",
> "label" and other parts). I don't see reason why we need some extra
> payload yet.
🗒️ 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.
📝 Original message:If alias resolution was guaranteed to always be just the address, then
yes, I would opt for no serialization at all. A simple plain text
response of an address is about as simple as it can get.
There are already a lot of good ideas floating around about how the
alias protocol could be extended. Is it really going to stay that simple
for long? I would personally much just have a serialized response
upfront, rather than having to worry about backward compatibility in the
future.
On 12/19/2011 10:17 AM, slush wrote:
> In my opinion, there's not necessary any payload format (json, xml,
> multipart). In keeping stuff KISS, everything we need is just an address
> in response + potentially some stuff like HTTP redirects (for providing
> additional compatibility for proposal of bitcoin URIs with "amount",
> "label" and other parts). I don't see reason why we need some extra
> payload yet.