This page permanently redirects to gemini://bbs.geminispace.org/s/Gemini/24266.

Thoughts on geminict://

My personal philosophy, is that protcols in the application layer shouldn’t implement encryption. I think encryption should be the job of the underlying network that the protocols run on. Take Yggdrasil or I2P for example, where addresses are cryptographic public keys and all traffic is encrypted. Running Gemini on such a network would mean encrypting traffic twice, which seems a bit unnecessary to me.

=> Yggdrasil | I2P

If you simply implement encryption once, in the underlying network, you can simply rely on that for all traffic, instead of having to include it in every new protocol you create. There are some similar protocols without encryption, such as Spartan, Gopher, Guppy, and Nex. And I have actually seen someone run a Nex server on Yggdrasil (although when I attempted to visit it, it did not work). But these protocols are not the same, they are different from Gemini. They don’t all use UTF-8, don’t have a data limit like Gemini, etc. If someone likes the Gemini protocol, and wants to use it on a network that already has encryption, I think they should be able to use the gemini protocol without encryption, and not some substitute.

The most widely used computer network today is the internet, which does not encrypt traffic, which is why Gemini does need TLS. But an unencrypted version of Gemini should also exist, for those who don’t want to substitute Gemini with another protocol.

In "Gemini requiring TLS is good, actually", (a response to "A Call for a Gemini Without TLS"), leafstorm argues that Gemini requiring TLS upfront was a good call for a couple of reasons, but ends with the following:

“With all that being said, having a cleartext version of Gemini is totally reasonable! Some capsules really don't need TLS and there are contexts where not implementing TLS makes experimentation easier. But it needs its own URL scheme and port to avoid collisions with TLS-secured Gemini. I suggest geminict:// (for Gemini cleartext) and 5691 (1965 backwards, which is not assigned by IANA).”

=> Gemini requiring TLS is good, actually | A Call for a Gemini Without TLS

I quite like this solution, and hope some actual implementations of it could be written so that geminauts whos traffic is already encrypted can get the same experience as with Gemini, but without the double encryption. Like http, where people can choose whether to use unencrypted http, or encrypted https, and browsers support both, Gemini clients could support both geminict and gemini, and people could choose which they want to use.

Thoughts on geminict?

=> Posted in: s/Gemini | 🚀 asdf

Jan 24 · 8 days ago · 👍 adam, ps, timmy2tos, clseibold

17 Comments ↓

=> 👻 ps · Jan 24 at 05:57:

Partially agreed, as Yggdrasil user. TLS requirement everywhere is definitively not useful, it also causes server setup issues in some other DNS-less networks..

One think - not sure about new protocol name for these needs, but maybe extend existing one by add some header codes (lol, it looks like we are finally going to HTTP)

By the way, take a look on NEX protocol, I'm using it for YGG. Of course it's not exactly replacement (as header-less), but Gemtext could be detected by path extension, and for server interaction there is NPS (Titan-like) satellite. I like it for minimalism and wrote lot of services there.

=> 🚀 asdf [OP] · Jan 24 at 07:06:

I did take a look at Nex, and it seems interesting. But if someone specifically wants Gemini, I think having unencrypted Gemini would be nice. I also took a look at Spartan, and it seems interesting too, I was thinking I might run a Spartan server on Yggdrasil. The one thing I don't like about Spartan though, is the extension it makes to Text/Gemini. Like why can't they just create a Text/Spartan, with .spr file extension or something? Having a document that behaves differently, and is parsed and rendered differently depending on what protcol it's served by seems a bit strange to me. What if someone views the file locally, instead of serving it via any protocol? Then how should it behave?

=> 🚀 asdf [OP] · Jan 24 at 07:33:

Also you said you were using Nex for Yggdrasil, were you referring to nex://[301:23b4:991a:634d::1900]/index.gmi? Because when I try to visit it Lagrange gives me this error: "Operation timed out (errno 60) - Failed to communicate with the server"

=> 🚲 Aelspire · Jan 24 at 07:34:

Sorry for brainfart, but how client certs (like one used to login on BBS) would work in such case?

=> 👻 ps · Jan 24 at 07:35:

@asdf For local issues, I currently don't have any server online, but can help with setup any service you like.

=> 🚀 asdf [OP] · Jan 24 at 07:51:

