I just thought that a topic about this protocol must exist on this forum.

According to the Gemini FAQ (https://gemini.circumlunar.space/docs/faq.html),

Quote:Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files. You may think of Gemini as "the web, stripped right back to its essence" or as "Gopher, souped up and modernised a little", depending upon your perspective. Gemini may be of interest to people who are:

• Opposed to the web's ubiquitous user tracking
  
• Tired of obnoxious adverts, autoplaying videos and other misfeatures
  
• Interested in low-power computing and/or low-speed networks
  Gemini is intended to be simple, but not necessarily as simple as possible. Instead, the design strives to maximise its "power to weight ratio", while keeping its weight within acceptable limits. Gemini is also intended to be very privacy conscious, to be difficult to extend in the future (so that it will stay simple and privacy conscious), and to be compatible with a "do it yourself" computing ethos. For this last reason, Gemini is technically very familiar and conservative: it's a protocol in the traditional client-server request-response paradigm, and is built on mature, standardised technology like URIs, MIME media types, and TLS.

Read the FAQ or the spec (https://gemini.circumlunar.space/docs/sp...ation.html) for more info. The protocol is quite elegant and is small enough to be understood fully by one person.

One of the features I absolutely love is Gemini's native markup language, gemtext or text/gemini. Here are all elements of the language:

That's all! No images. Links are on their own lines. Only 3 levels of headings. No emphasis.

If you are interested, you may start with a web-proxy for gemini. If you want to install a proper client, choose one of the listed ones in the faq. I use amfora.

Some sites I'd recommend:

• gemini://tanelorn.city/~bouncepaw, (proxy): my site. I upload my gemlog there quite often.
  
• gemini://rawtext.club:1965/~sloum/spacewalk.gmi, (proxy): Spacewalk, an aggregator of sites that update frequently. I really like it here
  
• gemini://gemini.circumlunar.space/capcom/, (proxy): CAPCOM, an aggregator of RSS feeds served through Gemini protocol. I visit it less often.
  
• gemini://gus.guru/, (proxy): Gemini Universal Search
  

There is a lot more sites there and you can make your own!

I have heard some buzz about this recently!

I am thinking about renting a server soon, and I most definitely will look into setting up a gemini server.
Writing a browser for this protocol could also be a very interesting project!

So is this meant as a simpler replacement of file sharing for IoT, M2M, and low-power devices?

Quote:I have heard some buzz about this recently!

I am thinking about renting a server soon, and I most definitely will look into setting up a gemini server.
Writing a browser for this protocol could also be a very interesting project!

Good luck! By the way, some gemini communities offer free hosting for static sites.

Quote:So is this meant as a simpler replacement of file sharing for IoT, M2M, and low-power devices?

Not exactly. It is not meant to be a replacement of anything, it's just a protocol for people who want to read&write mostly textual content and miss old web's or gopher's aesthetics (in fact, solderpunk, the creator of gemini, used to be a gopher enthusiast). However, it can be used as a file sharing protocol for sure.

Looks like a shitty Gopher+.

(06-08-2020, 02:23 PM)jkl Wrote: Looks like a shitty Gopher+.

Looks like Gopher+. Which is already shitty. ☺

(05-08-2020, 02:29 PM)bouncepaw Wrote: No images.

That's a pity, non-inline images can be quite useful, even if they aren't automatically loaded. The limitation was added for TUI/CLI people...

Quote:That's a pity, non-inline images can be quite useful, even if they aren't automatically loaded. The limitation was added for TUI/CLI people...

Not quite right. There are no inline images in gemini markup, but gemini itself can serve any file. Including images! It's quite common to link images

(06-08-2020, 06:12 PM)z3bra Wrote: Looks like Gopher+. Which is already shitty. ☺

Gopher+ has better multimedia support.

Quote:It's quite common to link images

Are there any clients which display links to images within the document?

So if I had something like


That link would be replaced with the image itself?

Quote:Are there any clients which display links to images within the document?

Afaik only https://proxy.vulpes.one/gemini/gemini.c...unar.space does it. It's a web proxy for gopher and gemini but you can consider it as a client.

Perhaps there are other clients that support this.

(08-08-2020, 01:36 PM)twee Wrote:

Quote:It's quite common to link images

Are there any clients which display links to images within the document?

So if I had something like

Code:

Look at my house:

=> http:link.to/an/image-of-my-house.png

That link would be replaced with the image itself?

At least lagrange does if you want (default : click to display it). It is an amazing client, and I wish Firefox look like it a little more.

=> https://git.skyjake.fi/skyjake/lagrange

It is quite an amazing protocol, I have a lot of fun with it.

What happened to "do one thing, but do it well"?
Why a F**king Transfer Protocol should define a damn file format?
Also, why should such a protocol specify a builtin crypto? It's better to let specialized tools do the crypto (because it's really hard to implement that correctly, and same for just using the libraries which do it), exactly the way HTTP can do it.
The main advantage of Gemini against Gopher is: it removed deprecated stuff. The main common point it have is: it will have deprecated stuff soon, and will be stuck with it because of legacy.

I've read gemini's specs. We talked about it a lot on IRC last year (edit: was it around august?), and my opinion is: this protocol sucks. Gopher, at least, was invented at a time where people had to _invent_ and experiment, there was no previous world wide network, there were not even stuff to, well, blog easily in a university (it was created for such "big" LAN). Gemini could learn from it, but didn't.
Instead, it's built to not be extended (why not), and (try to) do everything in a single layer: encryption, file transfer, file format.

I would, indeed, like to have a simple file transfer protocol, which *do not* specify encryption, *do not* explicitly require TCP (yes, that's a requirement for TLS) and thus allows broadcast (reduces resource cost for server and lot of hardware, thus lesser energy cost) and *do not* specify a file format, but *does* allow easy file/directory discovery, over several systems (mirroring).

Encryption should be a lower layer, file format should be something above.
Having client softwares which do the rendering of specific file formats... yes, that's nice. But that's the user-side, it should not have any impact on the protocol.
Now, specs for a name could specify an encryption layer, one (or more) file transfer protocols and a format. No problem with that. That's basically what UEFI does: standard UEFI must implement support for BOOTP, DHCP, TFTP, HTTP, GPT, and whatnot. That does not means that each of those protocols/formats must know the other ones.

Yan can write plaintext or any format, text/gemini with gopher is what html is to http. That's all.
TLS is required for privacy. I find it nice to think about it at the very first level, before doing anything else.
Not sure it will be deprecated the same way gopher is : the way links are writtent do not depend on file type.

Quote: Why a F**king Transfer Protocol should define a damn file format?

To avoid JS/AJAX/CSS/fonts... gemini is designed to remain simple and light.

(05-01-2021, 07:39 AM)prx* Wrote: Yan can write plaintext or any format, text/gemini with gopher is what html is to http. That's all.

And nothing prevents someone to use gemini to serve an actual website.

(05-01-2021, 07:39 AM)prx* Wrote: TLS is required for privacy. I find it nice to think about it at the very first level, before doing anything else.

Yeah. Well, I think it's crap. It's crap for debugging your server (or client) for a start, it's crap to not be able to reuse existing programs which only do that layer (this allows to change program if buggy/slow, to change encryption protocol easily when it's broken, to, well, let the really complex TLS stuff to people actually understanding how it works in depth, and no, using TLS libs is not simple, just see how many there are which all tries to address that problem...).
Encryption layers break "often enough" so that I think it's a bad idea to do that. Not to mention the weight of TLS, which requires TCP and few other fun stuff (if only I kept those links from when I did actual research on encryption protocols...).
But yes, I see that from a dev's PoV.
I would not implement a gemini server for production, clearly. Either I would use someone else's to hide when things break, or I would implement it without TLS, thus not being a conformant server, and rely on hitch, for example, to do that (which is what I do with my darkhttp instances, mind you).

Quote: Why a F**king Transfer Protocol should define a damn file format?
To avoid JS/AJAX/CSS/fonts... gemini is designed to remain simple and light.

It's not.
If it was designed to be simple and light, gemini would be a collection of technologies, as are the web or UEFI. It would then say something like:

```
gemini-compliant systems (not softwares, systems) are comprised of: 1) a security layer, considering current version of gemini specs requires at least TLS 1.2 and prefer higher ones 2) a file transfer protocol documented in [...] and 3) a file format to represent documents documented in [...].
```

That's not what it does.
And nothing that it does prevents the use of JS/AJAX/CSS/fonts, actually. Because, well, it's simply not possible (and would be stupid to even try, too).
It tries to discourage it, yes. But it's just that: tries to discourage.

Basically, nothing prevent a client to pre-load files referenced in the file you're reading (it would be silly to do so, but we could also have http client not doing it: the problem is that they are used to do it).

So, no, gemini is not simple. It's just a modern gopher, which, considering the goal of non-evolution, will deprecate too. Programs (clients and servers) will, for most of those, *require* active maintenance only to keep up with the TLS layers, which implies higher chances of using no longer safe programs.

Gemini seems to have a lot of agitation around it. Either praise or hate...

Fear not, Gemini will not stand any chance to receive the amount of hatred and lost hairs caused by modern web frameworks.

Both Gemini and Gopher walk toward the same direction. Who has the silliest walk toward simplicity means few to me.

@freem, dude you're overreacting a bit there. You seem to take it personally at this point 😂
I used to think just like you, specifically about the crypto part. However, I've been digging through crypto services a bit more recently, and I took a step back on that point.

(04-01-2021, 11:33 AM)freem Wrote: why should such a protocol specify a builtin crypto?

It doesn't specify "builtin" crypto, but rather, that TLS encryption must be used to communicate with the server, which is totally different. It means that a crypto-less server implementation is totally fine, as long as the TCP connection is encrypted. Just like you do with your darkhttp server.

The fact that they "enforce" it at the spec level is still a risky move IMO, because it doesn't take into account connections set in an already encrypted environment (IPSec, wireguard, yggdrasil, …), which render e2e crypto meaningless.
But it's good for the majority of the cases, and especially internet-wise.

(05-01-2021, 05:55 PM)freem Wrote: it's crap to not be able to reuse existing programs which only do that layer

Keep in mind also, that Gemini aims to define some features in the protocol that are greatly helped by the TLS requirement: Virtual hosting through SNI, and Certificate based authentication.
Those two features are a great addition to the protocol (I miss virtual hosting myself with gopher for example), and they decided to rely on existing mechanisms rather than bloating their protocol with headers and what-not like HTTP does.

This fits the "do one thing and do it well" mindset in a way: reuse TLS protocol SNI + Cert auth rather than implement their own. And the cool stuff about it, you can also offload that to an SSL-enabled proxy rather than implement it within your Gemini client 😉

As a conclusion, let me say that I agree with you that enforcing TLS transactions is an heavily opiniated decision, they managed to keep it separated enough from the actual protocol to make it easier to integrate with existing tools handling TLS, and not having to implement it at the server level.

My personal issues with Gemini:

• Conflates alt-text for ASCII-art with programming language indicators.
  
• TOFU has nothing to prevent a MITM attack during the initial connection.
  

IMO, backing TLS with DANE or using something like Yggdrassil or Tor to layer on encryption would be better. I still have a Gemini capsule tho because the community is comfy.

I do like how URLs get their own line, since it encourages people to use descriptive link text and helps break up long blocks of text; both are good for a11y and navigation.