📅 Original date posted:2015-01-19
📝 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.
On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
> 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
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:28:38
in reply to nevent1q…32er
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:28:38Event JSON
{
"id": "5ffefe4f1a3466b94442a5e0ab81e8c3456b62abc65f24ce54011239031ae43b",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151718,
"kind": 1,
"tags": [
[
"e",
"e1f7de9a3cc96853dcc43455df7f54523449e553ee4cde336d6870fe0e40792d",
"",
"root"
],
[
"e",
"da8c1756b1c7e027459ef01f3c0771cfc438db3932308a9cf3bfb574c5cae264",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 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",
"sig": "600f8c4dcda3d60376c55cbba920758d8d8a06b4a6216b05e825703f1a6de1f8481fd396b3c4ce6a08a9392bba8a870201fe6c65fdc27a19cc60e4845deb96e0"
}