I agree that web browsers are too complex. I don’t think that HTTP is the real problem, however. While it might be more complex than we’d like it to be, it’s manageable. From my perspective the real difficulty is in rendering and client-side code execution; the hodge-podge collection of rules of HTML and CSS that have developed over the years is just awful. This is why we have so few serious web engines.
the hodge-podge collection of rules of HTML and CSS that have developed over the years is just awful.
We’re just about there with Flexbox and Grid. You could probably amputate just about everything that came before (especially float, the various alignment options, position, all the animation stuff that goes unused, make display just border-box, etc…) and you’d have something relatively simple, able to fit in a persons memory, and which also covers 95% of the layouts anyone actually needs.
Glad it that works for you! I still have no idea how grid/flexbox work exactly, what the difference is and why there are two. MDN doesn’t help with its fragmented documentation on the subject and has mostly useless examples that don’t work for real world designs. I ended up copy/pasting various examples together until it did more or less what I wanted. Barely better than float/clear.
Someone at the company recently explained it very neatly:
Flexbox is when you wanna lay things out over one dimension (horizontally or vertically). E.g. your sidebar or your toolbar icons and such.
Grid is two-dimensional.
They’re not hard to grasp and I recommend trying it out as it’s really awesome not to deal with the old way of dealing with things. I hardly ever need things like bootstrap any more.
I thought about the elimination of float before as it’s notoriously tricky to implement correctly, but how would you “float” an image next to some text without it? I’m not sure how easy that is with CSS grid and still maintain a reasonable HTML layout (it’s possible, but you’d have to write your HTML in a specific way).
That’s the use case float is designed for; people have been (ab)using it for layouts and the like, which flexbox and grid finally solve in a better way, but I’m not sure if that’s also a replacement for the actual use case floats are intended to solve.
It’s not a managable problem. There are 3 web rendering engines of any utility, and that number is clearly shrinking to 2. One of those two is clearly molding it to serve their self-interest.
How do we “manage” this state of affairs? Fork one of the browsers? Just look at how that’s been going for Pale Moon. Write a new one from scratch? Netsurf is the most advanced attempt so far, try to use it for a week and tell me you feel like a first-class citizen. Or maybe you prefer Servo - try that for a week to similar effect, and recall that their whole team was fired from Mozilla and they hadn’t made any progress in the last 2 years anyway.
No, this problem is far from managable. It’s out of control.
There are no inline links (every link goes on its own line), no formatting, and no inline images
So it’s borderline useless for all but the simplest use cases, and even there it does a very subpar job. I’d like to have an inline image every now and then, or organize things in some multi-column layouts or the like, or a table. 19th century newspapers could do this, and if your technology can’t emulate typography produced on a daily basis – often in a hurry – 150 years ago then your tech is rather limited.
These protocols keep shooting themselves in the head with stuff like this, not even in the foot because this entire thing is dead on arrival for all but a few niche tech folk.
I see this a lot, and I really, really wish that the people making this case would actually try to use Gemini for what it is before bringing their preconceptions into it. Easily a full third of the people I’ve spoken to about Gemini immediately start talking about some $FEATURE that they would add to it - and I’ve heard a lot of different features. Do you see the problem with this? This is just a recipe for re-inventing the bloat of the web.
You must first use, then understand, then change the software. You can’t skip steps one and two. It is possible to express yourself within these constraints (you’re already expressing yourself within some fairly arbitrary constraints right now, for instance, imposed by Lobsters’ strict markdown rules), and you should first apply a little bit of creativity to the new medium before you try to bend the medium to your will. We don’t really want it bent, we’re doing something different for a reason.
By the way, your comment can be losslessly represented in Gemtext.
Easily a full third of the people I’ve spoken to about Gemini immediately start talking about some $FEATURE that they would add to it - and I’ve heard a lot of different features. Do you see the problem with this? This is just a recipe for re-inventing the bloat of the web.
I’d argue that this is because the problems it solves are inherently complex, so any good solution to it will be complex as well. That doesn’t mean I don’t think the web can’t be improved or made simpler – it’s an organically grown mess of 25 years – but it will never be replaced by a dead-simple solution such as Gemini.
And yeah, my Lobsters comments can be expressed in Gemini without much loss (except the inline links thing), but Lobsters isn’t my website though and I wouldn’t be able to express my fairly simple website on Gemini, or a fairly simple site as Wikipedia. And even the entire Lobsters website would be a worse UX in Gemini as it precludes any sort of design.
But isn’t this very limiting? Like, it would work for your blog, but in its current iteration adding a table would already be difficult, never mind something more advanced like the fivethirtyeight election forecast and results.
I suppose it all depends what your vision for Gemini is; if you want it to replace large parts of the web then it’s got basically 0 chance in its current state; if you just want some alternative to use yourself and like-minded people, then sure, go for it.
Of course Gemini doesn’t preclude design: It’s a networking protocol. You can use it to move HTML and JS and CSS and images and whatever else just fine.
Attempting to conflate a protocol with a document format is wrong.
The specification also includes a document format, as well as a networking protocol.
Arguably, things would have been clearer if they were separated out more clearly, but this would kind of defeat the point of Gemini. The networking protocol and document format are intended to be used together.
It seems interesting; to make it clear, I do hate tracking too, as well as inaccessibility & various Flash-equivalents of today. And dependency on the complexity tower of Chrome/Firefox/… So I’m certainly curious about alternatives to the current status quo.
I do understand that the protocol seems to allow for a lot of expression, and more “slow-food” style, relaxed consumption. Yet, I cannot escape immediately having a feeling of loss. If I understand this correctly, with no mathematical equations support, I would not be able to write or consume an article trying to explain Shor’s algorithm. With no graphs support, I assume whenever I’d want to display graphs, I’d have to resort to ASCII-Art as a workaround, with necessarily limited precision (for example, no smooth curves or complex 3D surfaces). Finally, I assume I would not be able to write or consume an article about typography, or bysantine icons. Or am I wrong?
Having the concerns mentioned above, I’m immediately starting to think about possible workarounds. I am assuming people would start resorting to “rich clients” - for example, with support for rendering of some kinds of mathematical equations. This, I am guessing, would quickly lead to on-site recommendations like: “This page requires support for LaTeX-Super-Renderer-3.7”. De-facto becoming in-band signaling of the kind Gemini apparently tries to dispell by “only allowing one field in response, the mimetype”. But wouldn’t people start doing that anyway, and start writing such plugins anyway, and start de-facto reinventing HTML anyway? With the likes of Flash plugins of yore raising from the dead in new clothes?
With regards to just graphs and images, I believe it could be somewhat easier actually. I am now reminded of the days of my childhood, when books in my country were mostly in black and white, with a few pages in the center being in color, and being referenced to by the b&w pages (“See illustration 7.b.”). I imagine something like that could work with images being listed, or linked, or attached (?) at the end of a Gemini page. But even then, I don’t think that would be usable for math-heavy documents. And from glancing through the few links around here, it’s not fully clear to me if any images at all, even at the end of a document, are expected to be supported? (Though mimetypes support kinda seems to hint at allowing this?)
So, with the ideal of simplicity sounding theoretically interesting and alluring, at the same time I’m concerned about losing access to, especially, maths-related content. (Assuming that some image-heavy, yet comparatively sparse in that regard, content could be possibly approximated with a list of image links at the end, referenced from the main article. Which kinda already sounds like a hack, that would probably soon lead to reintroducing inline images via specialized clients…) That feels like a pity to me.
I do understand that the protocol seems to allow for a lot of expression, and more “slow-food” style, relaxed consumption. Yet, I cannot escape immediately having a feeling of loss. If I understand this correctly, with no mathematical equations support, I would not be able to write or consume an article trying to explain Shor’s algorithm. With no graphs support, I assume whenever I’d want to display graphs, I’d have to resort to ASCII-Art as a workaround, with necessarily limited precision (for example, no smooth curves or complex 3D surfaces). Finally, I assume I would not be able to write or consume an article about typography, or bysantine icons. Or am I wrong?
I’ve brought this issue about math up in the past, but remember, nothing is stopping you from using HTML or PDF. Gemini uses Gemtext as a lowest-common-denominator form of markup, but if you are writing a client, you can always built in HTML support or shell out to something else that does.
I think that the reason that people keep trying to suggest features is that Gemini is marketed as a replacement for “the web”, but designed (and only useful) as just a plain text delivery mechanism - there’s (rightly) some cognitive dissonance going on.
That is, “the web” includes plain text, hypertext, rich documents, audio/video media, and interactive content. I don’t think that most people expect Gemini to implement the last two, but there’s some reasonable expectation that something trying to replace “the web” should at least be able to represent reasonably interesting documents - such as scientific papers, which Gemini clearly cannot.
Perhaps if proponents of Gemini stopped trying to claim that it could actually replace anything but the tiniest slice of the web that is pure, plain text (not hypertext, as inline links are really important), you would stop getting people talking about adding features.
Edit: that is, there’s no “preconception” going on here. GP post is responding to the argument that Gemini is a viable replacement for the web by pointing out that it is missing critical features for actually acting as a sane replacement, which has no “preconception” - it’s just a statement of fact. You cannot replace the web without inline links, formatting, or inline images, full stop.
None of these sites, or the majority of the thousands of other bookmarks that I have, can be replaced without inline links, formatting, or images.
Linked files do. Not. Cut. It.
Not only are linked (vs. inline) files objectively and meaningfully different (and, therefore, you cannot replace the web with them), but they are inferior from an information-processing standpoint. From both a practical and theoretical level, you cannot replace the web with Gemini as it currently stands. People will not use it, they are not equivalent, and I, personally, will discourage people from using it - it is a cognitive anti-tool, similar to a reverse printing press. Useful for implementors, terrible for anyone who actually wants to read documents and exchange information that will actually help them to learn and reason.
I can provide another counter-example: you had 5 links in your comment, none of which were inlined, despite having access to inline links on lobsters.
You can’t place identical content on Gemini as you can on the web. You can reformat your content for the new medium. Nothing transitions between mediums without change.
Gemini replaces a subset of the web, which I stated in the opening article and have re-iterated dozens of times.
I can provide another counter-example: you had 5 links in your comment, none of which were inlined, despite having access to inline links on lobsters.
…that’s not a counter-example. I never claimed that you can’t replace any of the content on the internet, which is what that statement would be a counter-example to. Perhaps you should take a logic course. Edit: that was too aggressive, my apologies.
Edit: I claimed that you cannot replace “the web”, which implies replacing the majority of the content at least, and all of the content at most.
You can’t place identical content on Gemini as you can on the web. You can reformat your content for the new medium.
…and, as it should be very clear, that re-formatting process is (1) lossy and (2) causes a significant decrease in readability and information processing - meaning that it is not a replacement. The format of the web is part of the web, therefore you cannot replace the web with Gemini.
Gemini replaces a subset of the web, which I stated in the opening article and have re-iterated dozens of times.
You have tried to claim that Gemini can replace anything but the tiniest trivial slice of the web that is pure, un-hyperlinked plain-text - which, as shown above, is false. The format of the web is part of the web. The content and the medium are entwined.
Anything with “less features” is lossy, but that’s not correlated with a “significant decrease in readability”. On the other hand, putting the presentation entirely into the client’s control is a significant win for readability, because the user can configure fonts, contrast, and layout to their preferences and usability needs. The screen reader experience, for instance, is WAY better. Inline links and inline formatting are less accessible to some.
Only true in the most needlessly pedantic sense. You can easily build systems with a small set of carefully-chosen features that still implement the vast majority of the functionality of larger systems that were poorly-built. This…does not describe Gemini. Gemini picked a basis of features that do not allow it to implement more complex functionality or richer documents.
that’s not correlated with a “significant decrease in readability”
Not in general, sure - but in the case of Gemini, it’s pretty clear that there is a significant decrease in readability (and, therefore, cognitive processing ability). Requiring users to click through to a separate document for each image, animation, or individual mathematical equation is extremely unreadable for anything with a reasonable density of those things - while “only” being merely slightly less readable for documents with only a few of those objects.
On the other hand, putting the presentation entirely into the client’s control is a significant win for readability
the user can configure fonts, contrast, and layout to their preferences and usability needs
You can already almost entirely control presentation with major browsers for the current web, through userscripts and stylesheets.
Moreover, HTML is actually structured, unlike Gemtext, so I have anchor points and document metadata that I can use to exert more control over my content than with unstructured Gemtext - so your statement is actually untrue.
The screen reader experience, for instance, is WAY better.
Modern web gives you more options to make a good screen reader experience - such as image alt text. Is it really inconsistently used? Sure, but that’s not a technical problem, that’s a social one - a social one that manifests itself in an equally bad way with Gemini, because Gemtext doesn’t have any way to bind accessibility-related metadata to document structure, because there is no document structure.
Inline links and inline formatting are less accessible to some.
Expanding links and controlling inline formatting are very basic features for screen readers.
So, to summarize, modern web gives you a much richer interface for screen readers, as well as a better interface for people who don’t use screen readers (which is the majority).
Gemtext is straight-up less conducive to thought and information transfer.
I think “significant decrease in readability” is interpreted a little too literally here.
Many of the documents linked by fouric would be way more inconvenient to read if they were adapted to fit in gemini’s limitations because of how heavily they rely on tables, anchor links to a specific part of the same document, and inline images (especially with how inconsistent most clients available today are at dealing with non-gemtext content types).
I personally am a big fan of how gemtext files only ever result in a single request due to the lack of stylesheets, scripting, and inline resources, and have pushed back on the adoption of HTML and Markdown as alternate document content types because I think that is a valuable part of the protocol. I’m also not delusional: the stance I hold also directly limits the mass appeal of gemini as a technology, because normal people who just want to read these kinds of documents are unlikely to accept what seems like massive inconvenience for technical reasons they don’t fully understand. They’ll just stick to the Web.
I am willing to put up with that inconvenience as a reader and writer of gemtext content because I think the other benefits of gemini are worth it, but I don’t expect anyone who isn’t another disillusioned Web developer to get on board quite as easily.
By the way, your comment can be losslessly represented in Gemtext.
This isn’t quite true, is it? His comment included the clearly-delineated metadata of his name and the time, including an inline graphic element (his avatar) to aid the eye in scanning the page for it. Gemtext as currently defined precludes any such niceties because they are perceived as ornament by the early community (who ironically see a need for some headings, lists, quotes, and … ASCII art).
It also included a simple method for you to add a reply. POST is a slippery slope, but I hope Gemini someday gains a sort of Micropub.
(I am one of those $FEATURE users, where $FEATURE is inline images and metadata or some sort of “secondary” text. But I’ll finish building my capsule and client and see how things evolve.)
You just wouldn’t have lots of inline links. You’d have a separate list of references, perhaps. Here are some examples of Gemini posts I have written with lots of links:
Let me put it this way: how would inline links work in a newspaper, book, or magazine? The answer is: they wouldn’t, and you just work within those limitations. That doesn’t mean the medium is bad.
19th century newspapers could do this, and if your technology can’t emulate typography produced on a daily basis – often in a hurry – 150 years ago then your tech is rather limited.
Not arguing against you, but when it comes to web browsers, then they still haven’t learnt to properly hyphenate text. Another thing we could do 150 years ago. One of the reasons (another being rather poor support for rendering maths, or, in the case of Chromium, complete lack of it) I’m relieved whenever I get to read a PDF generated from LaTeX instead of a webpage.
If I use soft hyphens, then copying He­re are rhi­nos. to terminal results in He re are rhi nos. visually, because it copied the text with the soft hyphens even though everything was on a single line.
LaTeX certainly requires some manual help.
It never required it when I used it. When you enable correct language support, it should just work.
I thought this analogy was cute for a little bit. But seriously, why is 150 years ago the standard? Are we really that painfully nostalgia-blind that we can’t recognize there’s a medium point between the old and the new?
It isn’t my standard, and frankly I don’t really care what we could / couldn’t do 150 years ago because I don’t believe it matters in the context of what are we doing, trying to do, and can’t do today.
Well, 150 years ago it was a manual process, and not an automatic one :-) I regularly insert ­ for this on my website by the way. But yeah, I agree that the lack of a universally supported hyphenate: auto has been long overdue (only Firefox supports it, and it doesn’t even do a great job at it, although I don’t know if there are technical reasons that prevent it from doing a better job; I think I saw someone on HN detail some issues with automatic hyphenation on the web years ago, but I forgot what they were).
Math rendering has also been supported by Firefox for 15 years with MathML, but for some reason Chrome doesn’t (but Safari does). Actually, looks like they removed it in Chrome years ago, although it looks like there’s work to add it back soon-ish.
Actually, along with Firefox, some versions of Chrome (Android & Mac) support auto hyphenation, and Safari has it hidden behind a prefix: https://caniuse.com/css-hyphens I feel that together these may cover enough of the market to make it worth adding to web pages.
If you want to see a quick and stupid demo, here’s my very unfinished Hugo theme I’m working on developing: https://www.maximumethics.dev/blog/2020/07/my-first-post/ If you shrink the viewport width until it’s skinny like a phone, you’ll see the longer 90 chars “alphabet” line break to hyphenate (on the aforementioned supported browsers), as well as random words in the text.
Ah yeah, it’s just the desktop version that doesn’t support it for some weird reason; I forgot about that detail.
I suppose it depends what you use it for: most of the time I really wanted auto hyphenation is for comparatively narrow pieces of text and/or for text-align: justify (e.g. a sidebar or info box). In those cases the hyphenation (manual or automatic) is pretty much a must-have rather than a nice-to-have, because without it it just looks ugly. Your site, on the other hand, looks fairly decent without hyphenation even on smaller screens, but it won’t hurt to add it for browsers that support it.
Math rendering has also been supported by Firefox for 15 years with MathML, but for some reason Chrome doesn’t (but Safari does). Actually, looks like they removed it in Chrome years ago, although it looks like there’s work to add it back soon-ish.
That’s what I was on about. If something isn’t available in Chrome, it’s irrelevant these days. I’ve been aware that “it looks like there’s work to add it back soon-ish” for quite some time now. I don’t have hope.
I think the idea is that the publisher delivers only the information, not the presentation. This constraint allows for greater user control over presentation, for example one might configure Gemini to lay out news articles (maybe on a site by site basis) in a column style, to suit their preferences. I think it’s an interesting idea as a way of making better typesetting more widely available to content published on sites without the budget / know-how to tune their CSS for readability.
I agree that Gemini would be better off if it supported inline images. That’s pretty often part of the information layer.
Not really, HTML still focuses a lot on presentation. Headers, side bars, footers, nagivation line, footnotes, etc. are all concepts foreign to the browser, that have to be manually re-implemented in the markup language, again and again. That’s actually what I think that protocols like Gemini misunderstand: HTTP/HTML is not too systamatically complicated (at most it’s “organically” complicated), it’s actually too simple. If for example the <head> section had made it possible to describe how a web-page is navigated, it would have been possible for the browser to render that part of the site, leaving the <body> to be actual content. It’s something you see with other simple languages too: Scheme has various implementations, that implement a common core, but diverge in their additional libraries, that are regarded as useful, but do not allow for code to be portable. So too, had HTTP/HTML has the foresight to recognize what people would want from websites (which is probably too much to ask), or at least the foresight to allow a certain degree of extensibility, a lot of implementation-specific complexity could have probably been avoided.
So the issue might not be “simplicity vs compexity”, but “what kind of complexity”.
Years ago I came across a browser extension that would build a navigation bar if it found certain <link> tags in the header. I modified my blogging engine to automatically add said links. Sadly, the extension no longer runs (because of course the extension mechanism changed—at least twice—since then) but I still generate the data in the vain hope it’ll be useful again.
A strict separation of information and presentation is something that sounds great in theory, but doesn’t really work all that well in practice once you move beyond the simple use cases, or use cases that are pre-defined and supported in some way.
I don’t know if this was part of the design goal - from what I can see, Gemini doesn’t have any sort of mechanism to describe or annotate what content/information is being delivered, which would make any presentation strategy necessarily heuristic, as there would be no way to delineate e.g. where the “author” of the article is.
I’m not quite sure what you mean - when you say “just put that information into the document itself” do you mean in a machine-readable format? Because if so, that’s not part of the Gemini text spec - which is the thing being discussed. Adding tags like <address> would be extending the Gemini spec to add features, which is what proponents of it are fiercely against.
As it has been stated on the mailing list, “you can always serve up text/html or text/markdown, you aren’t limited to text/gemini.” There are sites out there serving up images and even music.
Well, that’s not really what’s advocated for in this post (or on the Gemini website as far as I could see), and serving HTML over Gemini just sounds like a s/HTTP/Gemini/, and you can serve text or Markdown over HTTP as well. I don’t really see the point if you’re going to serve HTML over Gemini.
I’m sick of how complex html+css+js gets, and how complicated extracting the actual content can be, in order to view it on “unusual” platforms (small screens. ereaders, etc.), where a good experience depends on the client controlling the presentation of the content. Something like gemini could be the solution to that, but I have to say, the lack of inline images is a deal-breaker for me.
I view multi-column layouts as part of the presentation, not the content (I don’t want two columns of text on a phone screen: if I do want two columns of text on the desktop, I can write that into the client), but the images are part of the content.
I did wonder whether technically a gemini-ish client could fetch urls which look like they point to images and display them inline, but this is explicitly banned by the specification:
Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. gemini://, gopher://, https://, ftp://, etc.).
I can sort of see what they’re aiming for, presumably trying to avoid the sort of nonsense some websites have become, where the initial request just gets a jumble of html elements that require the client to fetch and execute tons of javascript before they can be assembled into something resembling content, but I think they should have made an exception for images (They could still leave it up to the client whether it displays inline images or not).
Interestingly, gemini probably works really well with screen readers, until you get to an image link (or any link for that matter), at which point it depends entirely on whether the author bothered to provide a caption, or explain what the link is as part of the text (Although that’s arguably no worse than html, where the existence of alt text doesn’t mean that it is always used or used correctly).
One big reason I’m excited about Gemini is the possibility of escaping the web’s bloat, which we need to do in order to reduce energy usage / emissions in the climate crisis. For this reason, I support Gemini’s decision to ban inline images. If you have inline images, next people will want inline video, and soon even if Gemini is “simpler” it’s using as much storage+bandwidth+processing as a web page.
Inlining images, especially from other locations, is also a plausible method for sneaking user tracking back into the protocol, and I also approve of Gemini’s strong efforts towards privacy. I also hate ads even when they don’t track people, I’d love to live someplace where billboards are banned so I can escape the constant background hum of marketing. Eliminating inline images is also a great way to reduce the annoyance of advertising.
I’m going to have to agree with everyone in this thread that refusing to implement inline links was a mistake, though. That was one of the biggest problems I had with Gopher, and I was hoping Gemini would do a better job with hypertext.
Inlining images, especially from other locations, is also a plausible method for sneaking user tracking back into the protocol, and I also approve of Gemini’s strong efforts towards privacy.
It’s a very difficult balance to strike between simplicity and functionality. You could probably avoid trackers by, as @m_eiman says, only allowing additional requests from the same domain as the original document.
Alternatively, you could create/use a format which embeds the images directly in the original document (similar to how pdf or epub does). Some might argue that this is inefficient, as you need to serve multiple copies of the image data if it appears on multiple pages. However, in this context, it could be seen as a feature, as we don’t want the kind of images (such as ads) which aren’t actually “part of the document”.
There will always be some people who abuse any protocol, but not having inline images is very limiting and means it isn’t any good for a significant portion of (what I consider) “good content that doesn’t need javascript/css”.
But ASCII art is pretty much the quintessence of mixing presentation and content, which is very specifically what Gemini seeks to avoid. It can’t wrap or scroll differently on small devices, it can’t be extracted (easily and reliably) to a machine-readable data format, and it isn’t accessible because there’s no semantic information about the table structure.
I need to click a link to an image? It seems pretty obvious to me that this is worse UX than just displaying it.
ASCII art relies on a monospaced font, which I don’t really like for reading text. I think Lobsters would be significantly worse if it was all monospaced text for example. It also relies on a certain screen size, which doesn’t work for smaller screens (or very big ones, for that matter). I mean, it kinda works but it’s a hack.
I need to click a link to an image? It seems pretty obvious to me that this is worse UX than just displaying it.
Yeah. You’re completely right, this is worse UX. I’m beginning to think of proposing an inline-image syntax for the gemini spec.
ASCII art relies on a monospaced font, which I don’t really like for reading text.
I admit I was wrong. ASCII tables are a hack, I suppose. Hopefully the simple table syntax I’m thinking of right now makes it into the spec!
I think Lobsters would be significantly worse if it was all monospaced text for example. It also relies on a certain screen size, which doesn’t work for smaller screens (or very big ones, for that matter). I mean, it kinda works but it’s a hack.
FYI there are gemini clients that support variable-width fonts.
FYI there are gemini clients that support variable-width fonts.
I tried to use it with Gopher years ago (I hacked up an existing client), and many sites don’t really work all that well because they assume stuff will be displayed as monospaced text (such as tables you mentioned, but also things like code examples, or other alignment things).
Gemini is a bit of an improvement because the spec at least recognizes that proportional text exits and has “code blocks”, but it also leaves much to the clients. In other words: I wouldn’t be surprised if people would just keep using it as they used Gopher, and the weird (and IMO, broken) way line wrapping works in Gemini doesn’t help either. I suppose time will tell how it will be used in practice (but as mentioned, I don’t think it will be used much in practice beyond a few “Hacker blogs” like Drew’s).
One of the big mistakes of HTML was, ironically, to “leave it up to the clients” which resulted in a big mess which had to be unified so that people could get a reasonably consistent experience irregardless of which browser they use, but that just unified the mess instead of clearing it up.
Gemini is only a protocol, but the specification also propose a basic text/gemini format as a de-facto document type. It however supports any mimetype, including text/html:
5 The text/gemini media type
5.1 Overview
In the same sense that HTML is the “native” response format of HTTP and plain text is the native response format of gopher, Gemini defines its own native response format - though of course, thanks to the inclusion of a MIME type in the response header Gemini can be used to serve plain text, rich text, HTML, Markdown, LaTeX, etc.
You could totally sent the following HTML document over gemini:// and enjoy inline images:
It would then be up to the gemini client to process this document, fetch required resources (the cat picture) and render it nicely for you. The advantage of the gemini protocol here is that it would put a limit on the HTML subset one could put in a document. For example, <form> tags won’t be any useful. There would also be no need for <script> tags, as they wouldn’t be able to “phone home” over gemini.
One of the biggest problem of the web is that the HTTP protocol itself grew in an enormous monster that’s impossible to understand, where sometimes the headers of a requests can be 10 times bigger than the content itself.
I’ve been reading the Gemini specification, as well as this post, and my conclusion is that it’s just a worse version of HTTP 1.1 and a worse version of Markdown.
Strong disagree. TLS + HTTP 1.1 requires to perform a upgrade dance involving quite a few extra steps. The specification is also pretty empty regarding SNI management. Properly implementing that RFC is pretty demanding. There’s also a lot of blind spots left to the implementer better judgement.
In comparison, the Gemini TLS connection establishing flow is more direct and simpler to implement.
TLS aside, you mentioning
I’ve been reading the Gemini specification
sounds like a clear win to me. The baseline HTTP 1.1 RFC is already massive let alone all its required extensions to work in a modern environment.
I agree that the specification is simple to read, but the specification itself is too limited and don’t find it suitable for the real world.
For example, I prefer HTTP’s optional end-to-end encryption because when working with internal routers within an infrastructure dealing with certificates is a PITA and a completely unnecessary bump in complexity and performance overhead being inside an already secured network.
I also disagree on that “extensibility is generally a bad idea” as the article says. Extensibility can work if you do it properly, like any other thing on software engineering.
EDIT:
Or the requirement of closing the connection and re-opening it with every request, and all the handshakes that means.
For clarity about what I think could be an actual improvement: I would prefer an alternative evolution of HTTP 1.0, with proper readable specs, test suites, clearer https upgrade paths, etc; instead of an evolution of Gopher.
TLS + HTTP just requires connecting to port 443 with TLS. I’ve worked on lots of things using HTTP for >20 years and I don’t think I’ve ever seen the upgrade protocol used in real life. Is it commonly used by corporate proxies or something like that?
When I looked at it (months ago), I got the same impression. I find this article irresponsible, as Gemini does not merit the support.
Gemini’s intentions are good. The specification isn’t. For instance, not knowing the size of an object before receiving it makes it a non-starter for many of its intended purposes.
This is an idea that should be developed properly and openly, allowing for input from several technically capable individuals. Not one person’s pet project.
I’ll stick to Gopher until we can actually do this right. Gemini doesn’t have the technical merit to be seen as a possible replacement to Gopher.
It does accept input from individuals. I was able to convince the author to expand the number of status codes, to use client certificates (instead of username/password crap) and to use the full URL as a request.
Gemini is a network protocol for exchanging hypertext documents
… and this is where he loses me. Gemini is a network protocol. It doesn’t force you to send any specific kind of documents in response to requests. That means it will be used to send any kind of document whatsoever the moment it gets at all popular, and lose whatever properties the non-HTML hypertext format has which make it so attractive to him when everyone else uses Gemini to send HTML with CSS and Javascript and, oh yeah, images and videos. There’s a reason Web browsers caught on in the first place: They could speak multiple protocols and parse (or otherwise handle) multiple kinds of document. Trying to confuse and conflate a protocol with a document format is, therefore, fuzzy thinking which grates on me.
I don’t get this at all. For those folks who want to have super simple layouts and no styles, you can do that with HTML without any problems. In fact, you can just ship plaintext to the browser if you really want. I saw the argument of “how do newspapers, books, and magazines do inline links” and I wonder if I’m in the same reality. The digital space is NOT the same. Those things don’t even have links. There’s really no comparison between them other than they can both have text.
This doesn’t even seem niche, it just seems idealistic in all the wrong ways. The web doesn’t exist as it is today because it sucks. I can’t even imagine trying to create a forum like this on a limited protocol like that. And instead of working on bettering the state of browsers, people pour energy into things like this that are basically hobbyist displays of protest. Do what you want with your free time, it’s your time, but I can’t imagine anything like this ever growing in real adoption. It’s not even a step backward since you can do all of this stuff in plain html anyway. It’s just silly.
Gemini is a strangely coupled project. Everyone who loves it seems to do so because they hate HTML5+CSS+JS (or at least those things as implemented and used by “modern web”). Fair enough. But then the first thing Gemini does is define a new document retrieval protocol – one that is almost identical to HTTP. Now, if you hate HTTP, that’s interesting, but no article I read about Gemini talks about problems with HTTP. The Gemini protocol can be used to serve an HTML5+CSS+JS mess if you like, the only thing preventing that is the community of people who want Gemini don’t want that and so they won’t use clients that work well with it etc, etc.
I’m 100% behind the ideas that people who love Gemini want to see move forward. I just feel like the goals of the whole project are a bit muddier. If the goal of the protocol is to make the pages unusable by the unwashed masses, I guess that makes some sense, but then you’ll have to work hard to prevent it from becoming popular and going endless september all over you some day. If the focus is on simpler hypertext formats, then why not focus on the format and deliver it over the myriad of existing protocol options (including HTTP, just for simplicity).
The issue with HTTP is that it can leak enough information to allow easier tracking (user agent, language preferences, etc.) and can be quite complex to implement (partial content, pipeline connections, caching, proxying, HTTP/2 and now the upcoming HTTP/3 which requires a custom lower-level protocol). Solderpunk wanted a protocol (and a text format) that was easy to implement over a weekend.
But we’re talking about building all new clients at least, and for Gemini also servers, right? So no need to send all that extra junk or use those optional features if you don’t want to, just plain old:
GET /thing.gemini HTTP/1.1
and reply:
HTTP/1.1 200 OK
Content-Type: text/gemini
Some gemini content...
This is, I’ll grant, a few more bytes than the Gemini protocol if these are the only features you ever want. However, I’m not sure it’s enough more bytes to bother breaking compatibility over.
I spent a couple months poking around this ecosystem and had a great time. Blogs on Gemini are personal, and an interesting mix of people after self-selecting for tech interest. It feels like early Livejournal.
There are several advantages. I’m going to quote the FAQ page:
Unambiguous use of arbitrary non-ASCII character sets.
Identifying binary content using MIME types instead of a small set of badly outdated item types.
Clearly distinguishing successful transactions from failed ones.
Linking to non-gopher resources via URLs without ugly hacks.
Redirects to prevent broken links when content moves or is rearranged.
Domain-based virtual hosting.
Text in Gemini documents is wrapped by the client to fit the device’s viewport, rather than being “hard wrapped” at ~80 characters with newline characters. This means content displays equally well on phones, tablets, laptops and desktops.
Gemini does away with Gopher’s strict directory / text dichotomy and lets you insert links in prose.
By allowing links within content pages instead of separating content from menu pages, Gemini acts as hypertext. You can have that always going forward, losing yourself in Wikipedia kind of experience. You don’t constantly hit dead ends; sites are naturally more interlinked.
As much as I’d like to have a simpler alternative to the web stack, I think Gemini is a bit of an extreme in its approach. Ideally I’d like to see a protocol closer in functionality to the web of 90s (functionality != tech stack, so maybe not even HTML) with a federation support built in.
Decoupling presentation from data + disallowing code execution on a client side would already be a MAJOR factor to simplify the client.
A page can request user input in a single text field, which has the semantics that the same page is re-fetched with the contents of the input field added as a query parameter (see 3.2.1 in the spec). So far I’ve seen this used for: 1) search boxes, and 2) text input to interactive fiction games.
I don’t think it’s designed for more wiki-style editing where the entire document itself is edited in the same viewer.
I read a lot of text in my browser and I find variable-width fonts easier to read. Anything which wants me to do this reading in a fixed-width-font terminal I’ll ignore.
That’s understandable – I also find variable-width fonts easier on my eyes! There are, however, a bunch of non-terminal clients that can use other fonts, such as Castor.
Last night I’ve written a gemini-server in 100 bytes of sh/netcat as a challenge (it expects the status line inside the file to serve; $G is the directory to serve).
I implemented my little website (gemini://caioalonso.com) this weekend after reading Drew’s article, as an attempt to understand Gemini a bit more.
The Web is overly complex and has endless scope–and it can be said that this is because society is endlessly complex–but we don’t seem to agree on the scope of this new, small Web. Everyone has a different subset of the old Web in their minds as what is the Ideal. If we use the subterfuge of saying ‘well anyone can deliver any MIME type they want’ then we’re just moving the complexity to having many different parsers or a single parser (like the traditional Web browser) that can display (and compute) anything and we’re back to the same problem. If we don’t define and accept scope then the final scope will be Turing completeness because that is the underlying feature set of computers.
How can we objectively say that we’ve got enough functionality? Will it ever be enough?
This post is an excellent introduction to Gemini. I can understand all the opposition against the idea (too simple, too limited), still I am excited about this new development and I can see the whole new world beyond.
The page I am brewing right know, will definitely have Gemini version.
I don,t understand how this is better than 20+ years of http with countless interchangeable implementations of each layer (http, html, js, cgi, access.log, ssi)
it,s an amazing stack if you use it in more established ways.
can we build something like Web 2.1, with all the kinks of basic css worked out, reasonable js like getElementById, basic dom… and code for every browser including links and nojs?
Here are some of the issues with a subset vs a new protocol.
Defining a subset is hard, everyone wants their pet features included.
The comments on this story are an excellent example of this phenomenon.
HTML5, CSS, and JavaScript are enormous specifications - it’s a substantial task.
It’s a huge burden for one person but sharing the task means lots of interminable discussions about what to include/exclude.
Writing a validator for the subset will be harder than for a new protocol.
Protocols are more interesting to the target audience.
Some of the project goals (no user tracking and easy implementation) are easier to address with a new protocol.
I disagree with some of the Gemini design decisions but think that defining a new protocol was the right call.
Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax. Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients). Even though in-line links may be a more natural fit for some kinds of content, they’re just not worth the increased complexity and fragility they would inevitably introduce to the protocol.
It’s true that you need to shift your thinking a bit to get used to the one link per line writing style, but it gets easier over time. There are benefits to the style as well. It encourages including only the most important or relevant links, organising links into related lists, and giving each link a maximally descriptive label without having to worry about whether or not that label fits naturally into the flow of your main text.
I agree with the points of this blog post, and with the mission of Gemini’s “radical simplicity” – it very much is a technical implementation of some of the early-twentieth-century art movements like Oulipo or De Stijl, where constraints forced a novel imagining of creative pursuits.
I’ve also heard the originator of the project describe Gemini as closer to Gopher than HTTP – so that helps to explain the design choices made.
I proxy to my gemini capsule from HTTP for my main website. With a touch of styling (and a little patch to go-gemini to allow inline images to be displayed) it’s more than adequate for a website as well
Litmus test; would https://sr.ht be implementable in Gemini?
I am not 100% sure, it’s possible that the TLS client certificate makes it easier to track people. The client would have to support selecting which identity to use for a given website at the minimum.
I agree that web browsers are too complex. I don’t think that HTTP is the real problem, however. While it might be more complex than we’d like it to be, it’s manageable. From my perspective the real difficulty is in rendering and client-side code execution; the hodge-podge collection of rules of HTML and CSS that have developed over the years is just awful. This is why we have so few serious web engines.
We’re just about there with Flexbox and Grid. You could probably amputate just about everything that came before (especially
float, the various alignment options,position, all the animation stuff that goes unused, makedisplayjustborder-box, etc…) and you’d have something relatively simple, able to fit in a persons memory, and which also covers 95% of the layouts anyone actually needs.Glad it that works for you! I still have no idea how grid/flexbox work exactly, what the difference is and why there are two. MDN doesn’t help with its fragmented documentation on the subject and has mostly useless examples that don’t work for real world designs. I ended up copy/pasting various examples together until it did more or less what I wanted. Barely better than float/clear.
I have found these two resources to be very helpful:
Excellent! Thanks!
Someone at the company recently explained it very neatly:
Flexbox is when you wanna lay things out over one dimension (horizontally or vertically). E.g. your sidebar or your toolbar icons and such.
Grid is two-dimensional.
They’re not hard to grasp and I recommend trying it out as it’s really awesome not to deal with the old way of dealing with things. I hardly ever need things like bootstrap any more.
I thought about the elimination of
floatbefore as it’s notoriously tricky to implement correctly, but how would you “float” an image next to some text without it? I’m not sure how easy that is with CSS grid and still maintain a reasonable HTML layout (it’s possible, but you’d have to write your HTML in a specific way).That’s the use case
floatis designed for; people have been (ab)using it for layouts and the like, which flexbox and grid finally solve in a better way, but I’m not sure if that’s also a replacement for the actual use case floats are intended to solve.That’s why we should stick to HTML 3.2, the best of all HTML standards.
It’s not a managable problem. There are 3 web rendering engines of any utility, and that number is clearly shrinking to 2. One of those two is clearly molding it to serve their self-interest.
How do we “manage” this state of affairs? Fork one of the browsers? Just look at how that’s been going for Pale Moon. Write a new one from scratch? Netsurf is the most advanced attempt so far, try to use it for a week and tell me you feel like a first-class citizen. Or maybe you prefer Servo - try that for a week to similar effect, and recall that their whole team was fired from Mozilla and they hadn’t made any progress in the last 2 years anyway.
No, this problem is far from managable. It’s out of control.
@davmac was saying HTTP was manageable, which feels like a different conversation.
Oh, I see. I still don’t think HTTP is that great. I prefer to draw a line in the sand and not mix incompatible cultures on the same network.
So it’s borderline useless for all but the simplest use cases, and even there it does a very subpar job. I’d like to have an inline image every now and then, or organize things in some multi-column layouts or the like, or a table. 19th century newspapers could do this, and if your technology can’t emulate typography produced on a daily basis – often in a hurry – 150 years ago then your tech is rather limited.
These protocols keep shooting themselves in the head with stuff like this, not even in the foot because this entire thing is dead on arrival for all but a few niche tech folk.
I see this a lot, and I really, really wish that the people making this case would actually try to use Gemini for what it is before bringing their preconceptions into it. Easily a full third of the people I’ve spoken to about Gemini immediately start talking about some $FEATURE that they would add to it - and I’ve heard a lot of different features. Do you see the problem with this? This is just a recipe for re-inventing the bloat of the web.
You must first use, then understand, then change the software. You can’t skip steps one and two. It is possible to express yourself within these constraints (you’re already expressing yourself within some fairly arbitrary constraints right now, for instance, imposed by Lobsters’ strict markdown rules), and you should first apply a little bit of creativity to the new medium before you try to bend the medium to your will. We don’t really want it bent, we’re doing something different for a reason.
By the way, your comment can be losslessly represented in Gemtext.
I’d argue that this is because the problems it solves are inherently complex, so any good solution to it will be complex as well. That doesn’t mean I don’t think the web can’t be improved or made simpler – it’s an organically grown mess of 25 years – but it will never be replaced by a dead-simple solution such as Gemini.
And yeah, my Lobsters comments can be expressed in Gemini without much loss (except the inline links thing), but Lobsters isn’t my website though and I wouldn’t be able to express my fairly simple website on Gemini, or a fairly simple site as Wikipedia. And even the entire Lobsters website would be a worse UX in Gemini as it precludes any sort of design.
Gemini does not preclude any sort of design, not at all - it just gives the responsibility for design to the client, not to the server.
But isn’t this very limiting? Like, it would work for your blog, but in its current iteration adding a table would already be difficult, never mind something more advanced like the fivethirtyeight election forecast and results.
I suppose it all depends what your vision for Gemini is; if you want it to replace large parts of the web then it’s got basically 0 chance in its current state; if you just want some alternative to use yourself and like-minded people, then sure, go for it.
Of course Gemini doesn’t preclude design: It’s a networking protocol. You can use it to move HTML and JS and CSS and images and whatever else just fine.
Attempting to conflate a protocol with a document format is wrong.
The specification also includes a document format, as well as a networking protocol.
Arguably, things would have been clearer if they were separated out more clearly, but this would kind of defeat the point of Gemini. The networking protocol and document format are intended to be used together.
It seems interesting; to make it clear, I do hate tracking too, as well as inaccessibility & various Flash-equivalents of today. And dependency on the complexity tower of Chrome/Firefox/… So I’m certainly curious about alternatives to the current status quo.
I do understand that the protocol seems to allow for a lot of expression, and more “slow-food” style, relaxed consumption. Yet, I cannot escape immediately having a feeling of loss. If I understand this correctly, with no mathematical equations support, I would not be able to write or consume an article trying to explain Shor’s algorithm. With no graphs support, I assume whenever I’d want to display graphs, I’d have to resort to ASCII-Art as a workaround, with necessarily limited precision (for example, no smooth curves or complex 3D surfaces). Finally, I assume I would not be able to write or consume an article about typography, or bysantine icons. Or am I wrong?
Having the concerns mentioned above, I’m immediately starting to think about possible workarounds. I am assuming people would start resorting to “rich clients” - for example, with support for rendering of some kinds of mathematical equations. This, I am guessing, would quickly lead to on-site recommendations like: “This page requires support for LaTeX-Super-Renderer-3.7”. De-facto becoming in-band signaling of the kind Gemini apparently tries to dispell by “only allowing one field in response, the mimetype”. But wouldn’t people start doing that anyway, and start writing such plugins anyway, and start de-facto reinventing HTML anyway? With the likes of Flash plugins of yore raising from the dead in new clothes?
With regards to just graphs and images, I believe it could be somewhat easier actually. I am now reminded of the days of my childhood, when books in my country were mostly in black and white, with a few pages in the center being in color, and being referenced to by the b&w pages (“See illustration 7.b.”). I imagine something like that could work with images being listed, or linked, or attached (?) at the end of a Gemini page. But even then, I don’t think that would be usable for math-heavy documents. And from glancing through the few links around here, it’s not fully clear to me if any images at all, even at the end of a document, are expected to be supported? (Though mimetypes support kinda seems to hint at allowing this?)
So, with the ideal of simplicity sounding theoretically interesting and alluring, at the same time I’m concerned about losing access to, especially, maths-related content. (Assuming that some image-heavy, yet comparatively sparse in that regard, content could be possibly approximated with a list of image links at the end, referenced from the main article. Which kinda already sounds like a hack, that would probably soon lead to reintroducing inline images via specialized clients…) That feels like a pity to me.
I’ve brought this issue about math up in the past, but remember, nothing is stopping you from using HTML or PDF. Gemini uses Gemtext as a lowest-common-denominator form of markup, but if you are writing a client, you can always built in HTML support or shell out to something else that does.
I think that the reason that people keep trying to suggest features is that Gemini is marketed as a replacement for “the web”, but designed (and only useful) as just a plain text delivery mechanism - there’s (rightly) some cognitive dissonance going on.
That is, “the web” includes plain text, hypertext, rich documents, audio/video media, and interactive content. I don’t think that most people expect Gemini to implement the last two, but there’s some reasonable expectation that something trying to replace “the web” should at least be able to represent reasonably interesting documents - such as scientific papers, which Gemini clearly cannot.
Perhaps if proponents of Gemini stopped trying to claim that it could actually replace anything but the tiniest slice of the web that is pure, plain text (not hypertext, as inline links are really important), you would stop getting people talking about adding features.
Edit: that is, there’s no “preconception” going on here. GP post is responding to the argument that Gemini is a viable replacement for the web by pointing out that it is missing critical features for actually acting as a sane replacement, which has no “preconception” - it’s just a statement of fact. You cannot replace the web without inline links, formatting, or inline images, full stop.
As a matter of fact, you can. Full stop.
…that’s so obviously false that I shouldn’t need counterexamples, but here they are:
https://graphicallinearalgebra.net/2015/04/26/adding-part-1-and-mr-fibonacci/
http://foldr.org/mw/emacs/
http://507movements.com/
https://lobste.rs/
https://www.av8n.com/physics/clifford-intro.htm
None of these sites, or the majority of the thousands of other bookmarks that I have, can be replaced without inline links, formatting, or images.
Linked files do. Not. Cut. It.
Not only are linked (vs. inline) files objectively and meaningfully different (and, therefore, you cannot replace the web with them), but they are inferior from an information-processing standpoint. From both a practical and theoretical level, you cannot replace the web with Gemini as it currently stands. People will not use it, they are not equivalent, and I, personally, will discourage people from using it - it is a cognitive anti-tool, similar to a reverse printing press. Useful for implementors, terrible for anyone who actually wants to read documents and exchange information that will actually help them to learn and reason.
I can provide another counter-example: you had 5 links in your comment, none of which were inlined, despite having access to inline links on lobsters.
You can’t place identical content on Gemini as you can on the web. You can reformat your content for the new medium. Nothing transitions between mediums without change.
Gemini replaces a subset of the web, which I stated in the opening article and have re-iterated dozens of times.
…that’s not a counter-example. I never claimed that you can’t replace any of the content on the internet, which is what that statement would be a counter-example to.
Perhaps you should take a logic course.Edit: that was too aggressive, my apologies.Edit: I claimed that you cannot replace “the web”, which implies replacing the majority of the content at least, and all of the content at most.
…and, as it should be very clear, that re-formatting process is (1) lossy and (2) causes a significant decrease in readability and information processing - meaning that it is not a replacement. The format of the web is part of the web, therefore you cannot replace the web with Gemini.
You have tried to claim that Gemini can replace anything but the tiniest trivial slice of the web that is pure, un-hyperlinked plain-text - which, as shown above, is false. The format of the web is part of the web. The content and the medium are entwined.
Anything with “less features” is lossy, but that’s not correlated with a “significant decrease in readability”. On the other hand, putting the presentation entirely into the client’s control is a significant win for readability, because the user can configure fonts, contrast, and layout to their preferences and usability needs. The screen reader experience, for instance, is WAY better. Inline links and inline formatting are less accessible to some.
Only true in the most needlessly pedantic sense. You can easily build systems with a small set of carefully-chosen features that still implement the vast majority of the functionality of larger systems that were poorly-built. This…does not describe Gemini. Gemini picked a basis of features that do not allow it to implement more complex functionality or richer documents.
Not in general, sure - but in the case of Gemini, it’s pretty clear that there is a significant decrease in readability (and, therefore, cognitive processing ability). Requiring users to click through to a separate document for each image, animation, or individual mathematical equation is extremely unreadable for anything with a reasonable density of those things - while “only” being merely slightly less readable for documents with only a few of those objects.
You can already almost entirely control presentation with major browsers for the current web, through userscripts and stylesheets.
Moreover, HTML is actually structured, unlike Gemtext, so I have anchor points and document metadata that I can use to exert more control over my content than with unstructured Gemtext - so your statement is actually untrue.
Modern web gives you more options to make a good screen reader experience - such as image alt text. Is it really inconsistently used? Sure, but that’s not a technical problem, that’s a social one - a social one that manifests itself in an equally bad way with Gemini, because Gemtext doesn’t have any way to bind accessibility-related metadata to document structure, because there is no document structure.
Expanding links and controlling inline formatting are very basic features for screen readers.
So, to summarize, modern web gives you a much richer interface for screen readers, as well as a better interface for people who don’t use screen readers (which is the majority).
Gemtext is straight-up less conducive to thought and information transfer.
I think “significant decrease in readability” is interpreted a little too literally here.
Many of the documents linked by fouric would be way more inconvenient to read if they were adapted to fit in gemini’s limitations because of how heavily they rely on tables, anchor links to a specific part of the same document, and inline images (especially with how inconsistent most clients available today are at dealing with non-gemtext content types).
I personally am a big fan of how gemtext files only ever result in a single request due to the lack of stylesheets, scripting, and inline resources, and have pushed back on the adoption of HTML and Markdown as alternate document content types because I think that is a valuable part of the protocol. I’m also not delusional: the stance I hold also directly limits the mass appeal of gemini as a technology, because normal people who just want to read these kinds of documents are unlikely to accept what seems like massive inconvenience for technical reasons they don’t fully understand. They’ll just stick to the Web.
I am willing to put up with that inconvenience as a reader and writer of gemtext content because I think the other benefits of gemini are worth it, but I don’t expect anyone who isn’t another disillusioned Web developer to get on board quite as easily.
This isn’t quite true, is it? His comment included the clearly-delineated metadata of his name and the time, including an inline graphic element (his avatar) to aid the eye in scanning the page for it. Gemtext as currently defined precludes any such niceties because they are perceived as ornament by the early community (who ironically see a need for some headings, lists, quotes, and … ASCII art).
It also included a simple method for you to add a reply. POST is a slippery slope, but I hope Gemini someday gains a sort of Micropub.
(I am one of those $FEATURE users, where $FEATURE is inline images and metadata or some sort of “secondary” text. But I’ll finish building my capsule and client and see how things evolve.)
How would metafilter-style writing look, with lots of inline links? Examples appreciated.
You just wouldn’t have lots of inline links. You’d have a separate list of references, perhaps. Here are some examples of Gemini posts I have written with lots of links:
https://portal.drewdevault.com/2020/11/01/What-is-Gemini-anyway.gmi
https://portal.drewdevault.com/2020/10/22/Firefox-the-embarassment-of-FOSS.gmi
https://portal.drewdevault.com/2020/10/01/Spamtoberfest.gmi
Let me put it this way: how would inline links work in a newspaper, book, or magazine? The answer is: they wouldn’t, and you just work within those limitations. That doesn’t mean the medium is bad.
Not arguing against you, but when it comes to web browsers, then they still haven’t learnt to properly hyphenate text. Another thing we could do 150 years ago. One of the reasons (another being rather poor support for rendering maths, or, in the case of Chromium, complete lack of it) I’m relieved whenever I get to read a PDF generated from LaTeX instead of a webpage.
You can manually hyphenate with soft hyphens like you did 150 years ago just fine.
Automating hyphenation is nearly impossible. LaTeX certainly requires some manual help.
If I use soft hyphens, then copying
He­re are rhi­nos.to terminal results inHe re are rhi nos.visually, because it copied the text with the soft hyphens even though everything was on a single line.It never required it when I used it. When you enable correct language support, it should just work.
That’s because your terminal is 1970s computer technology.
No. That’s because I copied text, but received bytes instead.
FWIW it doesn’t happen with
hyphenate: autoin CSS, but that’s only supported by Firefox, so it’s irrelevant.150 years ago you couldn’t copy manually-hyphenated text from your newspaper in to your terminal.
I thought this analogy was cute for a little bit. But seriously, why is 150 years ago the standard? Are we really that painfully nostalgia-blind that we can’t recognize there’s a medium point between the old and the new?
It isn’t my standard, and frankly I don’t really care what we could / couldn’t do 150 years ago because I don’t believe it matters in the context of what are we doing, trying to do, and can’t do today.
Firefox does hyphenation with
hyphens: auto;if you set the document language.Does Gemini support setting the document language?
A quick search on the specification shows it does. So hyphenation working on gemini or not would be a matter of the client implementing it.
Well, 150 years ago it was a manual process, and not an automatic one :-) I regularly insert
­for this on my website by the way. But yeah, I agree that the lack of a universally supportedhyphenate: autohas been long overdue (only Firefox supports it, and it doesn’t even do a great job at it, although I don’t know if there are technical reasons that prevent it from doing a better job; I think I saw someone on HN detail some issues with automatic hyphenation on the web years ago, but I forgot what they were).Math rendering has also been supported by Firefox for 15 years with MathML, but for some reason Chrome doesn’t (but Safari does). Actually, looks like they removed it in Chrome years ago, although it looks like there’s work to add it back soon-ish.
Actually, along with Firefox, some versions of Chrome (Android & Mac) support auto hyphenation, and Safari has it hidden behind a prefix: https://caniuse.com/css-hyphens I feel that together these may cover enough of the market to make it worth adding to web pages.
If you want to see a quick and stupid demo, here’s my very unfinished Hugo theme I’m working on developing: https://www.maximumethics.dev/blog/2020/07/my-first-post/ If you shrink the viewport width until it’s skinny like a phone, you’ll see the longer 90 chars “alphabet” line break to hyphenate (on the aforementioned supported browsers), as well as random words in the text.
Ah yeah, it’s just the desktop version that doesn’t support it for some weird reason; I forgot about that detail.
I suppose it depends what you use it for: most of the time I really wanted auto hyphenation is for comparatively narrow pieces of text and/or for
text-align: justify(e.g. a sidebar or info box). In those cases the hyphenation (manual or automatic) is pretty much a must-have rather than a nice-to-have, because without it it just looks ugly. Your site, on the other hand, looks fairly decent without hyphenation even on smaller screens, but it won’t hurt to add it for browsers that support it.That’s what I was on about. If something isn’t available in Chrome, it’s irrelevant these days. I’ve been aware that “it looks like there’s work to add it back soon-ish” for quite some time now. I don’t have hope.
I think the idea is that the publisher delivers only the information, not the presentation. This constraint allows for greater user control over presentation, for example one might configure Gemini to lay out news articles (maybe on a site by site basis) in a column style, to suit their preferences. I think it’s an interesting idea as a way of making better typesetting more widely available to content published on sites without the budget / know-how to tune their CSS for readability.
I agree that Gemini would be better off if it supported inline images. That’s pretty often part of the information layer.
Wait! That is HTML! (as compared to PDF)
Not really, HTML still focuses a lot on presentation. Headers, side bars, footers, nagivation line, footnotes, etc. are all concepts foreign to the browser, that have to be manually re-implemented in the markup language, again and again. That’s actually what I think that protocols like Gemini misunderstand: HTTP/HTML is not too systamatically complicated (at most it’s “organically” complicated), it’s actually too simple. If for example the
<head>section had made it possible to describe how a web-page is navigated, it would have been possible for the browser to render that part of the site, leaving the<body>to be actual content. It’s something you see with other simple languages too: Scheme has various implementations, that implement a common core, but diverge in their additional libraries, that are regarded as useful, but do not allow for code to be portable. So too, had HTTP/HTML has the foresight to recognize what people would want from websites (which is probably too much to ask), or at least the foresight to allow a certain degree of extensibility, a lot of implementation-specific complexity could have probably been avoided.So the issue might not be “simplicity vs compexity”, but “what kind of complexity”.
Years ago I came across a browser extension that would build a navigation bar if it found certain
<link>tags in the header. I modified my blogging engine to automatically add said links. Sadly, the extension no longer runs (because of course the extension mechanism changed—at least twice—since then) but I still generate the data in the vain hope it’ll be useful again.A strict separation of information and presentation is something that sounds great in theory, but doesn’t really work all that well in practice once you move beyond the simple use cases, or use cases that are pre-defined and supported in some way.
I don’t know if this was part of the design goal - from what I can see, Gemini doesn’t have any sort of mechanism to describe or annotate what content/information is being delivered, which would make any presentation strategy necessarily heuristic, as there would be no way to delineate e.g. where the “author” of the article is.
I guess you’d just put that information into the document itself.
One underappreciated tag in HTML is the
<address>tag, which is a nice place to put stuff like author, publication date, etc.I’m not quite sure what you mean - when you say “just put that information into the document itself” do you mean in a machine-readable format? Because if so, that’s not part of the Gemini text spec - which is the thing being discussed. Adding tags like
<address>would be extending the Gemini spec to add features, which is what proponents of it are fiercely against.No, I just meant to add something like
in the body of the text somewhere.
As it has been stated on the mailing list, “you can always serve up text/html or text/markdown, you aren’t limited to text/gemini.” There are sites out there serving up images and even music.
Well, that’s not really what’s advocated for in this post (or on the Gemini website as far as I could see), and serving HTML over Gemini just sounds like a
s/HTTP/Gemini/, and you can serve text or Markdown over HTTP as well. I don’t really see the point if you’re going to serve HTML over Gemini.I’m sick of how complex html+css+js gets, and how complicated extracting the actual content can be, in order to view it on “unusual” platforms (small screens. ereaders, etc.), where a good experience depends on the client controlling the presentation of the content. Something like gemini could be the solution to that, but I have to say, the lack of inline images is a deal-breaker for me.
I view multi-column layouts as part of the presentation, not the content (I don’t want two columns of text on a phone screen: if I do want two columns of text on the desktop, I can write that into the client), but the images are part of the content.
I did wonder whether technically a gemini-ish client could fetch urls which look like they point to images and display them inline, but this is explicitly banned by the specification:
I can sort of see what they’re aiming for, presumably trying to avoid the sort of nonsense some websites have become, where the initial request just gets a jumble of html elements that require the client to fetch and execute tons of javascript before they can be assembled into something resembling content, but I think they should have made an exception for images (They could still leave it up to the client whether it displays inline images or not).
Interestingly, gemini probably works really well with screen readers, until you get to an image link (or any link for that matter), at which point it depends entirely on whether the author bothered to provide a caption, or explain what the link is as part of the text (Although that’s arguably no worse than html, where the existence of alt text doesn’t mean that it is always used or used correctly).
Another reason to not allow non-user-initiated network connections is that’s abused to track users (Facebook pixel etc).
IMHO this could be sufficiently solved by allowing additional requests to the same domain as the document request.
One big reason I’m excited about Gemini is the possibility of escaping the web’s bloat, which we need to do in order to reduce energy usage / emissions in the climate crisis. For this reason, I support Gemini’s decision to ban inline images. If you have inline images, next people will want inline video, and soon even if Gemini is “simpler” it’s using as much storage+bandwidth+processing as a web page.
Inlining images, especially from other locations, is also a plausible method for sneaking user tracking back into the protocol, and I also approve of Gemini’s strong efforts towards privacy. I also hate ads even when they don’t track people, I’d love to live someplace where billboards are banned so I can escape the constant background hum of marketing. Eliminating inline images is also a great way to reduce the annoyance of advertising.
I’m going to have to agree with everyone in this thread that refusing to implement inline links was a mistake, though. That was one of the biggest problems I had with Gopher, and I was hoping Gemini would do a better job with hypertext.
It’s a very difficult balance to strike between simplicity and functionality. You could probably avoid trackers by, as @m_eiman says, only allowing additional requests from the same domain as the original document.
Alternatively, you could create/use a format which embeds the images directly in the original document (similar to how pdf or epub does). Some might argue that this is inefficient, as you need to serve multiple copies of the image data if it appears on multiple pages. However, in this context, it could be seen as a feature, as we don’t want the kind of images (such as ads) which aren’t actually “part of the document”.
There will always be some people who abuse any protocol, but not having inline images is very limiting and means it isn’t any good for a significant portion of (what I consider) “good content that doesn’t need javascript/css”.
I’m just going to drop a link to the FAQ page, in the hopes that it’ll answer some questions here.
Might I ask what’s wrong with merely providing a link to the image?
This can be easily done with some ASCII art (which is what you do for Markdown, anyways) coupled with a preformatted block.
But ASCII art is pretty much the quintessence of mixing presentation and content, which is very specifically what Gemini seeks to avoid. It can’t wrap or scroll differently on small devices, it can’t be extracted (easily and reliably) to a machine-readable data format, and it isn’t accessible because there’s no semantic information about the table structure.
You’re right. I kinda hope some kind of table syntax does make it into the Gemini spec after all.
I need to click a link to an image? It seems pretty obvious to me that this is worse UX than just displaying it.
ASCII art relies on a monospaced font, which I don’t really like for reading text. I think Lobsters would be significantly worse if it was all monospaced text for example. It also relies on a certain screen size, which doesn’t work for smaller screens (or very big ones, for that matter). I mean, it kinda works but it’s a hack.
Yeah. You’re completely right, this is worse UX. I’m beginning to think of proposing an inline-image syntax for the gemini spec.
I admit I was wrong. ASCII tables are a hack, I suppose. Hopefully the simple table syntax I’m thinking of right now makes it into the spec!
FYI there are gemini clients that support variable-width fonts.
I tried to use it with Gopher years ago (I hacked up an existing client), and many sites don’t really work all that well because they assume stuff will be displayed as monospaced text (such as tables you mentioned, but also things like code examples, or other alignment things).
Gemini is a bit of an improvement because the spec at least recognizes that proportional text exits and has “code blocks”, but it also leaves much to the clients. In other words: I wouldn’t be surprised if people would just keep using it as they used Gopher, and the weird (and IMO, broken) way line wrapping works in Gemini doesn’t help either. I suppose time will tell how it will be used in practice (but as mentioned, I don’t think it will be used much in practice beyond a few “Hacker blogs” like Drew’s).
One of the big mistakes of HTML was, ironically, to “leave it up to the clients” which resulted in a big mess which had to be unified so that people could get a reasonably consistent experience irregardless of which browser they use, but that just unified the mess instead of clearing it up.
I use HTML to add tables to my Markdown content.
I personally find HTML’s table syntax difficult to read and use.
Yep, I usually whip up a quick Perl script with the (deprecated)
CGImodule to generate it from plain text ;)Gemini is only a protocol, but the specification also propose a basic text/gemini format as a de-facto document type. It however supports any mimetype, including text/html:
You could totally sent the following HTML document over gemini:// and enjoy inline images:
It would then be up to the gemini client to process this document, fetch required resources (the cat picture) and render it nicely for you. The advantage of the gemini protocol here is that it would put a limit on the HTML subset one could put in a document. For example,
<form>tags won’t be any useful. There would also be no need for<script>tags, as they wouldn’t be able to “phone home” over gemini.One of the biggest problem of the web is that the HTTP protocol itself grew in an enormous monster that’s impossible to understand, where sometimes the headers of a requests can be 10 times bigger than the content itself.
I’ve been reading the Gemini specification, as well as this post, and my conclusion is that it’s just a worse version of HTTP 1.1 and a worse version of Markdown.
Strong disagree. TLS + HTTP 1.1 requires to perform a upgrade dance involving quite a few extra steps. The specification is also pretty empty regarding SNI management. Properly implementing that RFC is pretty demanding. There’s also a lot of blind spots left to the implementer better judgement.
In comparison, the Gemini TLS connection establishing flow is more direct and simpler to implement.
TLS aside, you mentioning
sounds like a clear win to me. The baseline HTTP 1.1 RFC is already massive let alone all its required extensions to work in a modern environment.
I agree that the specification is simple to read, but the specification itself is too limited and don’t find it suitable for the real world.
For example, I prefer HTTP’s optional end-to-end encryption because when working with internal routers within an infrastructure dealing with certificates is a PITA and a completely unnecessary bump in complexity and performance overhead being inside an already secured network.
I also disagree on that “extensibility is generally a bad idea” as the article says. Extensibility can work if you do it properly, like any other thing on software engineering.
EDIT: Or the requirement of closing the connection and re-opening it with every request, and all the handshakes that means.
For clarity about what I think could be an actual improvement: I would prefer an alternative evolution of HTTP 1.0, with proper readable specs, test suites, clearer https upgrade paths, etc; instead of an evolution of Gopher.
TLS + HTTP just requires connecting to port 443 with TLS. I’ve worked on lots of things using HTTP for >20 years and I don’t think I’ve ever seen the upgrade protocol used in real life. Is it commonly used by corporate proxies or something like that?
When I looked at it (months ago), I got the same impression. I find this article irresponsible, as Gemini does not merit the support.
Gemini’s intentions are good. The specification isn’t. For instance, not knowing the size of an object before receiving it makes it a non-starter for many of its intended purposes.
This is an idea that should be developed properly and openly, allowing for input from several technically capable individuals. Not one person’s pet project.
I’ll stick to Gopher until we can actually do this right. Gemini doesn’t have the technical merit to be seen as a possible replacement to Gopher.
It does accept input from individuals. I was able to convince the author to expand the number of status codes, to use client certificates (instead of username/password crap) and to use the full URL as a request.
I prefer to think of Gemini as a better version of gopher with a more sane index page format.
… and this is where he loses me. Gemini is a network protocol. It doesn’t force you to send any specific kind of documents in response to requests. That means it will be used to send any kind of document whatsoever the moment it gets at all popular, and lose whatever properties the non-HTML hypertext format has which make it so attractive to him when everyone else uses Gemini to send HTML with CSS and Javascript and, oh yeah, images and videos. There’s a reason Web browsers caught on in the first place: They could speak multiple protocols and parse (or otherwise handle) multiple kinds of document. Trying to confuse and conflate a protocol with a document format is, therefore, fuzzy thinking which grates on me.
I don’t get this at all. For those folks who want to have super simple layouts and no styles, you can do that with HTML without any problems. In fact, you can just ship plaintext to the browser if you really want. I saw the argument of “how do newspapers, books, and magazines do inline links” and I wonder if I’m in the same reality. The digital space is NOT the same. Those things don’t even have links. There’s really no comparison between them other than they can both have text.
This doesn’t even seem niche, it just seems idealistic in all the wrong ways. The web doesn’t exist as it is today because it sucks. I can’t even imagine trying to create a forum like this on a limited protocol like that. And instead of working on bettering the state of browsers, people pour energy into things like this that are basically hobbyist displays of protest. Do what you want with your free time, it’s your time, but I can’t imagine anything like this ever growing in real adoption. It’s not even a step backward since you can do all of this stuff in plain html anyway. It’s just silly.
Gemini is a strangely coupled project. Everyone who loves it seems to do so because they hate HTML5+CSS+JS (or at least those things as implemented and used by “modern web”). Fair enough. But then the first thing Gemini does is define a new document retrieval protocol – one that is almost identical to HTTP. Now, if you hate HTTP, that’s interesting, but no article I read about Gemini talks about problems with HTTP. The Gemini protocol can be used to serve an HTML5+CSS+JS mess if you like, the only thing preventing that is the community of people who want Gemini don’t want that and so they won’t use clients that work well with it etc, etc.
I’m 100% behind the ideas that people who love Gemini want to see move forward. I just feel like the goals of the whole project are a bit muddier. If the goal of the protocol is to make the pages unusable by the unwashed masses, I guess that makes some sense, but then you’ll have to work hard to prevent it from becoming popular and going endless september all over you some day. If the focus is on simpler hypertext formats, then why not focus on the format and deliver it over the myriad of existing protocol options (including HTTP, just for simplicity).
There’s a lot of posts in Gemini space that talks about this and some posts on the mailing list as well. These posts just aren’t on the Web though.
The issue with
HTTPis that it can leak enough information to allow easier tracking (user agent, language preferences, etc.) and can be quite complex to implement (partial content, pipeline connections, caching, proxying, HTTP/2 and now the upcoming HTTP/3 which requires a custom lower-level protocol). Solderpunk wanted a protocol (and a text format) that was easy to implement over a weekend.But we’re talking about building all new clients at least, and for Gemini also servers, right? So no need to send all that extra junk or use those optional features if you don’t want to, just plain old:
and reply:
This is, I’ll grant, a few more bytes than the Gemini protocol if these are the only features you ever want. However, I’m not sure it’s enough more bytes to bother breaking compatibility over.
I spent a couple months poking around this ecosystem and had a great time. Blogs on Gemini are personal, and an interesting mix of people after self-selecting for tech interest. It feels like early Livejournal.
Early Livejournal is not something I’d consider an endorsement
Your distaste is hereby acknowledged, but this was more of a characterization than an endorsement. Gemini doesn’t intend to be for everybody.
Why would one other Gemini over gopher?
There are several advantages. I’m going to quote the FAQ page:
it really doesn’t offer anything over gopher. pulling in the whole mess of TLS isn’t the right way to ensure document integrity IMO.
By allowing links within content pages instead of separating content from menu pages, Gemini acts as hypertext. You can have that always going forward, losing yourself in Wikipedia kind of experience. You don’t constantly hit dead ends; sites are naturally more interlinked.
As much as I’d like to have a simpler alternative to the web stack, I think Gemini is a bit of an extreme in its approach. Ideally I’d like to see a protocol closer in functionality to the web of 90s (functionality != tech stack, so maybe not even HTML) with a federation support built in. Decoupling presentation from data + disallowing code execution on a client side would already be a MAJOR factor to simplify the client.
I can’t find any mention of input or interactivity in Gemini. Is it possible to build something like lobster.rs or wikipedia?
A page can request user input in a single text field, which has the semantics that the same page is re-fetched with the contents of the input field added as a query parameter (see 3.2.1 in the spec). So far I’ve seen this used for: 1) search boxes, and 2) text input to interactive fiction games.
I don’t think it’s designed for more wiki-style editing where the entire document itself is edited in the same viewer.
Just like the WWW in 1994. If Gemini catches on, it will quickly (d)evolve into the web of 1996.
I read a lot of text in my browser and I find variable-width fonts easier to read. Anything which wants me to do this reading in a fixed-width-font terminal I’ll ignore.
That’s understandable – I also find variable-width fonts easier on my eyes! There are, however, a bunch of non-terminal clients that can use other fonts, such as Castor.
At least on my machine, Castor hangs when opening a resource outside of Gemini (a [WWW] link, specifically).
Last night I’ve written a gemini-server in 100 bytes of sh/netcat as a challenge (it expects the status line inside the file to serve; $G is the directory to serve).
and a netcat based client, retrieving the non-golfed version:
It’s running on gemini://zeta.gir.st (until the next server restart; I don’t plan on using gemini for the reasons arp242 has mentioned).
I implemented my little website (gemini://caioalonso.com) this weekend after reading Drew’s article, as an attempt to understand Gemini a bit more.
The Web is overly complex and has endless scope–and it can be said that this is because society is endlessly complex–but we don’t seem to agree on the scope of this new, small Web. Everyone has a different subset of the old Web in their minds as what is the Ideal. If we use the subterfuge of saying ‘well anyone can deliver any MIME type they want’ then we’re just moving the complexity to having many different parsers or a single parser (like the traditional Web browser) that can display (and compute) anything and we’re back to the same problem. If we don’t define and accept scope then the final scope will be Turing completeness because that is the underlying feature set of computers.
How can we objectively say that we’ve got enough functionality? Will it ever be enough?
I think that implementing a stripped down “web forum” like this very site would be a good test for Gemini.
There are several Web forum implementations out there, and there’s a Wiki that sits atop Gemini.
Links?
This post is an excellent introduction to Gemini. I can understand all the opposition against the idea (too simple, too limited), still I am excited about this new development and I can see the whole new world beyond.
The page I am brewing right know, will definitely have Gemini version.
I don,t understand how this is better than 20+ years of http with countless interchangeable implementations of each layer (http, html, js, cgi, access.log, ssi)
it,s an amazing stack if you use it in more established ways.
can we build something like Web 2.1, with all the kinks of basic css worked out, reasonable js like getElementById, basic dom… and code for every browser including links and nojs?
Here are some of the issues with a subset vs a new protocol.
The comments on this story are an excellent example of this phenomenon.
It’s a huge burden for one person but sharing the task means lots of interminable discussions about what to include/exclude.
I disagree with some of the Gemini design decisions but think that defining a new protocol was the right call.
I wonder what the rationale for not allowing inline links is.
I’ll just quote the Gemini FAQ page:
Thanks for linking to the rationale!
I agree with the points of this blog post, and with the mission of Gemini’s “radical simplicity” – it very much is a technical implementation of some of the early-twentieth-century art movements like Oulipo or De Stijl, where constraints forced a novel imagining of creative pursuits.
I’ve also heard the originator of the project describe Gemini as closer to Gopher than HTTP – so that helps to explain the design choices made.
I would have preferred the post itself to emulate gemini to a degree. E.g. no inline links, no styling.
You can view the post through the Gemini HTML gateway.
Or via another Gemini HTML gateway.
Excellent! Thank you!
Gateway seems to half broken, I am often getting
Gateway error: EOFWorks after some attempts.
I proxy to my gemini capsule from HTTP for my main website. With a touch of styling (and a little patch to go-gemini to allow inline images to be displayed) it’s more than adequate for a website as well
Litmus test; would https://sr.ht be implementable in Gemini?
I am not 100% sure, it’s possible that the TLS client certificate makes it easier to track people. The client would have to support selecting which identity to use for a given website at the minimum.
No but that doesn’t necessarily mean it is reliant on the web. A large portion of sr.ht operations can be done from email
I don’t think so; Gemini is for transmitting documents, not for creating web applications.