rich1.0npub1yex0huuw9mg3lksxwszh2q7v9rh52kfnprsjvg7wdlp202h2wlqsenmnxvhttps://nostr.ae/npub1yex0huuw9mg3lksxwszh2q7v9rh52kfnprsjvg7wdlp202h2wlqsenmnxvnjumphttps://nostr.ae📅 Original date posted:2015-01-19 📝 Original message:Hi Gavin, Mike and co Is there a strong driver behind the choice of Google Protocol Buffers for payment request encoding in BIP-0070? Performance doesn't feel that relevant when you think that: 1. Payment requests are not broadcast, this is a request / response flow, much more akin to a web request. 2. One would be cramming this data into a binary format just so you can then attach it to a no-so-binary format such as HTTP. Some great things about protocols/encodings such as HTTP/JSON/XML are: 1. They are human readable on-the-wire. No Wireshark plugin required, tcpdump or ngrep will do. 2. There are tons of great open source libraries and API for parsing / manipulating / generating. 3. It's really easy to hand-craft a test message for debugging. 4. The standards are much easier to read and write. They don't need to contain code like BIP-0070 currently does and they can contain examples, which BIP70 does not. 5. They are thoroughly specified by independent standards bodies such as the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard. 6. They're a family ;-) Keen to hear your thoughts on this and very keen to watch the payment protocol grow regardless of encoding choice! My background is SIP / VoIP and I think that could be a fascinating use case for this protocol which I'm hoping to do some work on. Best, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/6edaa8fd/attachment.html>