
A look at the Gemini protocol: a brutally simple alternative to the web - flatlanderwoman
https://toffelblog.xyz/blog/gemini-overview/
======
bluefox
It feels like the main feature of this project is incompatibility with HTTP.
The protocol is new and primitive, it's easy to write tools around it, write
texts about it, etc. A small community forms, and you're part of it. You can
advertise it to others, or rant against the mainstream, or whatever. But now
what? You lose interest and abandon it, and eventually it dies.

We already have a transport protocol that "everybody" agrees on: HTTP. We can
define a specification for a subset of it, and a subset of HTML/browser
features we want, create tools around them, and form a small community.

The advantage here is that the community is not an island. Users of Big
Browser can still read your latest rants. They can even learn about this
project and, while perhaps not using Mom-and-Pop browser, may support it in
their sites, since it wouldn't require another server; mostly just having
their site work without JavaScript would be a huge step forward. Right, you
don't have Google filtering based on Accessibility. The community can create a
search engine that does. Now what? You just get on with your life, producing
and consuming AccessibleWeb content without the gratuitous incompatibility.

~~~
ozim
I totally agree with that. It is not like some web police force is holding
people at gunpoint to add javascript and angular or react. People use all
those features because they want to and they find it useful.

~~~
loup-vaillant
There kinda is?

While web sites can avoid JavaScript all right, browsing most sites does
require JavaScript. As a NoScript user, I'm keenly aware of how many web sites
simply _do not work_ without JavaScript.

And I'm not even talking about all the third party spyware.

~~~
JamesLeonis
I had to give up doing this. I couldn't manage all of the different times
websites broke over just CDNs. Lord help me if the website is Ad driven.

I encourage every web developer to try running NoScript for a week. You will
find it enlightening.

~~~
jhardy54
If you're already using uBlock Origin you can disable JS per site (or by
default, like NoScript). I've found that the UI is _way_ easier to understand
compared to NoScript.

~~~
ta5hkv56f
uMatrix is similarly excellent (finer grained control I think is the
difference).

For frequently visited sites you can save which bits you want to allow so its
not as onerous as you'd think.

Blocks Google Analytics and Facebook's poison by default.

------
avian
> Blogs, [..] are perfect for the Gemini format.

> Gemini lacks in-line images

This is the only part that I don't really understand about Gemini. Even the
most basic printed publications can include illustrations. <img> got added to
HTML very early on because sometimes it's hard to share some piece of
information in anything but a visual form.

