Gemini's "uselessness" is its killer feature
alex.flounder.online
alex.flounder.online
Back in the day in the time of BBS with Fidonet or Usenet, I really liked the offline first mentality. With zmodem you had compressed and resumable downloads, with Echomail and Fidonet and POP3/Usenet you had offline first forums.
But the same FAQ says Gemini is also for those: "Interested in low-power computing and/or low-speed networks, either by choice or necessity"
This seems to be contradictory. Have compression, caching and resumable downloads omitted by default for the sake of simplicity or can it still be added to the protocol?
What's the rationale? A more formal seperation of simplicity of presentation and use within slow and frequently disconnected networks?
That if you for example want zstd compression you can use a VPN? Or that if you want resumable downloads or caching you can use a local proxy?
With the right proxy or browser one could emulate Gemini experience with the regular www, similar to using the old Opera Mini or force Reader View, block all images, javascript and ads on all sites. Wouldn't that be 'better'?
One of the side effects of ActivityPub is to standardize a "post new content" endpoint that might be used by offline-first clients with intermittent connectivity. This is in addition to getting content via ActivityStreams format, which can be implemented very easily, even by a cheap, statically-hosted site with no reliance on JS webtech.
(An ActivityPub-NNTP interconnect sounds like something that public-inbox really should support, now that I think about it.)
* caching is like alcohol: it is both the cause of and solution to all of life's problems
* nothing Gemini serves should be so large as to need resumable downloads or compression
In other words they seem like deliberate choices to prevent web-app-ification of Gemini.
A link should point to a hash. Now you can go get that hash from the same host you used to get the link or any other host that stores it anywhere in the world. That hash could unpack to data or to a list of other hashes. Go get those. Where you get them doesn't matter one bit. You can verify the correctness of the data trivially.
This is how BitTorrent works but it could work equally well on top of a simpler protocol.
Here's the bottom line:
The cryptographic content addressing I described sounds complex but is actually super simple and can be implemented in a page or two of code that will almost never need to change because it is "correct." It could be added to the gemini protocol in an afternoon.
Caching sounds simple but is horrifically complex and an endless source of bugs and failure modes.
I'd actually like this to be a separate protocol that's co-hosted with Gemini. It would make Gemini simpler, and it would enable other protocols to reuse content addressable storage.
Content hash distribution can also easily have privacy problems. Say there is a site for rubber band fetishists that you don't want people to know you've visited. I can interrogate if you've visited this site by embedding some of its content-- if you load it instantly because you have it cached, then I can be fairly confident that you've visited that site before.
The second can be mitigated but is a legitimate issue.
So Alice links to some content in Bob's site, but Bob made an embarrassing error and wants to update it. Very well, and Alice has to update the hash pointing to Bob's content: but now any hash pointing to Alice's content is stale, and so on, ad infinitum.
There are ways to solve this problem, but none of them force a linear forward history. Basically, you can request all Merkle chains featuring a base hash, and verify that Bob signed all of the branches, but only discipline can keep this collection in a linear order.
This is probably fine in practice, just follow the longest branch.
And now you have Secure Scuttlebutt!
You need a hash plus some "authorized mirrors list" or some other anti-poisoning measure. Not sure offhand how BitTorrent does it.
Re: malicious collisions, any modern hash algorithm currently in wide use, if "broken" by some kind of vulnerability, would cause far worse problems for the world than just some URN system breaking down. As such, literal man-millenia of cryptanalysis has gone into ensuring that there are no vulnerabilities in popular algorithms.
Re: accidental collisions, please note that 128 bits of entropy (i.e. a UUID) is already enough to ensure no accidental collisions before the heat-death of the universe. And most modern hashes have ≥256-bit residues.
A cryptographic hash like sha384 or blake2 makes it infeasible to come up with any input that would ever yield the same output. That’s what you would use for such a network.
UUIDv4s — the ones that are specified as being populated with 122 bits entropy from a HWRNG — cannot "be collided pretty easily." Those are what anyone clearly means if they're talking about "bits of entropy" in relation to UUIDs.
(Also, as it happens, UUIDv3s and UUIDv5s are specified as having their payload bits populated with the cryptographic hash of a user-defined input. But just to muddle your point further, the cryptographic hashing algorithms used in v3 and v5 are not ones that you'd trust today for collision-resistance; MD5 [v3] and SHA1 [v5] have both had at least one collision attack successfully done against them.)
UUID's are not meant to be 'secret' or 'hard to guess', and implementations can not be relied on to take care in generating the right kind of random state to ensure they aren't predictable.
From the RFC: https://datatracker.ietf.org/doc/html/rfc4122
Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.For ultra low power computing (for solar power) with zstd or brotli decompression support in a gemini client it would for example be doable on a raspberry pico running fuzix driving an e-ink display with keyboard. https://liliputing.com/2021/05/picomputer-kit-turns-a-raspbe... https://learn.adafruit.com/adafruit-qt-py-2040 https://www.tomshardware.com/reviews/adafruit-qt-py-rp2040-r...
[1] https://www.practical-sailor.com/marine-electronics/a-second...
To be fair, full HTTP is ludicrously complicated on the server and almost nobody actually does or uses it. I don’t know of a single web app framework or library that properly and conveniently does all of content encodings, transfer encodings, content negotiation, caching, ranges, ETags, and so on; what’s worse, if you’re doing anything dynamic much of this is application-dependent and so I don’t really know how it should be done. The parsing (on both sides) also kind of sucks, if not as much as for 822. Gopher (on which Gemini is based) is almost laughably simple by comparison, you can do it manually in shell script and not feel like a dirty hack.
I do not understand why the Gemini people don’t do NNTP, though. The relative inaccessibility of Usenet in the modern world? Still, you don’t have to federate with it if you don’t want to, and the tech is quite nice, if somewhat difficult due to the inherent complexity of the problem.
By a “federated system” I mean that there is a relatively small number of independently operated first-class entities (servers, nodes) that are more permanently connected and host a large number of second-class entities (users, points) that are more intermittently connected and generally correspond to individuals. Internet mail, IRC, Jabber and Matrix are federated; Slack (centralized) and BitTorrent with DHT (peer-to-peer) are not. The Internet itself is complex enough that it probably doesn’t usefully fit into this classification.
In this sense Usenet and FidoNet are both federated store-and-forward mail systems. Or am I wrong?
One of the neat things about Gemini is how quickly and easily people started writing clients for it. Perhaps this illustrates how we can influence client design, e.g., limit complexity (and perhaps decrease insecurity), through protocol design.
I use a text-only browser to read HTML. I often make HTTP requests from the commmand-line using a variety of different TCP clients in order to utilise a feature of HTTP/1.1 called pipelining. I have been using the web this way for decades. Needless to say, "new" protocols like HTTP/2 and HTTP/3 come across as being 100% commercial in their vision of what the web is; they are designed to acommodate a web full of advertising. Their sponsors justify them based on problems that one might encounter when trying to use the web for commerce. However, they fail to account for non-commercial uses. For example, there's no "HOL blocking" problem when all the resoources are coming from the same server and the site operator is not trying to "build complex, interactive [graphical] web pages." There is an underlying bias with these protocols for enabling a commercial, advertising-filled web. As one would expect considering who is paying the salaries of their implementors.
Then we have something like QUIC whose sponsors similarly make justifcation arguments that assume every site's goals are "complex [graphical] web pages", likely to be supported through advertising. I have read articles arguing in favour of QUIC that suggest TCP never achieves its true potential for speed because we are only ever making large numbers of small TCP "connections". That usage pattern is indeed something we see with "complex, interactive [graphical] webpages".FN1 The kind that serve advertising. However, with HTTP/1.1 pipelining, as I use it, I have different goals. I make a single, longer-lived TCP connection and make 10s to 100s of HTTP requests to the same server. I am not using the web as an interactive, graphical interface. I am doing [text] records retrieval. I am using the web as an information source. Again, what I am seeing with these "next gen" protocols are an underlying bias and assumptions in favour of a commercial web filled with ads.
As such, I agree the "limitations" of Gemini which make it cool to some of us, i.e., it is inherently not advertising-friendly, could be achieved using HTTP either by
1. users choice of client, i.e., stop using graphical browsers that run Javascript, written by companies that rely on "surveillance capitalism" or
2. a new standard that websites could adopt whereby they (also) served content in non-advertising-friendly way.
#2 is outside the control of the user. It is squarely under the control of website operators and those with the power ($$) to influence website operators. Indeed, it can also be brought about through use of a proxy. I have also become a die-hard localhost-bound proxy user. It is seemingly limitless what a one can do with a good proxy, however it can quickly lead to some rather complex configurations and much of the results can alternatively be achieved by #1, simply using the "right" client. I use both #1 and #2 together.
1. Not sure that Gemini supports pipelining. If not, how does it allow for efficient, bulk text retrieval. Does it encourage short, successive TCP connections.
The mistake that the original lobster.rs "Gemini is useless" commenter made is that he assumed Gemini is meant to "replace" the web. Yet no one, certainly not the creator of the protocol, ever claimed anything of the sort. In fact, Gemini documentation explicitly disclaims this as a goal. The commenter has constructed a strawman. He also assumed the only worthwhile use for an internet is a web, and the only worthwhile use for a web is to engage in commerce. To me, that looks like myopia. The internet has historically been multi-use, as the parent comment describes. The "www" is but one use. Alas, it has been co-opted by those seeking to use it as an advertising vector.
If Gemini documents could support static HTML and CSS (i.e. without anything like SCRIPT elements or cookies), it would be more useful to the people who it is intended to benefit - you could port Wikipedia or distribute journal articles - without being a tracker haven. I don't hate the modern web because I can read the results of a scientific study that mentions its statistics in tabular form. I hate the modern web because the first thing I have to do is sign away my right to be treated like a customer in business, a curious child in a library or a guest at a friends house, and instead must agree to involuntarily yield wealth for the company.
Gemini's different protocol isn't important for technical reasons. Its important for social reasons - to make it effortful to move content to gemini, and effortful for users to start using it. The result is that all the content and users on gemini are people who have done work to opted in to it. And the space populated by small community like that will necessarily end up different from the culture on the web. (If they were happy with the web, they would have stayed there.)
But they have stayed there. Gemini users still use the modern web all the time, mostly to remind everyone that they exist and are rejecting the modern web so hard you guys.
Gemini is no different. There's overlap with the web's use cases, but its its own thing. As a user, why not both?
What does Gemini have to offer to web users that the web itself doesn't? It's entirely possible to write small, simple HTML documents without javascript on the web. Indeed, one could replace Gemini entirely with a Geocities-like service that enforced the same rules, including only allowing linking within the platform.
Alongside the web, Gemini is just a worse version of the web, it isn't different enough to be its own thing, nor does it offer anything unique. Gemini only makes sense as a means of forging a separate identity from and exclusionary of the web, as you yourself said in the original comment I replied to[0]: (If they were happy with the web, they would have stayed there.)
You could e.g. color the links to other participating sites to highlight them (and still have the option to link to a conventional bloated website).
The web is like a badly architected government such that most citizens are unaware of the badness. The collective you describe is like a group who use their own awareness of the badness to improve the country, but that does raise awareness of the government's badness whereas starting fresh by founding a new country does.
Actually, the analogy I just gave is a little too harsh on the web. A more charitable description is that a subset of the web's users is poorly served by the architecture of the web, but most of that subset is unaware of that fact (what with not being experts on the effects of subtle technical decisions on something as vast, open and complex as the internet).
I am not defending Gemini in particular; I use it but have yet to form an opinion of it; I am defending the strategy of founding a new internet service to compete (for the time and attention of users) with the web.
I don't buy this argument.
Even if "he/she ascribes the good experience (...) to the web":
(a) the subset of users that could fell into one of the "participating sites" would be much larger than the subset of users that would install something like Gemini. The subset is open with no barrier at all to every web user. They just need to visit a page. The second subset requires them to have heard about Gemini, to care enough about it, and to actively download a client.
(b) For this reason, even the subset of (a) that could tell "Ahh, this site is fast and nice because it's simple web code" would be much larger than the subset that would install something like Gemini.
(c) If the subset that recognizes the benefits from the simple web design designs to join the movement, they just need to code simple html and deliver to everybody (an easy sell, no new tools needed). For the subset that discovered and likes Gemini, they'd need to find a host and install a Gemini server (much fewer options, no turnkey-host that supports it, unknown code quantity/quality), and then their potential audience is severely limited to Gemini client users (a much harder sell).
(The main problem with using the web to publish plain-text writings is that unless the person doing the publishing is an expert on the technology, in which case he will use something like Github Pages, there is no cheap way to publish a few paragraphs or a few dozens of paragraphs where it fill find a decently-sized audience without enriching some intermediary and subjecting most of the people who over the years will read the writings to either advertising or paywalls.)
I offer no criticism of the web as a way to buy things online or to apply for a passport online or such.
I am avoiding saying that the web is bad: the web might be bad only for a small fraction of web users. I don't know enough about how web users differ from each other to say how large the fraction is. I do know enough about software and how site owners will respond to incentives to be able to tell that the web is bad for users sufficiently like me. Well, I'm fairly certain, too, that the web is severely sub-optimal for blind users (and I wonder if attempts have been made yet to tell blind users about Gemini and to make it easy for blind users to get started with Gemini).
Someone could write a whole book about how seemingly insignificant decisions in the design of something like a web browser (e.g., decisions in the design of web standards) can have profound effects, but I think in this case it is better to show than to tell.
Improving Gemini might eventually show a lot of people that the web is a sub-optimal solution for some of their needs. Note that Gemini need not completely replace the web in a user's life: one session with the improved Gemini might get the point across to a new user (and the user might do nothing but browse Wikipedia during that session).
In contrast, the strategy I originally replied to, namely, a collective of web sites, might significantly improve the experience of many web users, but will cause approximately zero web-tech non-experts to become dissatisfied with the web.
I have no road map for how a large numbers of people dissatisfied with how the web serves some of their needs will eventually find their way to something better. I figure it will take many years. I do believe that increasing the numbers of dissatisfied users is probably a necessary first step.
=> https://gemini.circumlunar.space/docs/faq.gmi
> 2.5 Why not just use a subset of HTTP and HTML?
> Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites can track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they have to. Why not just build non-evil websites using the existing technology?
> Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done.
> The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
> Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they can't. You can do all this with a client you wrote yourself, so you know you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
> But you can serve HTML pages over Gemini either way.
The important question is what people can read over Gemini, I guess. Do Gemini clients effectively render that? I imagine it would be difficult to take Webkit and make it work without supporting JS.
Might as well ask "what good is competing webservers".
If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
Also, if this[1] is your HTML parser, it doesn’t look like an actual HTML parser with implicit tags and error correction, just a parser for some easy subset of HTML. If we’re not going to be web-compatible anyway, why not spec a language that’s actually good?
[1] https://github.com/s2607/webthing/blob/d6dd43aa5a3cc6dee15f8...
Gemini's selling point is that it's a narrow spec that's basically good for one thing: displaying largely unstructured text. It's not good for PDFs or layout, it's not good for media-heavy documents, it's not good for apps. You probably wouldn't write something like a book in Gemini. It knows exactly what it's doing, what kind of community it wants, and it focuses only on that use-case -- which is why its community likes it.
But how many different implementations do you need to build for this kind of narrow project? Are we really expecting that 50 different hobbyists are going to build custom Gemini parsers? Why? I'm not sure I understand what reason there would be for that kind of implementation diversity with a spec that is deliberately designed to decrease application diversity.
On the web, we have a lot of reasons why we are scared of having only one browser rendering engine. But most of those reasons don't seem to apply to Gemini, because it has different goals from the web. So say there was one zero-dependency C/WASM binary for parsing that was compiled for every platform and could be imported or transpiled into other languages for use in your custom browser/app. What do you feel would be missing from Gemini in that world?
Plus, being able to implement something from the ground up in not much time means it’s possible to explore foundational advances, like building the entire client/server in a memory-safe language.
I think it seems a little bit extreme in some ways, because when we talk about Gemini's implementation being simple, the FAQ isn't just talking about structure/readability, it's saying 100-200 lines for a basic client. To me that crosses from 'should be auditable' into something else entirely -- I'm not sure why having a 1000 line client would make this significantly harder to audit, or build, or re-implement in Rust. I'm not sure Rust is that complicated of a language.
But :shrug:, I guess if you shoot for an extreme metric, then you know you'll end up with something that meets all of your other goals as well, so those requirements do make some sense to me when phrased as part an overall architectural stability/reliability goal.
Frankly, I don't think that it even makes any sense to convince anyone. There are people who like Gemini and for them it's good enough, the rest will never use it. Both camps have excellent arguments and I see no point of arguing here. It's like Vim vs Emacs wars in the old days, as if people couldn't use their $EDITOR of choice.
I would love be able to write a gem document where I can say this is a quote, this is an emph light text and this is an emph text, this is a table and this is a link and then it will be up to the client to choose how it wishes to display it, including just as text.
I prefer inline links strongly, but I require inline images and tables for it to have any value directly. It would be an obvious benefit to include support for inline math too, something that we still don't have on the web.
And no a link to a table or an image is not a replacement for an inline one (though it is an obvious fallback for terminal renders).
Such a format would be really nice to access information in, it would be easy to save/proxy for online access and it would still be possible to include ads (of the still image, non tracking variant).
I think the issue with Gemini is that it that while it appears to be a general purpose protocol, it actually favours a very particular type of content. This maybe seems self evident, but even if you want to write anything much more than a blog post it's not a good fit. I wouldn't mind if it was really pure, but a code block syntax has been included to appeal to a tech crowd, while other basic elements of modern written communication are not. And now we're back to the start of my comment.
Kinda like.. some folks like manual-transmission cars with simple constructions that they can modify. Or machine-code/assembly. Or building their own computer. Because then they're not just a user -- an outsider to those who've actually created the technology -- but rather a fellow creator and equal participant.
Projects like this give me the same vibe. This is, I'm skeptical that anyone's doing this because it's practical, even in its minimalism -- instead, it seems more like a hobbyist project where folks can feel included.
Gemini vs. HTTP ~ HN vs. Reddit
Inclusiveness via simplicity is just one axis in the space of why people like things.
That's neither here, nor there though. You can have 20,000 other individual Hacker News style sites on every subject, and the simplicity would still be there on each individual one.
Not every thing has to be everything to everybody, for the category of the thing to be inclusive.
And Gemini is not like content or like a speficifically-themed website like HN, it's a content delivery format (like HTTP/Gopher/etc). The allusion between Gemini to HN was for the simplicity of the presentation, wasn't referring to the kind of content HN carries.
In a site's with HN design the content could still be whatever, from whaling to development, and from rocket science to religious practices.
(If anything, something like Gemini would be much easier to make inclusive to e.g. low powered devices in the developing world, or screen readers, compared to the modern ultra dynamic news and content websites that have tons of moving parts, trackers, popups, interstitials, animations, and random JS just to deliver news and text content).
Not really. It may have been true ten years ago, but during that time Reddit has slowly accreted "features" (Reddit gifts, Reddit Premium, sponsored contents, a chat...) whereas HN didn't.
Also there are NO native media (video/GIF, images, photo albums) support & linked media previews on HN too.
Additionally users on HN has no any administration or moderation rights.
Now the next step is deciding wether you enjoy the precise control of the manual vs the liberating comfort of the automatic.
I d argue that a tiptronic like solution that does both is perfect and should be default in all cars. But then it s a matter of cost.
At least you're totally wrong thinking we buy manual because they're simple enough we can modify them :D We're 70M people where I come from, 95% of cars are manual, never ever heard this one.
Presumably we'll see the same thing with fully self-driving cars in the future. This is, a mature self-driving technology should eventually out-perform (unmodified) humans, but even then, when there's no argument for manual-driving's practicality, some folks'd probably want to drive manually anyway.
And 400M people with manual in Europe, where an equal share (95% or so) is manual. And 99% of the people seldom if ever "modify" or hot-rod their cars.
That's more of an American thing, in the country where they have the automatics as the first choice.
My observation is simple stuff is generally less wasteful and designed with different set of goals. The simple stuff I particularly like lasts a lifetime, its maintenance is minimal and doesn't lock you into a single ecosystem.
Since these items are used for much longer than their modern counterparts, they become yours more.
On the digital realm, simple stuff is less distracting, works faster, is not short on essential features and can do 95% of the more complicated stuff with minimal overhead.
At the end of the day, people may like simple stuff more because it does most of the work done by the complicated thing with much less mental load. Funnily, sometimes the simpler stuff actually does more than the complicated one.
Or, well, because:
(a) it's more resilient (and they already have lost tons of formats of the last 40 years that can only be read with emulators now)
(b) it's simpler
(c) it does what they want (document web) without bloat
(d) it's hella fast
(e) it's light on resources
So, it's not "kinda like some folks like manual-transmission cars", but more like "some folks like a toaster that it's not internet connected with 30 toast programs and 5 buttons", or to squeeze their own orange packs without a $400 Juicer [1], or they like the plain old Hacker News webpage and not some social media sharing monstrocity with 200 options, and prefer static file serving instead of a CMS+Database+...
Gemini might not be practical, but that's because the majority wont know about it, as it wont be pushed by companies, and thus it wont be adopted in any large numbers (heck, advertising wise, it's against the whole FAANG model).
I don't have any plans on hacking with it, but I was looking for something like Gopher-revived to cut back on web bloat, years before Gemini started. That said, I'd prefer if it could somehow be part of the web (not another server/protocol, but a forcefully cut-down web - maybe with something like a HTML's version of Javascript's "strict mode" - when that would be toggled, only a minimal set of HTML and no JS would be supported).
[1] https://www.bloomberg.com/news/features/2017-04-19/silicon-v...
In my case, I appreciate the environment it creates while reading. It is more like reading a book. The text is front and center, progression is mostly linear, and the visual transition between sites is less jarring. Minimalism is nice in the sense that it makes the experience more cohesive, rather than being an end in itself.
Let me give you my perspective: the modern web client experience is that of a sturdy, advanced alien spaceship. It gets you from A to B and knows how to dock to all the popular alien space station airlock models automatically (aka all the HTTP/2/3/TLS/cookies, stuff that's expected by sites to work). You chuck plenty of fuel at it (RAM and CPU) and cross your fingers that it lifts off.
If you prod the wrong part of the (browser) engine, the universal constants change and you get turned inside out. You still occasionally do it because the ship can be made to block all the alien ads once you're on the space station.
Gemini is just an old ICE car with an antigrav module bolted on (the TLS engine). Its construction is simple enough that you can hold it in your head. It doesn't change the universal constants when you prod the wrong part of the engine, so it's refreshingly free of the risk of turning inside out. It goes into space just fine, but doesn't know how to dock on the alien space stations. This is fine - you knew that from the start, and the new human space stations are where all the quirky fun stuff is happening anyway. And the human space stations have no ads, for now.
These are hard problems arguably.
For TLS, I agree it's a monstrosity, but it was an intentional protocol tradeoff. We really want to have privacy, so the only other way is to homebrew your crypto protocols (which is just as dangerous as homebrewing your crypto algorithms).
Since we're basically stuck with TLS, Gemini asks the question of how to make TLS make a run for its money - and this is by using TLS asymmetric crypto keys for persistent or semi-persistant identity handled by the client. The HTTP web still doesn't have single sign-on, but Gemini does. Just present the same key everywhere.
As for search, it's not like the HTTP web has a good discoverability story either. The only reason why we have search that can pull up any page based on any keyword is because we've spent decades selling our eyeballs to a company that indexed it all by sheer brute force. The Gemini web is arguably no different here - if someone wants to build a search engine, they are free to do so.
and the selling point is 'no tracking'? i must be missing something.
And could easily implement one-keypair-per-server based on user preference.
It's a pretty context free format: each line can be rendered separately, and the user agent can display things as they arrive (with some visual indication of "holes" for lost packets while they're being re-requested). A partial page may also be enough for the user to decide they want to move on, saving pointless delivery of the entire page.
Besides many Gemini pages fit in 1 or 2 packets, so there is more wastage through the TCP setup dance.
The monster is x.509 certificates.
Why am I going to use anything if I'm not trying to extract value? I don't mean in the sense of "make money off of lusers", I mean as in "do something that provides value for my effort".
I used gopher to "extract value" 25 years ago, but it turns out I want inline links and images and formatting and interaction (and compression and caching et al) because they're really useful. Look no further than HN for the Gemini ideal use-case, but even here the experience would be worse because of its restrictions.
Reading the spec, Gemini seems like it wants to be the elitist / hipster version of both gopher and HT(TP|ML). It forgets that a lot of user-agent features are pro-user, even if they've been co-opted for nefarious means. It's the CLI tech nerd's dream of a user interface, and discounts both the evolution of the web and of UI/UX design over the past 30 years.
Painting people with negative stereotypes simply because they seek something different from their online experience is uncalled for. Nothing compels people to use Gemini aside from their own personal interest. Its imprint upon the world is so minuscule that it is impossible to complain of incidental impacts. Simply put, it will not affect the lives of those who choose to ignore it. Contrast that to the web, which is virtually impossible to escape while remaining functional in the modern world.
And why paint it in terms of negatives? People tend to compare Gemini to a crippled version of the web simply because that's what most of the world uses, but is more accurate to claim it is a modernized version of Gopher. It simplifies linking to other documents. It is possible to reformat text for small screens. It adds a layer of security. These are all positives.
The fact that your primary answer is a tautology is telling.
I'm asking what value I should find from it, what value I get from going down this bespoke, inaccessible, poorly tooled path versus using the web with it's widely-used tools, billions of users and a million onramps?
> Nothing compels people to use Gemini aside from their own personal interest.
Nothing compels me to use it, but nothing incentivizes me to use it, either. I'd like a static site generator for my blog. Why would I pick Gemini over Jekyll, Hugo, etc.? That's the missing part of the story.
> And why paint it in terms of negatives? People tend to compare Gemini to a crippled version of the web simply because that's what most of the world uses, but is more accurate to claim it is a modernized version of Gopher.
People tend to compare Gemini to a crippled version of the web simply because that's what it is. All of your arguments on how it's better than Gopher ignore the fact that the web has all of those same features.
It's negative because the web already did that, it's already a modernized version of Gopher. That's why we use it and not Gopher. That battle was lost when either NCSA Mosaic or Netscape Navigator was released 20something years ago.
- I'm looking at something I just downloaded from the URL I entered or navigated to. If I'm really paranoid I can open it up in a text editor and not have to wade through tag soup and potiential Javascript obfuscation.
- Nothing is hiding from me anywhere, anything that was retrieved from the server is in the current document view.
- No scripting has modified the document.
- No scripting is listening to input device events and sending those to a server.
- If I tell my client to render stuff in a certain way, such as font preference, font size, how to deal with links, the Gemini document won't break.
- If the Gemini document is a big list or index of a bunch of things I want, such as pictures or other media, I can parse those links ridiculously easily with standard UNIX tools and download them when I want with a multitude of download managers. Trying to parse things like Twitter's direct image or video links is hard.
So if you want those things, Gemini is worth a learning curve, which isn't hard (download a client and start browsing).
(Author here)
What "value" is there to extract from a public park? Some things are just places meant to be appreciated and enjoyed, and lack a "practical" purpose.
If I take effort to go and visit a park then I get some kind of value from it. I get to relax in nature, see some pretty trees, have a space to play on a playground, etc. Those uses are evident even if I personally prefer concrete and steel, have pollen allergies or don't have kids.
This project sounds more like a single tree on a tiny island. You can go and sit under it, but you need to swim out to the island. It has no low branches, so you can't do anything except sit under it. It's scraggly, so it doesn't provide any shade, so sitting under it isn't very pleasant in the hot sun. Oh, and no boats are allowed on the lake, so you have to swim the half-mile each way.
It's the opposite of your story, the only possible reason someone could have in visiting the island is to log the tree, or just to say they've been there.
And my argument is more about the practicality. Why am I going to go from writing my blog about how fluffy alpacas are on the HT(TP|ML) web to writing it on Gemini? What do I get for my effort and for the restrictions that are now placed on my writing?
I could appreciate a text file on my local disk about as much as a gemtext page because nobody will see it. Network effects are really real.
Using Gemini is building an enormous mountain, and the only reason to climb it is "because it's there".
It's a tradeoff and I can't judge if gemini got it right, but gemini obviously still wants to be useful in similar aspects in which it wants to be useless enough.
I think that's the point. When you build a protocol so restrictive and ascetically minimalist that even HN and Lobste.rs, epicenters of the very sort of contrarian tech hipster anti-modernist elitism that brought it about mostly complain about it, it's clear that what you're really optimizing for isn't utility but ideological purity and cultural homogeneity.
Gemini exists to satisfy political and cultural, not technical, needs. Most of what Gemini users have to say regarding their preference for it, and its benefits and its purpose are almost entirely about culture, not technology - the web is too complex, the web is too mainstream, too commercial, no longer a small "quirky" community, too full of the wrong people using it the wrong way.
We're here replying to an article whose entire thesis is that Gemini's technical shortcomings, it's "uselessness," is a killer feature for promoting a specific kind of culture, for preventing certain forms of expression and encouraging others, inviting certain kinds of people in, and keeping other kinds of people out. That it will never be extended is a decision based on enforcing culture, in the belief that any extra complexity, regardless of its utility, risks the protocol being used in ways that undermine its ideological basis.
So yes, culture.
It was also an idyllic place in the beginning that got crowded, and giving we didn't figure it out the next step beyond capitalism the trash from our material world started to fill the digital realm because we are still in the same culture.
So to solve the problem Gemini is trying to solve, is not by fixing the web standards, but by fixing our culture, which is a much harder and bigger problem.
Gemini will want to keep working, than it will figure it out a way to sustain itself economically that in turn will make it possible to create profitable services on it, and it will be just a matter of time to become exactly as the web is now.
If it doesn't take that path, giving the Web is a superset of it and it doesn't provide a unique value on its own, it will probably fade away or keep very niche.
I felt like the web's "change" was when it became skewed towards high-bandwidth content like images and videos, more so than popularity alone.
I can't imagine Gemini becoming as popular, but if it does, another new protocol can grow. :)
> it will probably fade away or keep very niche
Sounds nice, actually.
You would need a critical mass to get an extended Gemini off the ground now. Between the die-hardness of the early adopter community that realises that this extensibility is why they needed Gemini in the first place, the support for HTML and Markdown mimetypes over the core protocol (to alleviate some pain points) and lack of commercial attention, I have high hopes for Gemini.
> it will figure it out a way to sustain itself economically
Why should it? It's not a platform for commerce. Hosting a Gemini server on a residential connection has a negligible cost (a Pi and a few kilowatt-hours per year). Some small web communities host it for free. For personal expression, Gemini should be very cheap.
Now in 2021 we have a lot of historical records of how things shaped and get in the way they are now. Everything that you are saying about the Gemini is exactly how the primary web was in the beginning and yet it changed because a lot of forces happened.
I completely agree that the Web now is a whale and its too fat (BTW this is the point that Gemini is getting right), but i don't agree with the approach at all, as its not possible to have a time machine and make the technological status-quo get back to were it was in the nineties so a project like Gemini can be a successful branch of WWW.
A "skinny web" standard would be much more useful, and here i think that Tim Berners Lee is missing the point by creating something like Solid instead.
Anyway, its a chance missed to point to something for the future, pointing to the past instead and making a lot of good folks lost by following the wrong way.
I consider Gemini part of the "retro technology movement", that while cool and while having its heart in the right place, miss a nice chance to help us all change a very dark future ahead of us of digital feudalism imposed by the big tech goliath monopoly.
We, the tech crowd need to step back and stop following them into that bleak future, Gemini is subversive in that sense, but while the goals are great, its alienatory nature negating the status-quo and forgetting to learn with historical events its not a step into the right direction.
But if at least take some people away from the WWDC's and Google IO's, at least it will be a little bit less people into this army that is leading us into this dystopic future we are heading right now.. and i just hoped that Gemini with a little more contextual knowledge could be at least a stone in their path.
Back when Gopher and HTTP were slinging it out, the future was unwritten. No matter which nascent vision of the Web we picked, it would be cool. 20+ years later, we ran the capability-maximalist (excuse the term) experiment to its logical conclusion, we know for a fact that a web in the HTTP/HTML spirit leads to a hellscape inhospitable to the privacy conscious.
In that sense, Gemini is not a nostalgic look. It's a recognition that we picked the wrong evolutionary branch and that we must step back and redo the evolution.
I don't think it can win against the Goliaths of Big Tech, but then I think that no-one will. It's a political problem with no technical solution, because ultimately it involves money. The only way to kill those Goliaths is to get the governments off their seats and get them to sling some stones.
Ultimately, I think that Gemini recognises that slaying Goliaths is not something it can accomplish. It refuses to play that game entirely, and instead focuses on carving out little chunks in the hellscape for those that seek them. It's not forgetting to learn from historical mistakes, it's simply abandoning the pretense that the HTTP web can be unseated.
That makes it way too complex and also breaks the ideal of a complete, unmoving spec since cyphers tend to change as weaknesses are found. It also requires certificate management with roots of trust, expiration dates, etc... You basically need libs, which is a problem on its own. TCP is also a bit of complexity but not as much, and it is not mandatory, unlike TLS.
And now, since uselessness is the topic. Or more precisely, that Gemini can't be polluted like the web because it is useless, don't you think mandating the lack of encryption would make it even more "useless".
I mean, really, why do people want https? Why do Google insist so much on https? The biggest reason is e-commerce. The secret you have that everyone wants to know is your credit card number, and more generally, everything that allows someone to make a transaction on your behalf. Really for most people, https protects the bank account.
So, if you think that the commercial web is the enemy, making a protocol that is unsuitable for commerce can be an idea.
I took the reasoning from the ham radio rule that bans encryption. Simply, it is a way to keep most commercial operations out and keep it an amateur thing.
As for multi-column layout - it's a work for the browser to do on the user demand. View should be decoupled from the content.
For cases when you want to control every aspect of how is the information displayed there is HTML.
Things like Gemini should not have formatting features besides those semantic which MarkDown has.
Some people (maybe they call themselves "purists") rage against this and kind of insist that gopher is all about text and only text.
To a certain extent they are right - gopher has traditionally been about text, but the designers of gopher didn't have this dogmatic obsession with text-only but actually wanted to do "VR", I e. a graphical 3D interface for gopher (complete with "flying" transitions between servers) as well as doing visual overlay over a globe etc showing where gopher servers were physically located. They had dreams of a much richer interface so I don't think we should artificially constrain ourselves.
The real modern benefit of gopher is the lack of pervasive scripting and cookies/tracking (and FYI modern gopher clients and servers support TLS)
Gemini supports RFC2046 mime types. So you can serve using their own text/gemini, text/markdown, text/html, and so on. You can go ahead and serve images and video, too.
It's up to the client to support the mime type, but a lot of clients have pretty wide-ranging support (a few actually are re-using a web browser engine, so have full support for a lot of formats). (And markdown will fallback to plain text when unsupported, which is what it is defined for, so would be fine).
Isn't Gemeni can be simplified to a convention that forbid CSS/JavaScript and allow only basic tags of HTML (<h1-6>, <p>, <a>, etc..)?
IMO this could be a better move because this will use any performances improvement made on modern web stack (cache, compression, etc..).
The complaint was that Gemini lacks basic utility. Intentionally making things that lack utility is a great way to express an idea, but to me that’s an art form or a statement, not a tool.
Gemini is a communication tool. While it’s noble to make something that is difficult to extract value from, a tool has to serve a purpose. The complaints, to me, feel legitimate critiques for a communication tool.
Whenever I venture into the Gemini-verse, I feel like I’m peeking into personal diaries left out at random. I am not a person to shy away from a good search for interesting information. But on Gemini, I don’t see a point in digging. That makes me feel like it’s still lacking as a communication tool.
(Author here) I would definitely view Gemini more along those lines. Gemini is an interesting space to inhabit and explore -- a space dramatically different than the modern web due to its design. That's the value in it for me!
When I think of a minimal website, I think of danluu.com. But even danluu occasionally uses tables and images. https://danluu.com/cli-complexity/ https://danluu.com/branch-prediction/ . I think these articles would be made worse if these features were removed. I suppose they could be replaced with carefully formatted code blocks, but these would be harder for danluu to make, and would look worse to the reader. Consider the dictum from motherfuckingwebsite.com: "shit works on all devices"; codeblocks work very poorly across devices.
I think claiming that gemini is intentionally useless is a bad excuse. Gemini includes some features, but doesn't include others. There needs to be better reasoning behind the fetures it excludes.
Gemini is a social space as well as a protocol. Part of why it's got such a sharp break with HTTP than e.g. being a subset of HTTP with a special client, is to demarcate such a space for those who want it. Minimal websites still operate within the larger context of the HTTP web, where this demarcation doesn't exist. Click a link to a Facebook profile from that small blog and you've unwittingly chosen to load half a megabyte of markup and tracking scripts. This is not possible with Gemini because such a capability simply is outside the protocol.
> But even danluu occasionally uses tables and images. https://danluu.com/cli-complexity/ https://danluu.com/branch-prediction/ . I think these articles would be made worse if these features were removed.
I agree that this could be annoying. Gemini has support for alternate mimetypes, so it's possible to return Markdown to the client. I think that Markdown is still in the spirit of Gemini's minimalism, but it does support more things (including tables). If a particular client refuses to render markdown, it's still readable as plaintext.
It seems to me that the discussion here is just rehashing all the discussion on the Gemini mailing list from the past few years.
Images seem to do something to the human brain. They grab attention in ways text does not as evidenced by the fact that a dumb image meme can be used as an anchor point to advance the most inane bullshit in either meme or short-attention-span text form.
Image boards and their capacity to originate and amplify utterly inane bullshit are the canonical case, and the format illustrates the principle exactly. Each post consists of an attention grabbing catchy image along with text that is usually one or more of banal, mean spirited, or irrational, and the image meme sells the message to the point that these sites almost feel like cults. Take the images away and there is virtually nothing compelling there.
Edit: there was interesting stuff on the chans once. 4chan was not always identical to /pol. The fact that /pol, originally a containment board, became 4chan and edged out everything else tells you everything you need to know about the format and the medium and what kind of thinking it encourages.
Media guides discourse. This is the most important idea of Marshall McLuhan and why we still talk about him; "the medium is the message." When the quality of the ideas on a medium almost universally declines over time, the medium is the problem not the users of it.
These are subjects for which there are already many minimalist HTML blogs around, but the lack of image support on Gemini makes it impossible for them to support that ecosystem.
Furthermore, nothing prevents Gemini clients from eagerly fetching linked images (based on the URI) and displaying them inline- if the user chooses such a client.
Being strictly text-oriented is simply the default, and a default that must be taken seriously by anyone writing a page.
https://portal.drewdevault.com/x/srht.site
https://drewdevault.com/2020/11/01/What-is-Gemini-anyway.htm...
Markdown is simpler than HTML, but has more to offer than Gemini. You could have tables, images and depending on the flavor also checkboxes. Client side styling would also be easily possible. And if you want a simple browser, you don't even have to parse it and simply show the plain text.
You do not have to be a programmer to write Markdown and many writers already write in Markdown and then convert to HTML.
I'll say this: it's very cool that it's possible to make text more accessible to people using a screenreader than it is to people reading it raw. For instance, if I were to refer to the real real, I would do what I just did, and italicize the word to indicate that it's foreign. Someone who knows how Spanish works can interpolate from "italic real" and get /real/ instead of /ri:l/ out of it, and that's basically what a screenreader would do, literally say "italic real".
I'm not convinced that accessibility demands that words be pronounced properly under such circumstances. Note that someone completely ignorant of Spanish would just see "italic real" and maybe think it represents emphasis, so the sighted are not at an advantage here.
Again, it's pretty cool that there's a way to do it in HTML! Semantic markup is neat, even if it doesn't get used much.
Generally, use of this tagging is obligatory to meet accessibility guidelines. If in practice people don't use the tags so much, this is a problem. Again, the disabled should not be second-class citizens on the web or any medium that aims to substitute for it.
Seems like any interest in making technology more than a replica of reality has disappeared. Maybe its even going the opposite direction, that what we have in reality is too complicated to recreate so the digital becomes more constrictive than the real thing.
Also, how well does html do multiple columns with text flowing between them nowadays?
⇒ I don’t think the original argument is a strong one.
With the CSS property `columns`, this is pretty easy to do:
Guess im a bit confused on the design criteria.
Edit: found the spec - https://gemini.circumlunar.space/docs/specification.html
Sounds like they're passing the buck a bit to the client. Client can decide how long lived, so its up to the user if they want to use a long lived identity or a short lived one. Doesn't sound all that different from cookies to me. In old web browsers you were always prompted if you wanted to accept each and every cookie. Everyone clicked yes so web browsers stopped asking. This seems the same.
Gemini isn't useless because it can't do some arbitrary thing, but I think it's useless because it has no pragmatic purpose. The article author even claims it won't be modified once it's formal. It's like the definition of "dead on arrival".
I'm curious to see how long Gemini keeps an active community.
Just wait until Alex hears about illuminated manuscripts from the 13th century. Gemini's inability to depict historiated initials is an even bigger tragedy.
> if your model is the imaginary "good old web"
Is your assertion that the original cookie free, javascript free web was a hellscape of arbitrary executable code intended to exfiltrate as much monotisable information from the user as possible? Just because someone doesn't like the current situation doesn't mean the past was imaginary.
Oh interesting, had missed that when I took a look at it.
> Is your assertion ...
Obviously not, and responses like this from its proponents are a main reason I'm not interested in it, despite quite a lot of ideological overlap. Saying that not all was as perfect in the past as it's sometimes presented is not asserting that all everything today is better.
Some people are optimising for different properties than the current web. They are developing new technologies to do that.
It is entirely hostile to say that their model is 'the imaginary "good old web"' or to imply that they present the past as perfect (as you do here - clearly in poor faith). They do neither. They are learning from the past and the present and trying to develop some other technologies and a new community that addresses some of their concerns. With great success!
It's strictly impossible for a person who advocates for Gemini to believe the past was perfect. A person who felt the past was perfect would be using the technologies of the past. The people who use Gemini want some things to be different, and find it productive to learn from the past and the present in building this new space. It is a new and fulfilling project. This entire thread is based around the premise that is sufficient as it is, even if a bazillion people aren't posting on it. No imaginary models need enter into it.
Twice now you've used standard but false tropes: Anyone who wants to learn from the past and the present instead of accepting the present as good enough has an imaginary view of the past and believes the past is perfect. Some times, a person runs "git checkout -- some/file" while fully acknowledging that the reason they started editing some/file was because it wasn't perfect when they started. Sometimes a person runs "git bisect" to see how they next version of the code can have the wins of the past and the wins of the present. Acknowledging value in the past is not presenting it as perfect, nor mere imagination.
If you don't like getting pushback for mischaracterising someone's opinions and projcets, feel free to not do that. If the main reason you're not interested in it is because people defend themselves against such unreasonable mischaracterisations, it's probably Gemini who's winning.
As far as I see this doesn't cover most uses of forms, since its result should be appended to the URL with `?` and the URL is limited to 1024 bytes.
I also don't find the usage of SFTP or IPFS reasonable because that would mean two separate clients necessary for a single Gemini site. In fact I personally imagined email instead and email alone can already handle the forum usage (i.e. mailing lists). Gemini at the current state is simply not meant to be used as a full-featured forum. I do think there is a rather simple extension to allow that usage (add an equivalent of HTTP POST to the request protocol, and extend INPUT to give a pre-filled template), but any additional feature to Gemini can possibly weaken its merits.
gemini://geddit.glv.one https://proxy.vulpes.one/gemini/geddit.glv.one
It's a Reddit/HN cone for gemini.
In the (idealised) olden days, the web was a place people posted content. An amateur could make a geocities that showed people their interests, an academic could have a collection of pages that acted as notes for their lectures, or a company could advertise the products that they sold.
In the (distopianised) modern days, the web is a giant network of interlinked computer programs, none of which can be trusted, but most of which offer at least some attractive distraction, whose primary purpose is to develop a small number of competing databases about you to maximise the amount of money that can be extracted from you while minimising the amount of value that can be returned to you. The providers of the computer programs take particular steps which should cause rational people to distrust them (e.g. hiding the button that says "Save my choices" to discourage you from doing what you want and what they are obliged to permit you to do), but healthy people can only tolerate so much distrust in their day-to-day life that they become exhausted.
Gemini starts with extensions to Gopher to develop something a little bit more like the first one. It acts as something like a safe space. It is based on a similar sort of principle to the black-and-white mode on a lot of modern phones, to discourage you from overusing it by making it less attractive. Although Gemini does support form submissions and CGI, the primary form of interaction as far as I know is to have multiple gemlogs.
(I tried using Gemini last year when it was mentioned in this place. But the content I want - e.g. programming language API documentation - is not on Gemini, and I think the Hacker News proxy is read-only, so I began to forget about it. I think Gemini is perhaps a little bit too far over.)
Agreed, but Gemini does address the problem of surveillance.
All metadata are still leaked: IP addresses, DNS queries, FQDNs in the TLS session opening. Also timing attacks.
Furthermore, there's nothing that Gemini can do to prevent unofficial extensions, e.g. browsers detecting and loading HTML/CSS/javascript found on a Gemini page.
That's the problem with the current iteration of the internet. If you run a Gemini-based hidden service, they go away.
> Furthermore, there's nothing that Gemini can do to prevent unofficial extensions, e.g. browsers detecting and loading HTML/CSS/javascript found on a Gemini page.
That's the problem for the client to take care of. Those clients that aren't built with web technologies are unlikely to be subject to accidental web technology execution.
Gopher was a competitor to the early web. It had a distinction between contentful pages and link pages, so it was less flexible than the HTML based web. I'm pretty sure this is one of the things Gemini fixes