Lagrange: A desktop GUI client for Gemini
github.com
github.com
What people don't realise is that Gemini is a different thing for each person involved with the ecosystem. Some people are in it because it is easy to implement, something that can't be said about the recent specs of HTTP/HTML specs. Others enjoy having a spec that is easy to understand and absorb, even if they're not developing with it. There are those that like how clients decide how to present the content, and that some clients allow for a ton of customisation thus placing the user in control of the presentation. Each person is enjoying the ecosystem for their own reason, and that doesn't need to be a reason that serves as an answer to "why not HTML and HTTP?"
Mostly, people do Gemini stuff because they're having fun, and that is enough.
Lagrange is a great client. There are a gazilion others. Pick one up for a ride, have fun.
But who knows, maybe all of the people hyped about Gemeni are just really excited about TOFU or something and just happen to not be interested in actually hosting non gemtext documents by sheer chance. More likely it seems it's more a form of gatekeeping than anything about the protocol of document format itself. It's almost like if programmers decided .md files should only be served and rendered to markdown clients over an HTTP-like markdown protocol - yeah, it'll keep less programmers looking at it but there is nothing special that couldn't have been done by serving the .md over HTTPS outside the "cool kids club" portion.
I think that as long as they skip site-supplied css it should be kinda fine.
Desserts don't have network effects. The global hypertext network that we call the World Wide Web is a great achievement. Yes, commercialization has led to some awful excesses. But the Web still lets us all create the kinds of spaces we want, without needing to create separate networks that only a relatively few techies can access. That's why I think Gemini is misguided.
There are even apps for iOS and Android already, largely due to how simple they are to implement (compared to a web browser).
In all seriousness Gemini (the protocol) is really no easier to implement than a subset HTTPS client as both are basically HTTP type commands over a TLS channel. Heck HTTP isn't even the hard part anyways, for everyone worked up about it I wonder how many wrote their own TLS implementation. Anayways don't conflate "every feature and function of a web browser" with "things an HTTPS client has to support" as even "Every HTTPS feature" is out of scope for most clients. When it comes to actually rendering Gemini (the document format) the difficulty doesn't change based on what protocol delivered the document.
Plus everyone already has tooling out their ass for HTTPS from viewers to libraries to debug tools to servers to command line clients to proxies to anything else you'd ever need. Plenty of these existing tools don't even care about the documents being transported, you're free to download a .md over HTTPS via wget hosted on a Caddy server even though nothing in that entire chain has a clue what .md is or should look like. These tools span from running on tiny microcontrollers to abstract high level user facing import functions in apps so it can clearly scale to any use case where you can render to a screen.
Wait until you read about HTTP upgrade mechanisms, HTTP transfer encodings or even 206 Partial Content implementations that are broken everywhere.
HTTP 0.9 was easy to implement, but everything starting from 1.1 and upwards is borderline insane, especially SPDY and QUIC.
While I don't agree with gemini's design decisions (and neither with gopher's), I can fully understand their point of view in regards to unnecessary complexity and side effects of network states.
Source: Building a peer to peer Web Browser, for around 2 years already (still far away from usable).
You want to TOFU certs? Go ahead, HTTPS isn't going to stop you. You want to use client side certs even though most websites don't? Go ahead, HTTPS supports you. You want to use a custom port? Go ahead, HTTPS supports you. You want to leave some features out? Go ahead, you don't have to implement every feature Chrome supports
They absolutely do: I don’t eat a lot of deserts, and so I hang around other people who don’t eat a lot of deserts.
It isn’t a matter of I don’t like people who like cake, it’s just that I don’t want to be around the cake.
Html and HTTP are like that for some people.
People have the rights to do something for fun, and shouldn't be uncomfortable to say it out loud.
It doesn't support Gemini (just yet) but here's my take at a modern, fully-featured graphical Gopher client: https://github.com/zenoamaro/unnamed-gopher-client
I tend to spend hours browsing Gopherholes and Phlogs, but I tend to lose track of where I am. So I implemented a navigation system that I have yet to see in any other Gopher client (or web, for that matter):
- Drill-down Columnar Navigation.
It is heavily inspired by Finder's own column navigation, so if you like that, you'll be at home.
In addition, it has other features that every modern browser should have:
- A tabbed interface
- An omnibar with search capabilities (Using Veronica-2)
- Files and folders view
- Inline image previews with zooming
- Caching
I have many more ideas to contribute back to the Gopher ecosystem without losing its essence (see the roadmap), so if you want to contribute, send ideas, share your opinions, or just show support, please let me know! I hope you like it!
https://github.com/makeworld-the-better-one/amfora#amfora
But I'll give Diohsc a go!
Diohsc takes a little getting used to, but once you start using marks and the queue, it becomes very pleasant.
Doesn’t Gemini expose your IP address? Would it make sense to bundle TOR with the app?
The server does receive it, just like with standard HTTP, TCP, UDP, etc.
Tracking a user's complete browsing history would seem quite easy unless sites add padding to disguise file sizes.
At least with HTTP, most Cloudlfare-hosted sites will support ESNI. Plus there are some other workarounds to avoid SNI on other sites. Better than nothing.
1. Putting an ECH-enabled proxy in front of gemini servers may be one solution. https://defo.ie
From solderpunk, the founder: "When I started Gemini I dearly wanted to specify that TLS 1.3 be the minimum allowed version of TLS."
https://lists.orbitalfox.eu/archives/gemini/2021/007539.html
> AFAIK there are no gemini sites that support TLS1.3 with ESNI/ECH
gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi : 86 % of the capsules use TLS 1.3, 14 % use TLS 1.2.
Not sure about ESNI/ECH stats but TLS 1.3 is pretty widely used.
I could also post markdown files over that too.
Simple is better. But they all have yet to be proven workable from an application standpoint, it seems.
My first thoughts as an older internet builder, is that you're going to need a `mod_php` of some kind, call it `mod_gemini` for Apache to allow hosts and hosting ISPs to basically just have the ability to ftp and present "webpages" (what are they called, "geminipages"?) - same for nginx, caddy, etc. but not as trivial as it needs to present on another port.
Asking people to host their own webserver is basically the biggest show-stopper at this stage. Offering easy drop-in solutions like we used to have in the earlier days of PHP is crucial.
I had a look at the markup and a priori, it seems very straight forward, almost markdown like, which I like. Consider adding support to gemini to popular static site generators like Hugo etc.
From there you can build a small golang or python local client, like the early "dropbox client", living as a service on your computer that would convert html via beautifulsoup or other `outline.com` type converter to gemini on the fly, host it locally including local server, including proxy-ing the web links you visit, stripping all the javascript crap and cookies-we-want-to-fill-your-pantry-click-here-or-die-a-thousand-modals.
Sure, you won't have half the web working, but you still will have most of the important parts. Imagine browsing the web with Safari reader, almost a dream at this stage.
The content is what makes the web, not the interactivity, as much as people would like to believe. The essence of the internet is the thoughts it carries, not buttons that wobble when you hover them.
At that point, you can start talking about caching of online services in the gemini space - sort of like a shared global cache of internet content - with only the content and images/media making it through, start with blogs and websites that care about markup quality... No one will care at this stage because it's too niche, and because you're not caching linkedin or social medias, leave that crap behind please.
By that stage, start thinking about a search engine and classifiers, and you start having your own island of "new internet" going in the opposite direction of the metaverse, and "the people" (basically anyone that has installed an ad-blocker) will jump in with two legs, two arms, and their entire being - they just don't know it yet.
Ironically there is no good search engine for Gemini; there is one at gemini://geminispace.info/ but it is shockingly bad, given how tiny geminispace is
I find it easier to just use google and look for proxied gemini results.
Tiny, lean, minimal and beautiful apps might be cool, but most of them are unusable for me for that very reason.
Is there a good website that provides a starting point / primer for developing accessible apps on various operating systems?
Nothing can ever beat the accessibility of a fully native UI, written with whatever toolkit is most popular on a given operating system. Yes, this means you need multiple completely different UIs, 1Password 7 style.
If you want to go cross platform and still be accessible, go with Electron. There's a lot of material written already on how to make web apps accessible, and that's basically what Electron is. Chromium's accessibility is top notch on Windows and Mac OS and pretty good on Linux (if you turn on a flag).
If, for whatever reason, you're not allowed to use Electron, QT and WX widgets also work, though there are certain controls that don't work that well on certain platforms, so you might need some really terrible workarounds. Same for Swing, which still requires enabling Java Access Bridge if I'm not mistaken.
I think the worst offender is GTK, it's pretty accessible on Linux, but completely inaccessible on anything else. The GTK developers have been promising changes in that regard for years, but I haven't seen those changes yet.
Custom toolkits, SDL based libraries and immediate mode GUIs are a complete no go. The operating system needs to know what kind of controls you have on the screen for a screen reader to work, but "draw a bunch of pixels here" is definitely not enough information, and that's what you get from those. You can implement each platform's accessibility APIs yourself, but that requires intimate knowledge of the platform internals (think COM on Windows) and is often poorly documented (there's almost no documentation for the Mac APIs). If you want to go that route, it's much easier to just go with 3 separate GUIs.
There's some ongoing work to change that state of things[1], but it's far from complete.
I've been making a concerted effort to learn Gemini while still keeping my head, and while I still think the idea fundamentally is pretty useless, the people involved are generally nice to hand out with.
https://portal.mozz.us/gemini/gerikson.com/gemlog/gemini-sux...
Not sure how a subset would work in practice. Though I can imagine a javascript gemini client (as perverse as it sounds...) that could be used as a tunnel into the gemini world in cases where you just want to look something up quickly and/or don't have or want to install a proper client
What I'm imagining is a specification, defining which subset of HTML should be included, together with a <meta> tag which indicates a document's intention to be compliant with the standard.
It sounds like you're expressing disagreement with Gemini's chosen feature-set, but the question being discussed here is whether it would make more sense to use a subset of HTML rather than an incompatible format.
The point of using an HTML subset would be to retain compatibility with conventional heavyweight web-browsers. A feature-rich YAML-based scheme would be neither minimalistic, nor natively web-compatible.
If most users would end up browsing gemini with a regular browser that sort of thing would be commonplace.
Some of the goal is to prevent it from being so easily infected with tracking, malware, and other anti-user mechanisms.
Another goal is to make the presentation be truly a function of the client, and not the server.
Is 90% of it crap? Sure, but 90% of everything is crap (sturgeon's law), and it feels less corporate than the current internet. Also people seem to be less angry (on average).
Gemtext is easy to parse since a parser only has to read the first characters of a line to know a line's semantic meaning. Being line-oriented also improves a document's structure, as it's easy to navigate with links getting their own line.
That's the rationale for using a different protocol scheme and markup.
Interesting point, it would be unfortunate not to be able to distinguish web links from links that commit to using only the subset. It doesn't strike me as insurmountable though. Off the top of my head, file-extensions and/or MIME types might work.
Why wouldn't file-extensions work? HTML uses .html and .htm.
Why wouldn't MIME types work? HTML uses text/html.
https://seirdy.one/favicon.ico (hint: it's not a .ico file)
What can you infer only from the URL, before you click? File extensions show server side file formats, which reveal information about the backend's file representation; these do not necessarily correspond to the mimetype. .php, .asp, and trailing slashes are all examples of this; a trailing .html only means that the resource is (probably) a static file on the server, but neither gemini not the Web (nor even Gopher) are necessarily against dynamic content.
Furthermore, web servers can send a mimetype header along with an "x-content-type-options: nosniff" header to make compliant user agents disregard the file extension and use whatever mimetype the "mimetype: " header supplies. I personally use this to deliver a PNG favicon when a browser requests "https://seirdy.one/favicon.ico". The file extension tells you nothing if the scheme is HTTP(S).
If you see someone link both a gemini and an https url, you know what the difference is in advance and that can inform which one you click.
The point of a scheme is to supply a guarantee about what standards a URL will conform to without reading the response. This is necessary to inform the behavior of the request itself, and as I've just explained it can also convey information to the user before they choose to make said request.
Thats not what they are talking about. They explicitely said using existing browsers, not making your useless html4 only browser.
A small community can have fun with it. Nothing else.
One no-brainer thing that I wish Gemini would add is proper footnote support. The reading experience is kind of a pain in the ass if you can't quickly get back to where the note was introduced.
It's a policy choice.
Using Gemtext and Gemini makes you acutely aware of limitations, so eventually you either stop using it, or start enjoying it, with most of Gemtext readers sharing the experience.
Using a limited subset of HTML is an exercise in self-restraint, with the ability to go full ham on JS and CSS always being there, but you abstaining from sin. With most of browsers hardly sharing your desire for a JS lent.
There is nothing technically precluding browsers from supporting Gemini and Gemtext eventually. However, the idea is that contemporary browsers are not really interested in supporting it. Having a separate client instantly carves you out an entire world to live in and gives you 100% mindshare in that world. Shoehorning your document format into what browsers support right now gives you 0.001% of the browser world and its mindshare.
A core part of the idea is that with Gemini you know what you're getting when you open a link. If I wrote a blog with a very very minimal rendering (which are nice) and I put the link up, you wouldn't know it from blogspam until you clicked it. With HTTP a link can deliver anything. It is reassuring to know you're getting a document to read and nothing more.
The restrictions on what you can do are a feature. I want to know that when I'm in the mood to just read that I am not going to have a video autoplay and get asked to sign up for a newsletter and have to accept cookies and have infinite scrolling recommendations and a nested menu unique to your site. And when what I'm about to click starts with https:// I have no guarantees.
It gets a little walled off feeling, and that's OK. If only a handful of people care about this thing, then it works. If it becomes widely used, that's cool too. It isn't intended to take over the world, it is intended as a tool, to be used by people who have a use for it.
It's a pretty specific community, but if you like that stuff you'll probably fit right in.
The early web was all "hypermedia" and people already stuffed images and videos and java applets. Geocities was all animated gifs. Gemini is more like gopher, if it was designed in 21 century.
Gemini does not even have forms, or cookies, or logins, or even any way to input larger text, or write. Intentionally.
Of course people try to hack around that and use the query argument for input. But in general, Gemini is almost actively fighting that.
No affiliation, just happened to stick in my memory for some reason.
Gemini is not so rigorous with formatting as gopher; in Gopher, the different clients can format the paragraphs and do their own thing.
The TLS is the most problematic part, for me; as Gemini decided to go with TOFU, which is IMO horrible in web-like setting; and the TOFU itself is vaguely defined and the specs basically says "client and servers can ignore it or whatever". But it's simple indeed.
Most modern clients default to using TLS and failover to plain text as far as I know.
It is a shame that a lot of current Gopher users seem to be strongly against anything apart from standard Gopher, when the original authors of the protocol had much grander ideas for interactivity & visual interfaces. Sigh.
For anyone interested, the Gopher+ protocol doc never made it to a proper RFC, but is on github in a hyper-linked format to make it easier to read: https://github.com/gopher-protocol/gopher-plus/blob/main/gop...
https://github.com/gopher-protocol/gopher-plus/blob/main/gop... specifically mentions 3D representations of Gopherspace. They also provide provision for a "general purpose" scripting language - I think Javascript would fit the bill - there and in section 2.8
When talking about this people are usually refering to this section of the spec: "Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.)."
But that only says that you can't automatically fetch images (or other resources). You can still make a network connection if the clicks on the link, for example.