Comment by 🚀 asdf
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"
2025-01-24 · 1 year ago
13 Later Comments ↓
@asdf For local issues, I currently don't have any server online, but can help with setup any service you like.
🚀 asdf [OP] · 2025-01-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 · 2025-01-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] · 2025-01-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 [🛂] · 2025-01-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] · 2025-01-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 · 2025-01-24 at 18:12:
I kind of wish the opposite - a secure universal transport layer.
damn, I mean the same.
👻 darkghost · 2025-01-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 · 2025-01-24 at 19:53:
Yes, I wish the OS provided a secure socket service.
For Gemini you also need client certificate support.
🦂 zzo38 · 2025-01-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.)
+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 [🛂] · 2025-01-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?
@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.
Original Post
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. If you simply implement encryption once, in the underlying network,...