@Aelspire I mean, for something like Yggdrasil where addresses are public keys, capsules where people have accounts can simply use those keys instead of certs to verify that someone is the owner of an account. Although that would make managing multiple accounts a little difficult/annoying since you would have to disconnect and change address whenever you want to switch account. Maybe you could have some kind of address manager where you can select an address from a list and switch to that, so you can quickly change address when you're about to use a capsule or web site or gopher hole or whatever where you have an account with that address

=> 👻 darkghost · Jan 24 at 11:40:

Solderpunk had some ideas for a stripped back Gemini protocol that used no encryption and was even more simplified. He called it the Mercury protocol (in keeping with the NASA project theme.) As far as I know, no spec exists for it and as such no clients or servers. However, an unrelated Mercury protocol does exist and has nothing to do with what we're talking about.

=> 🚀 asdf [OP] · Jan 24 at 15:47:

I did take a look at the Mercury protocol and it seems interesting, while there isn't exactly a specification there is a post that kind of specifies the protocol by starting with Gemini, and removing features from it (gemini://zaibatsu.circumlunar.space/~solderpunk/gemlog/the-mercury-protocol.gmi). Also, according to section 6.1.4 of the Gemini protocol FAQ, some people have written software implementing Mercury.

=> 🚀 clseibold · Jan 24 at 16:02:

Mercury is defunct, was hardly intended to be a real thing, and I think there are better protocols (Spartan, Nex, and Gopher) that just make more sense.

Now GeminiCT makes sense! I will be adding support for it into my SIS server.

=> 🚀 asdf [OP] · Jan 24 at 16:44:

Haven't had a look at what SIS server is yet but if you're going to implement the protocol in a server can you also implement it in a client, so that people can actually connect to the server with the protocol? Because to my knowledge no-one has implemented it yet.

=> 🚀 stack · Jan 24 at 18:12:

I kind of wish the opposite - a secure universal transport layer.

damn, I mean the same.

=> 👻 darkghost · Jan 24 at 18:41:

I'm with @stack on this one. My opinion: Security should be the default since there are so many malicious actors on the network.

=> 🚀 stack · Jan 24 at 19:53:

Yes, I wish the OS provided a secure socket service.

For Gemini you also need client certificate support.

=> 🦂 zzo38 · Jan 24 at 20:57:

I think that unencrypted Gemini should not need its own port number, because Gemini protocol is: client sends first, and the client sends a URL which cannot start with a control character; therefore, it can be distinguished. (I made Scorpion protocol to use the same port number for encrypted and unencrypted, for the same reason. Another consideration is 6x responses, but I did consider that too; I wrote that the client switches to encrypted mode once a certificate is provided by the user.) I agree that it should use a different URI scheme then "gemini:" though (I previously suggested "insecure-gemini:", but I suppose "geminict:" will do).

(One of the problems with Mercury protocol is that it does not seem to be well defined enough.)

(Another note, about Spartan: If you are only serving static files on Spartan and Gemini, then it should be good enough to use Spartan as the unencrypted protocol. (Although the Spartan protocol is only ASCII, the documents are UTF-8 and the same formt as Gemini; some people have been confused by this, so I mention it.) For dynamic files, the differences of the protocols may make it more complicated to handle, though.)

=> 🚀 sy · Jan 25 at 06:03:

+1 for security-by-default. I hope a gemini protocol update mandates TLS1.3 with ECH, too.

It took some time for me to notice that @clseibold’s server was not down on the server side, but was actively being blocked by my ISP on TCP level. I had to special-case it in my client to use IP and avoid sending SNI. That workaround won’t work for multiple servers on the same IP with the current specification.

=> 🚀 clseibold · Jan 25 at 13:54:

@sy Oh, weird! I wonder what is getting it blocked. I use ALPN (Application-Layer Protocol Negotiation), so maybe it's that. Or maybe it's something with my certificate? Does the non-tls (nex, gopher, or spartan) sites work for you?

=> 🚀 sy · Jan 25 at 14:13:

@clseibold Sorry for being not specific enough.

The whole ddns.net is being blocked, for unrelated reasons. HTTP is redirected to some other domain, and connection is reset for other protocols (by SNI sniffing if on TLS).

Edit: nex, gopher etc. plain protocols seems to work now. Previous problems probably were indeed server side. But I prefer eavesdropping- and tampering-resistant protocols nonetheless.