💾 Archived View for thrig.me › blog › 2023 › 06 › 03 › jevons-protocol.gmi captured on 2024-08-18 at 17:55:43. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-14)

-=-=-=-=-=-=-

Jevons Protocol

Improved protocol efficiency can be a negative: if the pipe is "too cheap to meter" that means the pipe can be filled with too much stuff, something that was impossible before technological change lifted some pipe-bearing boats. The modem wasn't very good in the 90s after it had been raining, for example, and not very quick at getting articles from usenet. Something even less efficient might have been better--provided that large media (books, OS installs) could be obtained in some other way. On the other hand, mobile data caps might make uncompressed content problematic, so there are trade-offs here.

Ruin from improved efficiency might fall under "Jevons paradox", originally applied to coal, where they improved the efficiency, the cost fell, demand went up, and thus The Great Smog of London. Whoops, externalities. A similar effect might be observed in the size of web pages: fast computers, big bandwidth, and now the pages often are choked with useless crap. Because they can be! And someone probably wants to keep those ad and engagement numbers up, and isn't being paid to put the pages on a diet. Besides forest monks and lesser eccentrics (hi!) most consumers want a big pipe and a fast computer for videos and games—the demand is there.

So you're got efficient protocols that paradoxically can be crudified, or inefficient protocols that may not work on some networks, or anyways use too much energy. There are also efficient protocols that tend to be used for, uh, let's call it file sharing. This makes those protocols problematic for other uses. The RFC can be had via rsync, but that's very niche, and rsync probably isn't portable to mobile, and may not make for the best of interfaces without a file explorer or search engine of some sort. There's more to protocols than just efficiency.

Energy costs can be tricky to calculate; HTTP might be more efficient, but not if there's too much stuff on a page versus a bit of gemtext. "Protocol" is perhaps too specific; the overall energy use of the system is important, not just how well the data tubes itself—how much additional work must the client do? How big a serverfarm is required on the other end? Do the content editors peg multiple CPU cores? How can Jevons paradox be mitigated? Can we do more with less? Or, even more popular, less with less?

One million cancel broadband as living costs rise - BBC News

Efficient protocols may assist with centralization, though the link between an efficient road (such as found in the Achaemenid or Roman empires) and an efficient protocol probably needs more study; the correspondence may not be there.

https://acoup.blog/2023/06/02/collections-roman-roads/

Inefficient Protocol Design

Tired of stupid meetings and endless standups? Try this protocol for a change!

Management will write the daily tasks onto individual pieces of paper. The papers will be folded into airplanes, and launched around the meeting room to general if not universal hilarity—recall Dale Cox vs. the Cleveland Browns. Once the tasks have thus been assigned, the workers can go about doing them.

Is this inefficient? Yes! Is this a Ritual? Yes! Would there be horsetrading afterwards? Yes! Is it a waste of paper? Yes! Will corporations adopt this protocol? No.

Towards Different Protocols

More likely one will see hybrid protocols that try to balance a variety of concerns. The problem here is there is only so much blanket for the bed; modern security requirements will exclude lots of older and still otherwise viable hardware. A protocol that is too complicated limits alternative implementations and portability. Too efficient a protocol can run into Jevons paradox, and one too inefficient will not be used, unless you can con someone into using it, as humans often get into Dutch Tulips.

Examples of hybridism can be found in the food industry—sure, industrial food is cheap and scales well, but the food may not taste like anything (flavor is often orthogonal to storing well and looking good on a shelf), might be designed to be optimally addicting (just like social media is), and may not actually be very healthy (again, social media). On the other hand, slow food is too labour intensive for many, especially when both spouses must work—who has time to rotate the sourdough starter in addition to everything else? Therefore one may see hybrid approaches where the best of the industrial and the traditional are wed: fermentation, but accelerated to save on time and space. Or maybe sourdough as a service, partially baked breads, etc. There's probably lots of room for small business here.

So for new internet protocols one might combine some aspects of the big industrial protocols, while excluding or mitigating the worst. The result will doubtless not be an optimally efficient protocol, as there will be other concerns at play: ease of implementation, portability to smaller or older systems, limiting dark patterns, etc. Ideally some of that would be handled by regulations, given that protocol design may not be the best place to solve social problems, but one might suspect that meaningful regulation will be absent or in the pocket of those pushing the dark patterns, and therefore the blanket will have to make do as best it can.

xkcd://927