📅 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>;
Richard Brady [ARCHIVE] /
npub1ye…nmnxv
2023-06-07 15:28:35
in reply to nevent1q…6knr
Author Public Key
npub1yex0huuw9mg3lksxwszh2q7v9rh52kfnprsjvg7wdlp202h2wlqsenmnxvSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:28:35Event JSON
{
"id": "b05a61cb6766bb733e0b62ea94d5bfa711ef8f3e5c2347c6283cb244b7a96202",
"pubkey": "264cfbf38e2ed11fda0674057503cc28ef45593308e12623ce6fc2a7aaea77c1",
"created_at": 1686151715,
"kind": 1,
"tags": [
[
"e",
"e1f7de9a3cc96853dcc43455df7f54523449e553ee4cde336d6870fe0e40792d",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 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",
"sig": "bae72f63752c0d73af51e8a817ca18c06a8021ebcd40ee0d638d728f0cd1b28edcce54a33603d7c299caa60be4bbf4e72d65e8e7ab67fa98ac07ace564d2c3ce"
}