The code in Agate is a bit weird, because it started as a 100-line toy server I wrote for my personal use. A lot of the early code was optimized for conciseness rather than maintainability. It also had various micro-optimizations that were probably totally unnecessary, just because my idea of fun involves minimizing allocations and copying everywhere.
As other people started actually using the code, and submitting feature requests and patches, I mostly gave up on minimalism as a goal. The newer code is more focused on maintainability, but it's still mixed together with the old code.
My favorite thing about this project is that, as the community grew beyond my own motivation to manage it, the most active contributor @Johann150 stepped up to maintain it [1], and has done a great job!
For anyone looking for a fast way to dive into the "Geminispace", I recommend you check out this list of resources (clients and whatnot): https://github.com/kr1sp1n/awesome-gemini.
I personally prefer Amfora (Go), which uses the GUS search engine by default on top of being aesthetically pleasant and minimal.
Amfora is great and has pre-built binaries for most oses, including Win10, which I hadn't expected for this sort of project. Also worth mentioning is Lagrange, which is graphical and vaguely resembles the original Mosaic browser.
>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.
Going through the docs, it's apparent that Gemini is a bit more than just that. A description that is almost as succinct but more accurate would be 'A Gopher inspired protocol, over TLS'.
It is worth noting that using TLS doesn't seem like an afterthought (it's required, not optional), and more closely resembles SCP rather than HTTPS, with the use of client certs a first-class feature for example.
It would be an interesting project to implement a REST-like API over Gemini.
My understanding is that the designers explicitly do not want applications to be possible/practical over Gemini. The request format is intentionally not extensible, and consists exclusively of a URL.
> It would be an interesting project to implement a REST-like API over Gemini.
URLs are limited to 1024 characters according to the spec, and query strings look like it's the only way for clients to talk to servers outside of the URL, so you have a pretty narrow pipe.
It would be neat, but it's impossible, because Gemini explicitly forbids any request types other than GET, or rather a practical clone of GET that isn't called that because there isn't anything else anyways. Without a POST or other support for sending larger bodies, there's a ton of interesting stuff you just can't ever do.
If they know they don't ever want that to be possible, well fair enough it's their protocol, but I don't see the point of a cool feature like identifying clients explicitly by client TLS certs only when clients can never do anything but view documents and maybe do a simple search anyways.
A poorly thought of protocol, with political goals.
It's supposed to be simple in order to support trivial clients, and to prevent it from suffering the web's ill fate.
But it forces complexity into clients, by making TLS (of all possible ways to do e2ee!) mandatory and by not even giving the client the length of a response before the response is sent.
Of course, for political reasons, protocol can't be extended, and while it's still new and could be made sane, it won't; The authors don't want outside input.
I'd look into Gopher instead. It's old and tested, not to mention free of political bullshit.
why does it matter that response length isn't included? Gemini aims to be a small protocol that doesn't need to handle all types of content. if another protocol is more appropriate for whatever thing you want to link just use that.
I'm really confused by how vehemently against Gemini you seem to be and by the claim that the Gopherspace has no politics.
I don't see what's political about that. It seems like a design decision you don't agree with (and neither do I at a first glance) but I fall to see any political intent.
I think the OP means "political" as in its broader definition, meaning that it makes strong decisions about what it is and how it should be implemented. In other words, "opinionated".
AFAIK Gemini is not and has not yet been heavily used for the politics of government or social issues. If your concern is whether it's a new haven for left-wing/right-wing/whatever-wing nuts to spew vitriol and hate, I don't think that is the case.
Gemini, or that shitty protocol that won't tell the client the length of what it is about to receive. By design. To make things "simpler".
Of course, for political reasons, protocol can't be extended, and while it's still new and could be made sane, it won't; The authors don't want outside input.
Thanks. I was really asking an honest question, so appreciate you replying.
I do think ideas need a compelling reason to exist in order to be successful, but then again the people behind Gemini may not have my definition of "success" as one of their stated goals.
It doesn't. It literally provides no value over Gopher.
And it is broken by design; By not providing a length field in the response, it does force complexity into clients.
Of course, for political reasons[0], protocol can't be extended (refer to 2.12), and while it's still new and could be made sane, it won't; The authors do not want outside input.
The code in Agate is a bit weird, because it started as a 100-line toy server I wrote for my personal use. A lot of the early code was optimized for conciseness rather than maintainability. It also had various micro-optimizations that were probably totally unnecessary, just because my idea of fun involves minimizing allocations and copying everywhere.
As other people started actually using the code, and submitting feature requests and patches, I mostly gave up on minimalism as a goal. The newer code is more focused on maintainability, but it's still mixed together with the old code.
My favorite thing about this project is that, as the community grew beyond my own motivation to manage it, the most active contributor @Johann150 stepped up to maintain it [1], and has done a great job!
[1]: https://github.com/mbrubeck/agate/issues/6#issuecomment-7677...