I write a (mostly) technical blog that certainly focuses more on text content
than images. I would be happy to throw away the header, sidebar and the rest
of the "design" cruft (in fact my blog is perfectly usable in a browser that
doesn't support CSS or Javascript) But I can't imagine having my posts without
graphs, diagrams and photos inserted in the text.

If the fear is that in-line images would lead to frivolous use as ads or
"useless multi-megabyte header images", then maybe a better approach would be
to limit the number, or size, of images on each page? Some scientific
publications do exactly that in an attempt to force the authors to focus on
selecting only the most important images that need to accompany their papers.

~~~
sloum
The lack of inline links is less about aesthetics and more about
predictability. When you request a gemini resource you know that there will be
two things happening: a TLS handshake followed by, hopefully, the server
response (hopefully with your requested document).

Adding images requires more requests and breaks the concept of "one
url/document == one request". I love that I know that my client will do
nothing I do not tell it to do.

If you want to use gemini and you want inline images I believe
[https://proxy.vulpes.one](https://proxy.vulpes.one) does inline images of
some form or other.

That said, images have other issues beyond causing page loads/requests to be
unpredictable: they are an accessibility nightmare (as we have seen on the
web).

~~~
troupe
> they are an accessibility nightmare (as we have seen on the web).

Audio is an accessibility nightmare for people who can't see, text is an
accessibility nightmare for people who can't see or people who can't read,
German is an accessibility nightmare for people who can't speak German.

At some point we have to accept that not every way something is presented is
going to be equally accessible by every person, but the solution isn't to just
decide we should jettison a rich form of communication because there is a
small subset that can't fully benefit from it. Even books that are expected to
be used by people who can see all the images usually describe the purpose of
the image, what it is illustrating, and why it was included.

------
efitz
A large part of HTML, and a large part of modern browsers and other web
technologies, are focused on ensuring that the publisher has control over the
user's experience. I really like the fact that Gemini breaks that, and I hope
that the project owners mercilessly reject any attempt to introduce features
that allow the server to control or influence user experience.

I would really like to see structured text that is self-descriptive (e.g. this
is the document title, this is a paragraph, this is a header, bullet list,
etc.) but have no ability to influence HOW those things are displayed-
eventually maybe we'll have browsers that can support rich theming, etc.

Others have noted that lack of images is an oversight. Perhaps the language
needs a "binary file download" structure, and if the binary in question is a
media file, then the browser could choose to display it. Maybe signal with
mime types?

~~~
yoz-y
> A large part of HTML, and a large part of modern browsers and other web
> technologies, are focused on ensuring that the publisher has control over
> the user's experience.

It's also the reason why it caught on. On one hand people reject the ability
to express individuality on the web, on the other a similar crowd is nostalgic
about geocities and praises similar revivals. It's either one or the other.

> I would really like to see structured text that is self-descriptive (e.g.
> this is the document title, this is a paragraph, this is a header, bullet
> list, etc.) but have no ability to influence HOW those things are displayed-
> eventually maybe we'll have browsers that can support rich theming, etc.

How about publishing markdown over HTTPS? Then make a client that renders just
that?

~~~
contextfree
Why's it either one or the other? You could have one browser application for
no-nonsense textual or informational pages and one for wacky personal
geocities/myspace style pages. Feel free to enjoy both, either separately, or
if you want more integration you're free to use the underlying OS shell to
switch between them, read them side-by-side, link between them, etc.

~~~
yoz-y
> You could have one browser application for no-nonsense textual or
> informational pages and one for wacky personal geocities/myspace style
> pages.

Hence the idea of a separate markdown only browser. I don’t think http is the
problem here. So it would be better to reuse as much existing tech as
possible.

Note: Personally I don’t think it would catch on, the convenience of handling
everything in one program is just too high.

------
tylerchilds
I'm a Gemini newb, but I've enjoyed using the AV-98 client so far:
[https://tildegit.org/solderpunk/AV-98](https://tildegit.org/solderpunk/AV-98)

If Gemini sounds like a dumb idea, I'd highly encourage you to move along. If
Gemini sounds intriguing, you'll probably have fun.

Lots of opinions in this thread, but doesn't look like many armchairs have
tried it. Personally, I've enjoyed the rabbit hole.

------
mattlondon
I feel like the lack of image support is a missed opportunity.

I know it is an idealogical choice to _only_ have text, but being able to
embed standard image formats (on a totally plain, non fancy way) would
increase the utility of this hugely. They mention blogs and tutorials and
recipes here - those would benefit hugely from having simple inline images
within the body of the text, just like you expect in a newspaper etc.

I guess I am not the target market then.

~~~
Taikonerd
I understand why they didn't allow inline images, but I agree with you it
limits a lot of use cases.

If I were designing it, I would say: "you can have images, but they always
display as a 'block element', with nothing to either side. No worries about
wrapping text; no background images _under_ other elements, etc." I think that
keeps the spirit of simplicity.

~~~
lal
you can have images and they don't always display as anything. the author of
the user agent decides how they are displayed. you could in-line them if you
wanted to, but only a few clients do that at the moment. there are no hints to
the client about how some content could, should, or should "always display
as".

It's text. The client displays that text and renders links, headings, etc,
however it wishes. If it really wants to, it could just not format them at
all. There's a gemini client made for plan9's acme text editor that doesn't
render links, and instead displays them verbatim, because the plan9 plumber
can handle the hyperlinking aspect. All of that is eye candy and fluff.

If a client finds a link to an image, it can in-line it if it wants. If you
wrote a client, when it found a link to an image, it would in-line it "with
nothing to either side." That's not something that has to be specced.

------
vbezhenar
I would take an alternative position in this matter. What we need is a simple
yet functional subset of web. The point is to be able to build a browser in a
reasonable amount of time with many languages reusing some commonly used
libraries, while being able to use latest Chrome to browse those websites as
well.

TLS: keep it as it is. Crypto is hard and TLS is proven crypto. Mandate
something like 1.2+ and be done with it. Every mature language has TLS
implementation or bindings.

HTTP: use subset of HTTP/1.1. Parsing is very easy: it's just bunch of lines.
Full HTTP/1.1 is hard and probably unnecessary. Things like connection reuse
are not necessary and should be excluded for simplicity.

HTML: use subset of XHTML. It must be valid XML, so parsing is just one call
to the XML library which is available on every language.

CSS: I don't really know, that's a tough one. Something like CSS 2 I guess.
There must be a balance between complexity of implementation and richness of
presentation.

JavaScript: just nope. That rabbit hole is too deep.

If you take this position to the extreme, you can even reduce HTML + CSS to
some kind of markdown-like language, but I don't think that we need to go that
far.

~~~
acdw
Honestly, you've just described about 95% of gemini exactly. It's TLS required
(even 1.2+), line-based parsing with text/gemini content, it's actually even
simpler to parse than XML, since it's line-based (just peek at first 3
characters, you know the line type from that). It doesn't use CSS or JS at
all, styling is totally up to the client.

So like I said, you've basically just described gemini :)

~~~
vbezhenar
The difference is you can't just open Gemini protocol in the browser, so
you're limiting audience of your resource to a very minority. That's what I
want to highlight: something that is compatible with modern web, yet simpler
so alternative browsers could be implemented.

~~~
acdw
You actually _can_ open Gemini in a web browser, using a proxy like
proxy.vulpes.one or portal.mozz.us. I tried to write a Firefox extension a la
OverbiteWX for gemini to automatically redirect links, but my JS-fu isn't
strong enough.

------
ketzu
I think calling gemini an _alternative_ to the web has a very limited view of
the web. It takes an idea someone has of what the web should be: a set of text
documents. That's a very small subset of the web, not just of today.

Building separate protocols for all the various use-cases of the web would be
interesting, but would still need some interconnection. But I'm not convinced
that has many advantages besides not being accidentally linked to a websited
of the "Old web." A problem that could be reduced by a browser extension that
strictly blocks any external urls and javascript.

~~~
kristopolous
The separate protocol for everything is essentially what things were like
prior to about 1994.

There was a protocol for searching documents, a protocol for looking up
someone's email, it was all partitioned out.

The web was seen as just another fish in the pond.

After the web became big, these things still lasted for a while

However spam and crooks changed it all. Usenet became useless, DNS full domain
lookups (you used to be able to get a list of all the subdomains of a domain
through the command line and you could just browse then out of curiosity),
using whois for email (you could just query for a name and get an email
address over whois), it's all gone because there's too many snakes trying to
scam people and flood the network.

Things used to be much better tools but it turns out they were too good and
had no defenses. The dream of everybody connecting has sort of been retracted
a bit. RMS, TBL, Torvalds, I could just send them an email in the 90s and
they'd respond, it was pretty remarkable.

It's not the case any more. Not even minor players in history (such as an
author from a 25 year old book) respond to my questions. People just don't do
that anymore.

Spam, harassment, criminals, ill will, this all has to be a big priority if we
want to try it again.

The future should be the dreams of our better angels, building better
tomorrows...

~~~
cortesoft
> RMS, TBL, Torvalds, I could just send them an email in the 90s and they'd
> respond, it was pretty remarkable.

I don't think this stopped just because of spam, harassment, or other bad
behavior. A big part of it is just community size. When the community of
internet users was smaller, you could interact with everyone who reached out
in a reasonable amount of time. As it got bigger, that is no longer possible
because of the sheer number of people.

------
ehnto
The web is partly broken due to the sheer expanse of it. The author of the
article alludes to how they enjoys looking at the aggregator, and notes they
can always find something interesting. If Gemini ever became as popular as the
web, that would stop being true.

So the selling point of Gemini is that by staying rudimentary, it can limit
it's appeal, and subsequently stay unpopular enough to be more like "The Old
Web". I think that's worth noting, because you could get trapped into thinking
this is a technology problem, but it's really a people problem.

~~~
dancek
You have a very good point.

However, Gemini does not exist in a vacuum. The web will be there. There will
be social media platforms, multimedia, awesome webapps and all that. And
Gemini is just text.

When you have the choice between easily consumable infinite multimedia and
_just text_ , you only pick the latter when you really care about the quality
of text content. It's not sexy so all the spammers, content marketers and ego
boosters have nothing to gain on Gemini. And so there can be this esoteric
little corner of the internet, with down-to-earth text content written by
ordinary people.

------
pacifika
This is hard to understand for someone not familiar with Gopher, but I’m
interested in how menus are handled.

I’ve always wished browsers handle site menus in their chrome, so that the
document can be focused on content not navigation. It’s the browsers job!

For a while Opera supported these related links in the head for some pages but
the dev was unable to add their own, it was limited to a small number of
standard items such as Index. These were shown in a browser toolbar.

Nonstandard navigation have always been a point of friction for users as it
precludes universal access by having to relearn how each site works.

~~~
vertex-four
Gemini documents can contain lines that are text or lines that are links - so
a menu looks like a list of links, one per line.

------
msla
I guess I don't understand this:

How is a network protocol proof against being used to transport CSS files?
Does the network stack inspect what you're shipping and ensure you're only
sending 100% Pure Plain Text?

> The Gemini transport protocol is unsuitable for the transfer of large files,
> since it misses many features that protocols such as FTP or HTTP use to
> recover from network instability.

Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?

Finally:

> Now, what does Gemini currently have to offer? The best way to find out is
> to head over to the official site: gemini.circumlunar.space in your Gemini
> browser.

Back in the Gopher days, my "Gemini browser" would be my Web browser. That was
one of the reasons Web browsers took off: You could use them to access all of
the information on the Internet, including the WWW, Gopher, Usenet, and Email.
Only more recently did Mozilla morph from the Netscape Communicator software
suite into the slimmed-down Firefox browser without email, spinning off
Thunderbird in the process, and only _much_ later did Firefox drop Gopher
support from the core binary.

~~~
zuppy
> Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?

maybe he’s talking about higher level features, like the possibility to
restart a download from a certain point, without redownloading the initial
part? haven’t used this since dialup days, though

~~~
ivanstojic
I suspect that it is this partial download that they are talking about.

That said, I can't tell whether or not I've used it recently. I know I don't
use it when I play with personal projects, but I don't know what other sites
do because I rarely have a console pulled up in my browser when I'm just using
it, rather than developing.

~~~
bawolff
Its often used with bulk file downloads (e.g. curl a multi-gb file while
transfering between wifi networks), as well as video streaming sometimes
(buffering)

------
nojs
I foresee a familiar cycle playing out:

1\. Gemini is great, no spam and commercial crap

2\. Someone realises it would be great to have simple inline images, and makes
a cool client that supports “gemini+img” syntax that they make up. The syntax
gracefully degrades, so you can use it in your docs even if your users aren’t
using the new browser!

3\. Protocol is technically text-only but in reality everyone uses img-enabled
browser

4\. Repeat with basic styling, then simple scripts. Eventually authors rely on
more and more “optional” features and syntax extensions, and we end up with a
similar feature set to what we have today.

5\. Advertisers move in as Gemini gains mainstream adoption, and we’re back to
www

------
wolfspider
One of the things I find refreshing about Gemini is there is no standard
scripting language in there and the implementations vary wildly on the client
side from Rust to Lua to Python to Go as well as the server-side. It made me
realize perhaps browser technology for the Web got locked into specific
domain-centric technologies which have held it back. There is so much C/C++
required for JavascriptCore and friends in a modern browser there is only one
real choice to code in. Mozilla has made great advancements with Rust in
Firefox but still a long ways off from a total conversion. It's not that its
not possible but if you want to tap into the work which has already been done
in JavascriptCore or other technologies you certainly cannot just pick your
own backend or language. Gemini's efforts on the other hand are being brought
up in parallel and in the open so that is a major strength that the ecosystem
is already much more broad from the beginning. Building a modern browser from
source nowadays is an intensive process on a single mid-range workstation just
due to the fact much of the extra functionality is compulsory and not opt-in.
Many of these modules were meant to be pluggable but somewhere along the way
they became coupled dependencies of each other. A good example is Electron
where in theory it should be just the things you need and a subset of a
browser where applicable but instead you need the whole browser engine every
single time.

------
_-___________-_
I've spent the last few hours browsing Gemini, and it feels more like the
early web than anything I've experienced in the decades since. I love it.

------
algerd
Here we go again. Solving social problems with technical staff.

~~~
dredmorbius
Protocols are actually part of the glue between technical and social domains.

------
triptych
Why not just set up a site that only allows markdown with plain pages and get
all the benefits you list without a new protocol?

~~~
DC-3
Gemini's creator solderpunk wrote about this here [1].

[1] gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/why-not-
just-use-a-subset-of-http-and-html.gmi

~~~
corobo
I’m sure that would be an interesting read, is it available on a usable
protocol?

~~~
vertex-four
You can read it with a Gemini browser, along with a lot of other content!
There's a list of clients at
[https://gemini.circumlunar.space/clients.html](https://gemini.circumlunar.space/clients.html),
along with SSH and HTTP bridges.

~~~
corobo
Aha nice one!

I’m still not sold on it (you’re allowed to do websites without js/css!), but
the effort and skill involved is commendable

~~~
cjallen88
True, but before you visit that website, you don't know anything about how the
site was implemented, or what JS is going to run, or whethere there will be a
big autoplay video advert, etc.

When you visit a gemini URL, you know how it's going to serve you a limited
capability, text based document, styled according to your own rules.

------
carapace
Gemini is awesome and fun. Sure, it's kind of a toy, but's that's kind of the
point.

Go read the mailing list. Implement a client in your favorite language, or
that weird language you've been wanting to try...

Write a blog, or some fan fiction, or a screed or some poetry. (There's a
choose-your-own-adventure you can play.)

Have fun with it.

------
gray_-_wolf
One thing I don't agree with the protocol (on technical level) is that absent
of content-length or of some end-of-message marker.

> The server closes the connection after the final byte, there is no "end of
> response" signal like gopher's lonely dot.

This just seems like a bad idea, especially if one is on shitty connection.

~~~
UIZealot
I share your concern.

Since the response body is not encoded, there's no safe end-of-response marker
byte(s) to use.

So content-length seems like the way to go. But knowing content-length ahead
of time is difficult for dynamically generated content (CGI is supported after
all), so they also need something similar to HTTP chunked encoding, which does
complicate things _a little_.

I understand that keeping the Gemini _client_ simple to implement is one of
their design goals, but I don't think the same is true for the Gemini
_server_. So I hope that they would consider adding these to the protocol.
They could probably stuff the content-length or the word "chunked" in the
<META> string.

~~~
gray_-_wolf
But since they explicitely state that it is not suitable for _large_ content,
server could just cache it until it has it all. Most clients will likely wait
for whole response anyway.

I feel like that would strike reasonable balance. Client are still simple
(arguably _more_ simple since they don't have to guess if they got everything)
and the protocol is still trivial. For dynamic content, it would increase
time-to-first-byte and ram usage on server, but both imho would not be an
issue for the type of content gemini aims for.

~~~
UIZealot
I agree that always sending content-length would be ideal, if it didn't come
with the extra work and costs on the server that you mentioned.

Chunked encoding is simple enough to implement, avoids all those issues, and
would allow a Gemini server to serve more requests faster given the same
resources, or to run on hardware with more limited resources such as embedded.
So I think it's well worth the _slight_ cost in simplicity.

------
jansc
I wrote an ncurses-based gemini and gopher client a while ago:
[https://github.com/jansc/ncgopher](https://github.com/jansc/ncgopher) I
really like the gemini protocol because of its simplicity and its text-based
nature. Spending most days in a terminal, text consumption is so much easier
with a gemini client then e.g. lynx for webpages (which won't work 99% of the
time).

------
JohnStrangeII
I've been thinking about something similar for a while, but kind of disagree
with Gemini's scope and implementation. I think that the lack of inline images
is too limiting. In my opinion, a good replacement for the WWW should have the
following features:

\- ToS that strictly prohibits commercial use and advertising. We have the WWW
for that, no need to duplicate it.

\- Uses HTTPS or something similar. This allows use of efficient servers like
Nginx.

\- Based on a virtual display with fixed dimensions and orientations, 2-3
aspect ratios and vertical/horizontal orientation. Fixed virtual pixel
solution. Every page is fixed in size and in the length of unicode text it can
display.

\- Uses a structured document format with a limited number of logical tags.
The client displays the page as it likes (no styling directives in the
document markup). Every page written in this format is compiled into an
efficient and compressed binary representation for transmission.

\- Limited number of links, overlays, and images per page. Input fields with
validation should be allowed. Inline images and movies are limited in size.

I'm planning to implement something like this in my forthcoming virtual Lisp
machine (z3s5.com), though it's going to be a bit less general and probably
not be based on HTTPS.

------
electronstudio
Last time this was posted I started working on a Gemini client:

[https://github.com/electronstudio/2face](https://github.com/electronstudio/2face)

Currently it’s TUI, but will add GUI eventually. It’s fun to have a protocol
small enough you can implement it yourself, but I currently have a weird bug
where some Gemini servers work and others don’t because they don’t seem to
follow the SSL spec.

------
tluyben2
No mention of JS; not even a Gemini server in Node[0]. Finally a sane place to
hang out! Kidding, but only half. The 'everything must be done in JS' is
fairly annoying imho.

[0][https://portal.mozz.us/gemini/gemini.circumlunar.space/softw...](https://portal.mozz.us/gemini/gemini.circumlunar.space/software/)

~~~
flatlanderwoman
A Gemini implementation in JS:
[https://github.com/derhuerst/gemini](https://github.com/derhuerst/gemini)

~~~
tluyben2
Great, doesn't disappoint; includes horrible emoji's :]

~~~
flatlanderwoman
Emoji's are part of Unicode. Not bloat.

~~~
tluyben2
I wasn't thinking of bloat; it just looks unprofessional, in my opinion, and
it is also very related to people who work with js almost exclusively.

------
jeffmcmahan
I see a lot of comments expressing that all we need is markdown plus this or
that little bit. I think that's unreasonable. It might suit Joe developer just
fine for reading blogs and news, but the world benefits enormously from the
ability to build complex software applications at low cost. Imagine the
alternative: Welcome to Mario's Pizza - you can order right from your own
computer after we mail a disc* to your house (*requires Windows 8 or newer)!

Also, some of the CSS and JS hatred is piffle. Publishers absolutely abuse
these languages and it gets pretty bad on news websites especially. But I do
not find that most or even many of the sites I visit perform badly on my
hardware (2016 iPhone SE and a 2017 MBP). They work fine. Moreover, I
appreciate nicely designed and competently implemented experiences on the
modern web.

I have no interest in trading the modern web - warts and all - for some
spartan plaintext utopia.

------
thayne
I think this might be _too_ simple. In particular, the absence of a way for
the client to specify a desired language or supported mime types, query
strings as the only way for the client to send data (what about uploads? Or
non-idempotentent requests like registration?),and the absence of compression
all seem to go a little too far to me (compression could be done using a
parameter to the mime type).

And really,why replace http? The complaint seems to be mostly with html, so
why not just makr a gemini text format,build some browsers that use that as
the default instead of html and specify semantics for how tls works, like
custom status codes to request a client certificate and recommend TOFU
certificate trust. And maybe specify certain headers that shouldn't be used,
like cookie.

~~~
flatlanderwoman
The intention isn't to replace HTTP entirely. By using an incompatible
protocol, a hard line is drawn.

------
squarefoot
The web has become much more than a protocol for reading documents: controls
that communicate both ways with the server so that they can be also updated in
real time is a really useful aspect that won't make them go away anytime soon.
I rather wonder if the browser is the best interface for that, or if html is
the best protocol for that use. The answer would probably be obvious: "one
software doing all is cheaper to produce and maintain than two or three doing
each one its own business (and we can still blame the user hardware for the
added slowness)."

------
maitredusoi
I still don't understand the point of this project.

I mean QUIC is here, waiting for us.

Why throwing away 30 years of HTTP ideas . If images and cookies are to be
forbid that should be made from the web developper decision.

Choosing Gemini is like accepting restriction by law. I feel like this is old
behaviour, that confidence and responsability is the way forward.

In a way Gemini could have been published by writer of European Union , North
Korea or Soviet Union laws, I can't belive this is a US products, as it
contains too much to liberty constrain ;)

~~~
tenebrisalietum
> If images and cookies are to be forbid that should be made from the web
> developper decision.

Unfortunately even today that's not 100% under your control. I don't have to
accept cookies nor load images from your site with the proper settings or
browser.

You seem to be forgetting HTTP is a user-initiated protocol and while a lot of
it is hidden behind Javascript and common browser features, ultimately it's
the user agent that initiates everything. You as a web developer can only
control the files on your webserver, put cookies in headers (which the user
agent has to send back to you) and possibly take advantage of some other
Javascript features like DOM storage (which I can turn off).

I'm 100% on board with Gemini being a 'liberty constrain' for those who put
information online - honestly it's not necessary for remote systems to be
executing code on my system just to display text. Yes, you can't monetize it
as easily. That's a feature, not a bug, for a user like me.

------
aronpye
How is introducing yet another new technology, incompatible with what everyone
else is using, any better than just creating a minimalist static HTML website?

~~~
arghwhat
Because the problem is the technology everyone else is using

The issue isn't bloated websites as much as the web itself.

~~~
aronpye
How is the issue not bloated websites? You can easily create a text only
website in HTML which is compatible with every existing internet capable
device. All technology can be misused, it isn’t necessarily a problem with the
underlying technology. By introducing yet more standards and technologies, you
end up creating bloat and fragmentation of a different kind.

~~~
tryauuum
There is also an allure of having a client that will never run some weird god-
know-what-doing javascript code.

Of course you can just disable javascript in your HTTP browser. But as the
author states, it's easier to write a completely new client than to disable
all the bloat in e.g. firefox.

~~~
aronpye
Agreed, but like I’ve said elsewhere the effort would be better spent
modifying an existing browser to be lightweight. That would gain more
widespread adoption than a whole new client-server protocol. You’d also gain
the benefit of better interoperability with screen readers and such like.

~~~
vertex-four
Nobody involved in Gemini wants "widespread adoption", because that inevitably
means big commercial organisations coming into the space where right now
they're having a lovely time building a community.

Screen readers handle Gemini just fine - one of the clients I've tried outputs
text and buttons in a GTK window, another literally just outputs text into a
terminal and takes command line input, if a screenreader couldn't handle that
I'd be horrified. The format is paragraph-based, there's very little styling,
no guessing at what the main content on a page is.

------
smoyer
I've recently switched from Markdown to ASCIIDoc ... the article makes it
sound like the browser is optimized for text but isn't it really the server
that's rendering the text that's sent? In this case, I like the idea of
minimal styling mostly because my eyes are getting old but as others have
stated, why isn't this specification a small subset of the existing internet?

------
perryizgr8
> Gemini, being a recent protocol, mandates the use of TLS. There is no
> unencrypted version of Gemini available.

Mandating the reliance on third parties in the protocol itself does not seem
to be a great choice. If I have a simple webpage which I use as a daily diary,
why should I go to the trouble of asking a random third party to provide me
with a certificate?

~~~
vertex-four
Gemini does SSH-style TOFU, you don't ask a third party for the certificate.
From the spec: "Clients can validate TLS connections however they like
(including not at all) but the strongly RECOMMENDED approach is to implement a
lightweight "TOFU" certificate-pinning system which treats self-signed
certificates as first- class citizens."

------
guerrilla
I was just talking to someone about an idea like this. I even thought about
making a Gtk+ widget for it, having no idea this existed. I really like the
idea of viewers being the ones who decide presentation and something like
Markdown (with images and videos) could work well for that. I'm not sure why
we'd need a new protocol for it though, other than to escape the web.

------
bonestormii_
It's like wearing clothing.

If I wear a polo and dress pants, and I'm on the train at 8am, I'm going to
white collar work. If I wear jeans at the same time and have my partner with
me, I'm a middle class, middle aged, probably-parent on personal business that
could probably be described as "running an errand". If I'm a 42 year old man
wearing bright purple halter top, with black lipstick and combat boots on the
train at 8am--you don't know me! Where the hell am I going? How am I living?
You don't understand how to talk to me, so don't bother unless you are a 27
year old woman with red eye liner, green air, blue lipstick and a brady bunch
t-shirt on! We wouldn't understand each other!

Elaborate protocol jokes aside, it's an apt analogy. It works--for some
people, some of the time. They are dreamers living life waiting for a tomorrow
that may never come, but the cause gives them their identity. Chances are that
Bob and Linda still have to straighten up on Monday mornings and assimilate to
the general protocol. But that's the world we live in, is it not?

I like it. I don't like to deal with it when I'm at the bank or the brokerage,
but Friday night, it's alright with me.

I don't begrudge their them identities. However, it's a weak, unopinionated
protocol. No inline images? Just because you support them doesn't mean they
don't exist.

Users will have their inline images, and they will build clients, and the
protocol will be defined. If not by you, then by someone else.

That _is_ the story of the modern web, and that is, funny enough, how we got
here.

Nostalgia isn't productive. A new protocol isn't insurmountable, but it has to
be native to the time you are living in. You don't need to necessarily inline
videos and graphics, but you need to define how these should be handled, or at
the very least, the boundaries of the protocol. Waxing whimsically at people
creating readers to handle inline images in an ad hoc way... lol, why? Why are
they doing this?! They were just bemoaning the current state of the web! My
god, have some foresight!

Make a protocol, make a browser, define the boundaries and perhaps adjacent
protocols, set your browser roadmap accordingly. Stop when you feel the
coverage of the desired space is sufficient. If that's text-only, fine. But
you must have answers to how an image or video should be served to the good
people of this community.

~~~
peteyboy
The thing is, when the web grew up, there was no not-web. Gemini occupies a
swim lane, and if you want more, even a gemini page can link to a web page to
do the heavy lifting of the modern web. So aside from making the bear dance,
there's little interesting in forcing inline images. It will be not that the
bear dances well, but that it dances at all, right? There is definitely a part
of the Gemini community--from what I've seen--that is really excited to see
the http 0.9 grow up that they missed the first time. But so far cooler heads
are using their persuasion to knock most of that urge down. What will save
gemini from turning into the modern web is that the modern web will be _right
there the whole time_. I guess the perverse server and client could collude to
deform the gemini protocol to look like http, but why? "=>
[http://www.mysite/recipe-with-inline-images/](http://www.mysite/recipe-with-
inline-images/) Step by step recipes " in your .gmi file would do this so much
better.

------
ilaksh
If anyone is interested I have an idea along these lines under
runvnc/noscriptweb on GitHub.
[https://github.com/runvnc/noscriptweb](https://github.com/runvnc/noscriptweb)

Its probably going to stay as just an idea because other projects have
priority.

------
dangoor
What if the problem statement (what is something like this trying to solve)
is:

1\. No tracking beyond what the server gets via standard logging 2\. Document
styling control in the hands of the user agent 3\. Navigation control in the
hands of the user agent 4\. Compatibility with existing web browsers would be
a bonus

Points 2 and 3 imply some kind of semantically-clear markup. Would definitely
want to think of forward/backward compatibility (something the web has been
fairly good at).

Point 1 means no cookies, likely nothing like JS, images need to come from the
same server (either packaged in the initial request or forced to come from the
same host).

Point 4 is a nice to have and may be possible if this is built on a subset of
HTML and HTTP. One possibility is that if the server receives a request that
looks like it's coming from a standard browser, it can serve up the page with
some JS and CSS that fill in the stuff that would normally be done by the user
agent.

IMHO, something built on a stack that looks like that would be a better fit
for 2020 than something based off of Gopher's approach.

------
steeleduncan
Could most of this not be achieved by adding a markdown mode to Firefox?
Whenever text/markdown content type is received it would display it using a
stylesheet set by the user. It could skip cookies, etc in this mode to reduce,
if not completely eliminate, tracking.

~~~
peteyboy
I'm waiting for folks to look at gemini, see only part of what they want, and
make markdown-native web protocol, a wiki protocol, basically. I think that
would be very cool, and it is what drew me to gemini before I figured out it
was really super-gopher. Like what if there was a mediawiki protocol? You'd
have your tables! Anyway, there's no one stopping anybody for trying to make
that happen. The true interwiki promised in the days of c2, could actually
happen!... if some people want to make it happen.

------
juanbyrge
A better approach to Gemini would be to create a UGC web app that allows
people to create simple, text-only, markdown-enabled content that does not
track users. And I think plenty of those exist already. It would be the circa
2004 era blogging platforms.

~~~
SllX
My understanding of Gemini’s raison d’être is that the JavaScript-laden app-
filled WWW is an anti-feature so doing anything with Gemini and web apps would
be contradictory.

Probably won’t stop someone from trying.

~~~
dragonwriter
Well, there's nothing stopping you from serving HTML/CSS/JS web apps over the
Gemini protocol.

(Nothing stopping you from building a browser that handles gemini format
documents and does special things with JS links, either, though to avoid
accidental execution issues you would probably need to extend the format to
distinguish “links I want to execute” from other links.)

~~~
SllX
All of that goes without saying, so the only real question is whether Gemini
can resist the scourge of the modern web.

~~~
peteyboy
I'd like to say again that by competing with the modern web to do things that
gemini isn't good at, gemini gets to _lose_ those contests, and this should
limit the success of efforts to to make dancing bears out of gemini.

------
spiritplumber
If you want to show circuit diagrams, have you considered the Parallax
Propeller font?

------
Lio
This would be interesting for a terminal based web alternative. A practical
use would be something like O'Reilly's Safari Books Online.

The author mentions that fancy Gemini reader apps could allow linking to
images, since that some terminals allow images to be displayed[1] that would
fit nicely too.

Why not just use text based websites and something like w3m? Well it's hard to
tell when opening a link in the terminal will be useful and when it would be
better to open the link in a "real" browser like Firefox.

e.g. after a git push to github I'm provided with a link to create a PR. I
really when I click that link I really want it to open in Firefox.

[1] Off the top of my head Kitty and iTerm2 both allow image display from apps
such as the ranger file manager.

------
Beegle
I agree with some of your thoughts and thank you for putting this together. In
order for this to be successful (and I truly wish it becomes so; I very much
miss the internet before the web sometimes), it needs to work side by side
with http. By that, I mean your web browser needs to become a ‘dual’ browser
and be able to switch back and forth between the two seamlessly and documents
built for the two protocols need to be able to link back and forth between the
two protocols. If a browser can do that, my question then becomes, is it even
worth it or fo we just need more web sites out there that focus on their text
and their usability?

~~~
peteyboy
there are gateways if all you want is to peek into gemini web, as several
people have noted. How does that ruin anything?

------
ilaksh
I just wish they had not insisted on TLS and closing connections. It defeats
the purpose to me because you are going to be delayed constantly by new TLS
startups.

~~~
troupe
If the expected use case is to spend a long time reading a document with no
images, is that much of an issue?

------
Silke_Mousepad
> a brutally simple alternative to the web

Yip and gemini's markup is so simple that it is useless for me. :-(

Combining a restricted HTML maybe with 1-file-only limit (use data url for
insets) with gemini's protocol could make sense for me.

"rHTML" like PDF, all in one file, maybe a bit JS for rendering maths, but
maybe there are other/better ways to do it (no maths in PICs please!).

Or brutally different? Distribute DVIs over gemini://?

I like the 1-file-only style in the dimension gemini and apart from not yet
having automated images to data-url-conversion, ... _sigh_ ...my image-less
HTML stuff already is 1-file-only.

------
meigwilym
This seems to be RSS with extra server setup but no images.

------
Andrew_nenakhov
Hey, no tables, even basic? If this protocol is to be like 'library', instead
of a 'mall', it definitely should have tables.

~~~
flatlanderwoman
Even Markdown hasn't sorted this out yet though.

CommonMark currently has no tables, it's up to other markdown dialects to add
it.

Related discussion: [https://talk.commonmark.org/t/tables-in-pure-
markdown/81](https://talk.commonmark.org/t/tables-in-pure-markdown/81)

~~~
Andrew_nenakhov
Well, html had it sorted out three decades ago...

------
scorecard
Are there other projects similar to Gemini? Of these projects, which is most
likely to still exist 5 years from now?

~~~
peteyboy
I don't know, are there? I don't know, do you?

------
spiritplumber
Would this help usability over a slow link (let's say a 9600bps radio modem),
or is Gopher better for that purpose?

~~~
sloum
Gopher will be faster by nature of gemini using TLS. However, gopher is
inherently less secure than gemini. If you are wanting the TLS, gemini
_should_ load your document faster than the https (even with minimal headers
included for the https version, there is still more header overhead to just
make the request and there is a lot more header overhead in most responses).

------
LoSboccacc
> although Gemini lacks in-line images, you can still use in-line links to
> images

this is telling. not only it's inconvenient, but claiming link to images are
good enough for blog and recipe pages makes me think the audiences are
completely misunderstood.

weird because text driven interface like airline reservations still exist and
porting them on a common protocol would provide immediate tangible benefits
today without the backward thinking about media

~~~
sloum
I do not think it is inconvenient at all, it is just different that what
people have come to expect.

~~~
LoSboccacc
inline illustrations predate internet by hundreds years. imagine a child book
but all the images are in the appendix.

it is the definition of inconvenient. it's usable, but it's not like inline
media is a modern or even contemporary concept.

------
bborud
Call me a cynic, but isn't Gemini like HTTP before it grew any of the features
that made HTTP useful?

I don't get it.

~~~
toby
You're pretty much correct. Even in this thread there are people saying "oh
the Gemini browser can decide whether to render inline images", which is
exactly what Mosaic did.

The main advantage this has is that it will not get popular enough to
experience the scope creep that the web did so will probably remain relatively
pure.

------
rs23296008n1
Pity the client scripting thing is absent.

Then again, which script would you use?

The overall web itself is going WASM for a lot of projects. Pure javscript
that is actually readable isn't exactly common now either as more frameworks
build multiple layers on top.

I see this as an interesting step sideways. Less is more and all that. Perhaps
check in 2 years from now and see what major shifts it caused.

------
jonnypotty
What network instability recovery features are there in http and ftp? I
thought that was all in tcp?

~~~
ptr
The author is probably thinking about HTTP partial/range requests ("resumable
downloads"); they can recover even if the TCP connection is closed.

~~~
jonnypotty
That makes sense. You don't get this in ftp thou right?

------
Recurecur
This seems like a fair enough idea, except that there should be provision for
"rich content boxes" that might contain images, forms, WebGL or other things
that Gemini intentionally forgoes.

Having a "web browser" that can't do interactive content at all (no, server-
side CGI doesn't count) is a non-starter in 2020. What if I need an
interactive chart?

~~~
peteyboy
You could make a regular http web page for your interactive chart...

------
bawolff
This seems almost identical to http/0.9, and early versions of html

Soo umm. Just use netscape 2.0 (+modern TLS)

~~~
flatlanderwoman
If one were after a minimalist browser they would be better of with something
like NetSurf. But that puts it at odds with 90% of the current web.

Everything I find on Gemini will be compatible with my browser.

------
bertman
Regarding the quote at the end of the blog post:

    
    
      "When I picture it in my head I think of the early web as more of a library. 
      Over time it has transitioned into a shopping mall." 
      - chris_f (Hacker News comments)
    

There are still books in a shopping mall. You have to know where to look and
not get distracted at every corner, though.

~~~
devaler
You’re confusing a library with a bookstore. Libraries are repositories of
information that one can browse.

------
gingerlime
Can Gemini be used for something like HN? e.g. nested threads? (or that’s
basically Usenet?)

~~~
acdw
There's a list of mirrored services here:
[https://portal.mozz.us/gemini/gempaper.strangled.net/mirrorl...](https://portal.mozz.us/gemini/gempaper.strangled.net/mirrorlist/)
(http link) gemini://gempaper.strangled.net/mirrorlist/ (gemini link)

I think it gets updated semiregularly.

~~~
flatlanderwoman
Good link thanks!

Added to article.

------
ryankrage77
Just make a regular old HTTP(S) site. You can host plain text files and
they'll work just fine in any modern browser. Or you can use a subset of HTML
and CSS for accessibilty reasons (screen readers, etc).

------
hkt
Is gemini featureful enough to build a sign-up form where I could pay for
stuff? I ask only because it seems like the commitment of commercial players
seems like a prerequisite for the success of stuff like this.

~~~
sloum
The almost full and complete point of this is to REMOVE the ability of
"commercial players" from having a role or interest in the platform at all.
They have already ruined the web and society as a whole (but that gets into a
whole argument for/against capitalism... take a wild guess where I stand).

~~~
hkt
I'm not a great fan of capitalism, but really my favourite thing about it is
the seeming inability of commercial players to surveil. I don't like the idea
of building in the price of content as being nothing - I want to donate to
bloggers etc.

A way around this is to mix gemini and http in a single browser. Only one can
be rendered on a page, but they can link to one another, with a warning when
you transition between the two. So blogs could have a donate button that just
hits paypal etc.

------
dukoid
I'd find it an effort to standardize text/terminal-friendly accessible
HTML+CSS much more appealing. And the TLS requirement seems to make it harder
to get started for pure "fun" projects.

~~~
ac29
One of the goals of the project seems to eliminate all of the ways the current
web can violate user's privacy. Without encryption, I dont think Gemini could
claim to be better.

------
yaur
> Gemini, being a recent protocol, mandates the use of TLS.

and also

> it misses many features that protocols such as FTP or HTTP use to recover
> from network instability

What? These statements are at totally different levels of the OSI model.

~~~
progval
About TLS: it means the spec requires Gemini to be encapsulated in TLS; the
same way RFC 2616 recommends HTTP be encapsulated in both TCP and IP ("HTTP
communication usually takes place over TCP/IP connections"). Yes, technically
they are abstraction violations, but they are commonplace for network
protocols.

about network instability: it doesn't refer to congestion and packet loss
handling in TCP, but to the "Range" feature of HTTP, which allows downloading
only a subset of a file, to resume an interrupted TCP connection.

------
eaandkw
Won't work. As soon as it gains any traction hackers/crackers will figure out
how to exploit people. Marketers will figure out how to optimise it to sell
you crap you don't need. Left wing/ Right wing censors and moderators will
silence at least a portion of the users if not the whole project because
"reasons". Oh yeah, the government will also be there to ensure that you can't
do anything without them knowing about it.

Honestly the web could be great with the technologies that are out now. At
this very moment. But it isn't.

------
docuru
How the web today is how it has evolved. I think it is hard to change the flow
of water.

I mean, for example, if Gemini evolved, it would still somehow be what the web
became!

~~~
ketzu
I feel similar. Projects like gemini work, because they are niche, not despite
it. If it became mainstream similar forces that drive the web to what it is
woule take hold.

~~~
l0b0
Yeah, designers would hack around the limitations until the hacks become
official (against the original protocol inventors' intent, if necessary),
because every company wants to control the experience of their content to an
unreasonable degree. I recently turned off the "Allow pages to choose their
own fonts" setting in Firefox, and it's refreshing to read text in O(1) rather
than O(N) fonts. Now if only similar tweaks were as easy to apply to web
forms, menus etc.

------
rado
The linked site is perfectly fine on the Web.

------
surajs
sounds like another gimmick but okay

------
otabdeveloper4
> <URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.

This is never a good idea.

------
andreigaspar
Breaking: Sacred texts from 680 B.C. are a simple alternative to high-budget
Hollywood movies

JK, interesting read but the idealism is stronggg.

------
jamesfisher
Meanwhile, the other post at the top of HN is a visual explanation of sphere
eversion [1] that relies on the web being a system for distributing _sandboxed
applications_, and so would be completely impossible in this Gemini system.

[1] [https://rreusser.github.io/explorations/sphere-
eversion/](https://rreusser.github.io/explorations/sphere-eversion/)

------
antihero
Don't get this fad of hate to be honest. The web, fucked as it is, works.
Obviously there's a load of cruft because humans will try and exploit any
system, but if our only problems are our Macbooks spinning their fans up a
bit, it's a beef that really only irks purists. Day to day, talking to people,
people don't bitch about the web other than about invasive adverts.

Frankly I think a lot of commentary stems from backend people being annoyed
that frontend people earn a bunch of money for work they deem insignificant.

------
rikroots
> I have really come to hate the World Wide Web. It is bloated at every level!

I have to admit that this opening statement almost stopped me reading the rest
of the article. Which is a pity, because Gemini does sound like an interesting
endeavour. I went searching (via the bloated World Wide Web) and found the
Gemini FAQ page
([https://gemini.circumlunar.space/docs/faq.html](https://gemini.circumlunar.space/docs/faq.html))
which (in my opinion) makes a much better argument for considering this
alternative approach to delivering content over the wire.

> I could totally see Gemini being used as an alternative particularly for the
> non-comerical individuals who use text as a primary medium. Blogs, poems,
> recepies, tutorials are perfect for the Gemini format.

The one big thought I had - as a content developer (I write poems: I will
never apologise for this) - as I read through the FAQ was: "Yet another
distribution channel to maintain" ... because Gemini reminds me (probably
unfairly) of WAP and its Wireless Markup Language. Back in the day I was very
keen to inflict my poems on everybody in the world: I posted them on Usenet
(mainly RAP), various web-based bulletin boards, a Blogger Blog (with a
blogroll!) and, of course, my own poetry website. Reaching out to a mobile-
centred audience was the next logical step. But the mechanics of the effort
defeated me, and I soon grew to truly detest WML and its stupid limitations.

I suppose, in 2020, adding another communications channel to my current
website's toolchain should be a lot easier ... but I don't want to do the
work. If the people around Gemini can get more passionate content creators to
do the necessary work, then maybe it will have an interesting/exciting future?

~~~
vertex-four
If you're seeing Gemini as a "distribution channel", it's... probably not
really for you? What's there, right now, is a community of people, sharing
ideas and talking to each other. Pretty much all the content there was made to
be shared with that community. And I very much have the impression they'd like
to keep it that way as long as possible.

~~~
rikroots
I'm glad they're building Gemini - a monoculture of anything is an unhealthy
environment and projects like Gemini can help break up our current HTML/CSS/JS
monoculture. But it is also a distribution channel: a method for content
creators to get their content out to content consumers.

At the moment the 'coolest' way for poets to share their poems with their
readers is through Instagram[1]. I've tried it; I don't like it. But I don't
resent the poets who have made the channel work for them - anything that gets
people reading more poems is a Win in my book!

[1] - [https://www.vogue.co.uk/article/best-poets-on-
instagram](https://www.vogue.co.uk/article/best-poets-on-instagram)

