{"type":"rich","version":"1.0","author_name":"npub1yex0huuw9mg3lksxwszh2q7v9rh52kfnprsjvg7wdlp202h2wlqsenmnxv","author_url":"https://nostr.ae/npub1yex0huuw9mg3lksxwszh2q7v9rh52kfnprsjvg7wdlp202h2wlqsenmnxv","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-01-19\n📝 Original message:Hi Gavin, Mike and co\n\nIs there a strong driver behind the choice of Google Protocol Buffers for\npayment request encoding in BIP-0070?\n\nPerformance doesn't feel that relevant when you think that:\n1. Payment requests are not broadcast, this is a request / response flow,\nmuch more akin to a web request.\n2. One would be cramming this data into a binary format just so you can\nthen attach it to a no-so-binary format such as HTTP.\n\nSome great things about protocols/encodings such as HTTP/JSON/XML are:\n1. They are human readable on-the-wire. No Wireshark plugin required,\ntcpdump or ngrep will do.\n2. There are tons of great open source libraries and API for parsing /\nmanipulating / generating.\n3. It's really easy to hand-craft a test message for debugging.\n4. The standards are much easier to read and write. They don't need to\ncontain code like BIP-0070 currently does and they can contain examples,\nwhich BIP70 does not.\n5. They are thoroughly specified by independent standards bodies such as\nthe IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.\n6. They're a family ;-)\n\nKeen to hear your thoughts on this and very keen to watch the payment\nprotocol grow regardless of encoding choice! My background is SIP / VoIP\nand I think that could be a fascinating use case for this protocol which\nI'm hoping to do some work on.\n\nBest,\nRichard\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/6edaa8fd/attachment.html\u003e"}