💾 Archived View for rawtext.club › ~sloum › geminilist › 006923.gmi captured on 2024-03-21 at 16:10:57. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Rohan Kumar seirdy at seirdy.one
Thu Jul 15 21:34:48 BST 2021
- - - - - - - - - - - - - - - - - - -
I put a TLDR at the bottom of this giant wall of text.
On Thu, Jul 15, 2021 at 05:34:29PM +0530, Arun Isaac wrote:
--8<---------------cut here---------------start------------->8---
The embodied energy of the memory chip alone already exceeds the energy
consumption of a laptop during its life expectancy of 3 years
--8<---------------cut here---------------end--------------->8---
Agreed. If you're running a datacenter or homelab, then the footprint of continued uptime could catch up to the manufacturing footprint quite easily; however, I think we should move away from the "scale everything to massive machines" approach in favor of simple software that can run on a near-vintage computer or highly-constrained environment.
Implementation authors can be liberal in deciding what computers to support/not support. When deciding what computers to support on a *platform*, however, we should be more conservative. We should define what computers to consider "vintage" and try to make it possible for non-vintage computers to participate.
It's time to write what will definitely become a {web,gem}log post at some point. Oh boy.
I loosely define a vintage computer to be any computer whose *hardware* prevents it from being useful today for a hypothetical user whose use-case hasn't changed since the computer was new, but wants to compute according to current standards. Such a user might have used Gopher and unencrypted IRC in 1996. Today, encryption in-transit has become an expectation for many reasons; this user might now use Gopher-TLS, Gemini, IRC with TLS, or a basic web browser for viewing Web 1.0 sites with HTTPS. Notice that I haven't mentioned any particular software implementation by name; I'm only mentioning implementation-neutral platforms and protocols.
Computers from the start of the millennium and earlier can't effectively leverage secure cipher suites supported by most TLS implementations. They're slow, lack SSE2, etc. Users who expect to be able to communicate over the Internet might find themselves unable to use current protocols (https+tlsv1.2, gemini) even if they only want to view very lightweight pages.
These vintage computers still have their uses, but they're better relegated to domain-specific applications (distraction-free writing, dumb terminal for another computer on the local network, etc) than general-purpose computing, or they can be used in conjunction with a non-vintage computer (e.g. a proxy that encrypts/decrypts traffic for TLS).
Another example: a user in 1999 might have hosted pages for others to access over the Web on an old personal computer from their home. Today, to do the *exact same thing*, this user might need a beefier computer due to the prevalence of bots, crawlers, and a greater number of users. A server that was just able to handle the load in 1999 might now be considered a vintage server. This user might consider buying a more powerful computer, such as a Raspberry Pi.
( Aside: project of note to bring a subset of modern TLS to the Internet of Old Things: https://github.com/classilla/cryanc )
Gemini's primary use-case is viewing hyperlinked documents over the Internet. Today, use-case comes with default expectations, like encryption, for a baseline level of privacy and authenticity. Two conclusions follow:
1. Some computers are now considered "vintage" in the context of the use-case "viewing hyperlinked documents over the Internet" because they'll be painfully slow when handling modern crypto.
2. Gemini must support transit-level encryption to properly meet its stated use-case today.
This means that Gemini probably doesn't need to address computers whose hardware prevents the usage of secure TLS. This does NOT mean that Gemini needs to ignore all 32-bit computers; plenty of 32-bit machines can handle TLSv1.2 (with strong cipher-suites) and TLSv1.3 just fine.
- I haven't researched attempts to use modern crypto on old computers very thoroughly; I kind of guessed that Pentium 4 with SSE2 should be the "cutoff point" for modern crypto.- I might want to pick a word besides "vintage" when describing computers that can't meet the same use-case after requirements change; something that specifically refers to a piece of a technology that isn't necessarily old (it doesn't have to be old) or obsolete (too broad) but is just unable to adapt to a use-case being "updated" to address current requirements as security holes and bad actors pile up.
If you're making an implementation, feel free to be as portable or non-portable as you want. When deciding norms, *recommended* implementations, and inherent platform limitations: conservatively evaluate what computers cannot handle your desired use-case and try to make sure all other computers are included to the best of your ability. Don't "expire" computers unnecessarily.
-- /Seirdy (seirdy.one)-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 898 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210715/625d4874/attachment.sig>