{"type":"rich","version":"1.0","author_name":"npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwet","author_url":"https://nostr.ae/npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-01-19\n📝 Original message:Even if a compact binary encoding is a high priority, there are more \"standard\" choices than Google Protocol Buffers. For example, ASN.1 is a very rigorously defined standard that has been around for decades, and ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary encoding (BER/DER), given the schema. In practice, I'm mostly agnostic about what encoding is actually used in BIP70, and I wouldn't fault BIP70 for choosing Google Protocol Buffers, but the very existence of Protobuf perplexes me, as it apparently re-solves a problem that was solved 40 years ago by ASN.1. It's as though the engineers at Google weren't aware that ASN.1 existed.\n\n\nOn Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:\n\u003e Hi Gavin, Mike and co\n\u003e \n\u003e Is there a strong driver behind the choice of Google Protocol Buffers for\n\u003e payment request encoding in BIP-0070?\n\u003e \n\u003e Performance doesn't feel that relevant when you think that:\n\u003e 1. Payment requests are not broadcast, this is a request / response flow,\n\u003e much more akin to a web request.\n\u003e 2. One would be cramming this data into a binary format just so you can\n\u003e then attach it to a no-so-binary format such as HTTP.\n\u003e \n\u003e Some great things about protocols/encodings such as HTTP/JSON/XML are:\n\u003e 1. They are human readable on-the-wire. No Wireshark plugin required,\n\u003e tcpdump or ngrep will do.\n\u003e 2. There are tons of great open source libraries and API for parsing /\n\u003e manipulating / generating.\n\u003e 3. It's really easy to hand-craft a test message for debugging.\n\u003e 4. The standards are much easier to read and write. They don't need to\n\u003e contain code like BIP-0070 currently does and they can contain examples,\n\u003e which BIP70 does not.\n\u003e 5. They are thoroughly specified by independent standards bodies such as\n\u003e the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.\n\u003e 6. They're a family ;-)\n\u003e \n\u003e Keen to hear your thoughts on this and very keen to watch the payment\n\u003e protocol grow regardless of encoding choice! My background is SIP / VoIP\n\u003e and I think that could be a fascinating use case for this protocol which\n\u003e I'm hoping to do some work on.\n\u003e \n\u003e Best,\n\u003e Richard"}