3 ms·

The authors explicitly compare saltpack and PGP, and all of you questions get answered when you think about it as "better PGP", an encryption designed to be use

by theamk 10y ago

The authors explicitly compare saltpack and PGP, and all of you questions get answered when you think about it as "better PGP", an encryption designed to be used with email, generic online messengers, forums and so on: > Not totally sure what BaseX is, how it compares versus Base64, especially post HTTP deflate compressions, but I'm not sure I like it. BaseX is "armor" -- a way to insert binary data into the text-only media such as email messages and forum posts. It seems to be way more convenient, as it uses no punctuation and is whitespace-insensetive. For example, I have once tries to send PGP message via gmail web interface and it took me two or three tries to figure out how to properly paste the text without gmail inserting extra whitespace and making the message undecodeable. BaseX should not have such problems. It is slightly less efficient that base64, including under compression, but I think it is worth it. > I'm pretty sure this kind of exercise is better left out, and that everyone should just use zstd on whatever encoding so as to decouple problem domains. Are you talking about zstd as in "Zstandard - Fast real-time compression algorithm"? This has nothing to do with this proposal, there is no compression anywhere in there. > Round two of skepticism: msgpack is a niche player with no clear big corporate sponsor. Protobufs, flatbufs, and thrift are all actively making faster better quicker implementations, but I can not off the top of my head think of any major msgpack lovers. Avro also seems to just generally have some fast impls already, especially on platforms I care about[1], so credit there too. The deserialization speed does not really matter. All saltpack messages are encrypted, and your decryption time will dominate your deserialization time. > I ought review, but out of hand I can't think of anything distinguishing about msgpack. Well, msgpack is in a completely different group from Protobufs/flatbufs/and thrift. The former is a protocol, which is implemented by a number of libraries, while the latter is a specific library, available from a single vendor only. As a result, msgpack has fewer features (no schema support at all), but is not bound to a single large corporation. IMHO, a right choice for global communication protocol. > Definitely nice having some alternative to Salmon protocol[2] (as in Buzz, OStatus) on hand. Wait, what? Salmon is about blogs on the web, HTTP posts, XML schemas embedded in HTML. The encryption is only a small part of it. Saltpack is about encryption email/chat/messaging, has no specification of payload format, and designed to work without HTTP using efficient formats. I see very few common things between two protocols. > Alas I believe it's again fully encapsulating, versus say http signatures[3], where the signature is decoupled from the payload. It takes both types!! Neither is right. Well, the big difference is that http signatures have no encryption while saltpack has it. So just two very different goals that they want to achieve.

rektide 10y ago
I'm basically obligated to reply to a long long list of mudslinging and disfavorment on your part here- section by section: 1. You randomly talk about BaseX ad nauseum but brely mention what I was actually critical of- it's advantages vs base64. I still have no clean picture why not base64, like everyone else, which would serve the exact same needs. 2. You just finish talking about compression then slam me for mentioning compression as a relevant factor. 3. You criticize deser speed as not important, say decryption will dominate. But while the message format may be competing with PGP it's inner payload is msgpack and I expect inside the firewall systems to have canonical text as msgpack, and performance is relevant. But I didn't initially grok that msgpack is the inner payload, that the BaseX text is the normal messaging format. 4. You try to pull some technical distinction nonsense about msgpack being just a messaging format by talking about how competitors also have other stuff too, while also being a message format. I find this distinction in bad faith and believe most techs could reasonably see there is way more overlap than differences. Your advantage ends up rather accurately being "msgpcka has fewer features" and chalk up the advantage as some nebulous political one, while ignoring the fact that Thrift is owned by the most reliable open source org on the planet Apache whereas Msgpack is just some rando project. 5. You obviously don't know what Salmon is for. Your decision to focus on some apparently unrelated technical things that it corresponds with ignores that it is a (XML)signing format for arbitrary content. HTTP and HTML have no bearing on what Salmon Digital Signing Protocol is, yet you harp on them to draw a false contrast, and as usual you refuse to acknowledge that there could be some bearing or relationship that I had validly called out. I'd like to better understand some of your valid points, but some of your arguments seem done in very bad faith and there to argue rather than explain or demonstrate. I have a hard time understanding how I can start to reconcile our two point of views with what you have written.

by theamk 10y ago

rektide 10y ago

I'm basically obligated to reply to a long long list of mudslinging and disfavorment on your part here- section by section: 1. You randomly talk about BaseX ad nauseum but brely mention what I was actually critical of- it's advantages vs base64. I still have no clean picture why not base64, like everyone else, which would serve the exact same needs. 2. You just finish talking about compression then slam me for mentioning compression as a relevant factor. 3. You criticize deser speed as not important, say decryption will dominate. But while the message format may be competing with PGP it's inner payload is msgpack and I expect inside the firewall systems to have canonical text as msgpack, and performance is relevant. But I didn't initially grok that msgpack is the inner payload, that the BaseX text is the normal messaging format. 4. You try to pull some technical distinction nonsense about msgpack being just a messaging format by talking about how competitors also have other stuff too, while also being a message format. I find this distinction in bad faith and believe most techs could reasonably see there is way more overlap than differences. Your advantage ends up rather accurately being "msgpcka has fewer features" and chalk up the advantage as some nebulous political one, while ignoring the fact that Thrift is owned by the most reliable open source org on the planet Apache whereas Msgpack is just some rando project. 5. You obviously don't know what Salmon is for. Your decision to focus on some apparently unrelated technical things that it corresponds with ignores that it is a (XML)signing format for arbitrary content. HTTP and HTML have no bearing on what Salmon Digital Signing Protocol is, yet you harp on them to draw a false contrast, and as usual you refuse to acknowledge that there could be some bearing or relationship that I had validly called out. I'd like to better understand some of your valid points, but some of your arguments seem done in very bad faith and there to argue rather than explain or demonstrate. I have a hard time understanding how I can start to reconcile our two point of views with what you have written.