pull down to refresh
150 sats \ 8 replies \ @k00b 11 Aug
Whenever I hear and agree with experienced protocol designers criticizing naive protocol designs, it helps to remind myself that Javascript is the most popular programming language. Thus, if a protocol is popular, the only criticisms I find valid are ones that speak to a protocol's limitations rather than its imperfections. Most things that make something popular impart survivable imperfections. But if they have design flaws that limits popularity/possibilities, then you have something worth getting upset about.
reply
150 sats \ 7 replies \ @optimism 11 Aug
Are these limitations or imperfections?
reply
150 sats \ 1 reply \ @WeAreAllSatoshi 11 Aug
Sounds like imperfections that can be addressed over time to me
reply
50 sats \ 0 replies \ @carter OP 11 Aug
Yeah none of it is horrible but they typing stuff I think is probably important
reply
150 sats \ 3 replies \ @k00b 11 Aug
I'd classify dangerous/inefficient things, especially when they're mostly experienced at the margins, as imperfections.
The best example I can think of for a limitation is something like a text-based wire format (like JSON) used in a context where more binary data (by volume) needs to be transported. The inefficiency here is beyond marginal imo and burdens both sides of the transport.
Put another way, these MCP issues are mostly a burden to the few providers that exist (relative to consumers) and can be solved by providers throwing more money at the problem. Naive consumers will just not cache, retry like hell, etc. In the JSON example, consumers (and providers) will need to support an orthogonal binary wire format which is beyond imperfect imo.
reply
222 sats \ 2 replies \ @optimism 12 Aug
Hmm.. JSON is an encoding standard, like asn.1's encoding variants BER/DER/PER, or nastier things like XML. A protocol could specify an encoding standard, but it doesn't have to. This is the one thing that MCP does.
What is much more important is that the protocol solves domain-specific issues. No errors, no single-shot guarantee, no rollback... all this needs to be re-engineered in. And the result will be a spaghetti spec (which it kind of is already.. it's hard to actually make sense of the docs because it is oddly structured.) Spaghetti specs, like modern websites-over-http for which you need mozilla's security checker to check your live site (or CI) is an awful manufacturing pattern. And since many people are of the belief that all code will be done by LLMs, coding is manufacturing now.
Therefore I'm with the author:
But this is not something that MCP will solve. Maybe MCP's replacement in a few months will. I don't read this as a complaint, but as great advice for whatever comes next. Hopefully without throwing insane amounts of money at it: I'd rather have everyone throw some non-yolo, non-artificial brainpower at it instead.
reply
100 sats \ 1 reply \ @k00b 12 Aug
We don’t disagree about better specs being better or MCP having flaws (I haven’t looked very closely but it’s safe to assume it has many). Protocol economies just seem to have a mind of their own and produce spaghetti specs more often than not, so I see wanting a different spec (after one is widely adopted) like wanting an exception.
That’s a fair reading. Complaint was a poor word choice. The author seemed frustrated was what I meant.
reply
100 sats \ 0 replies \ @optimism 12 Aug
I don't think you said complaint - I was just trying to put it in perspective, so it's my poor choice of words haha.
In the end, I've been on protocol design teams, lead them, and in an unfortunate situation been the whole team by myself. But I haven't jumped in to help. So ultimately the blame is on me, and every other experienced protocol designer that didn't help with me.
reply
0 sats \ 0 replies \ @justin_shocknet 12 Aug
I think this just illustrates it's a bad comparison, more useful to view MCP as a documentation format vs. an interface.
reply