We already have a transport protocol that "everybody" agrees on: HTTP. We can define a specification for a subset of it, and a subset of HTML/browser features we want, create tools around them, and form a small community.
The advantage here is that the community is not an island. Users of Big Browser can still read your latest rants. They can even learn about this project and, while perhaps not using Mom-and-Pop browser, may support it in their sites, since it wouldn't require another server; mostly just having their site work without JavaScript would be a huge step forward. Right, you don't have Google filtering based on Accessibility. The community can create a search engine that does. Now what? You just get on with your life, producing and consuming AccessibleWeb content without the gratuitous incompatibility.
The whole point of this project is to shrug off legacy. Yes, that means reinventing a few wheels.
I'm more terrified of the average electron app or java app than I am scared of a single browser tab.
While web sites can avoid JavaScript all right, browsing most sites does require JavaScript. As a NoScript user, I'm keenly aware of how many web sites simply do not work without JavaScript.
And I'm not even talking about all the third party spyware.
The fact that this has attracted a fair number of gopher users (who have always very strongly opposed http/s) would seem proof enough of it's success, imo, at least within particular circles, and at least within the context of its goals. It was never intended to draw people away from the web, it was intended to be a sort of superpowered gopher.
For example, i'm thinking of a roam research like content platform, without tracking and ads. It would be interesting to see shared content around that.
Sometimes it is just the latest trend...
Please no. No more everything-over-http. There are other ports besides 443; there are other protocols besides HTTP.
The Internet was once a general purpose peer-to-peer network, and we should try to keep it that way.
However Web still has its place in Google, Wiki, and Shopping. The three things has one thing in common in that they need multiple tabs to keep data and Information.
This is like pushing for stone cart wheels when spoked wheels are already available.
For instance, if the issue is with the use of cookies, all they need to implement is a mechanism for the server to not respond to cookies in any form.
If there issue is with other forms of tracking, they could implement a browser which supports a small subset of the HTTP protocol which does not allow any tracking of any kind.
---
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscle fraction of websites it could render.
They did. That's the Gemini protocol. I recommend reading the spec to properly understand the constraints they were trying to meet.
This is similar to the driving motivation behind RSS: it was supposed to be something for simple static sites to put up, such that gateways could then poll it, before turning around and doing something more technologically-complex to actually deliver the events, like using WebHooks, or sending emails, or doing whatever PuSH does.
Big Browser is the cause of so many problems that people on HN complain about. Without the control over Big Browser that certain offending corporations have, their empires are considerably weaker.
Mom-and-Pop Browser is probably not an accurate caricature. Maybe something like End User Browser is more apropos.
If most HTTP is being sent over TLS these days, and Gemini is also over TLS, one could argue there is no "incompatibility". Gemini just doesn't need to all the extra ad-hoc functionality that has been built on top of HTTP. It is intended for data retrieval, not something that relies on help from the 20+ million lines of code in Big Browser to achieve.
It looks to be a reimagined gopher with some early web parts. Which makes me wonder how close their protocol is to the gopher one.
this means you can create a far simpler protocol semantically: requests are just the uri, responses are just a header of a two digit response code and the mime type, and the rest of the response is just the content as raw text. that's the entire protocol grammar.
This allows hyperlinking to the accessible version of a page, and using different default browsers for the different protocols, so that I (as someone who wants to use Mom-and-Pop browser) can easily fall back to Big Browser when necessary to view a page that won't render over accs://
What about using something like https://gemini.site.com ?
And part of that restricted spec would allow linking only to such links, to stay within the network ?
And the biggest challenge with Gemini is creating a great search engine. But now , searching site:gemini.* KEYWORD , gives us the power of Google and other search engines.
But with a lightweight protocol like this, it seems easy to set up a proxy that would let anyone access the content via web.
- https://portal.mozz.us/gemini/gemini.circumlunar.space/ - https://proxy.vulpes.one/ (also does gopher)
My question is: what's stopping us from doing that?
> Gemini lacks in-line images
This is the only part that I don't really understand about Gemini. Even the most basic printed publications can include illustrations. <img> got added to HTML very early on because sometimes it's hard to share some piece of information in anything but a visual form.
I write a (mostly) technical blog that certainly focuses more on text content than images. I would be happy to throw away the header, sidebar and the rest of the "design" cruft (in fact my blog is perfectly usable in a browser that doesn't support CSS or Javascript) But I can't imagine having my posts without graphs, diagrams and photos inserted in the text.
If the fear is that in-line images would lead to frivolous use as ads or "useless multi-megabyte header images", then maybe a better approach would be to limit the number, or size, of images on each page? Some scientific publications do exactly that in an attempt to force the authors to focus on selecting only the most important images that need to accompany their papers.
The best possible limit is "must convince the reader to click it".
On the other hand, it made me think of old Usenet posts and discussions. That was another medium where you were limited to plain-text only. Posts were often forced to resort to awful ASCII-art drawings of things they wanted to explain and that was just a horrible experience altogether (not to mention how fun those drawings are to decipher today where modern archives have mostly messed up the white space).
Adding images requires more requests and breaks the concept of "one url/document == one request". I love that I know that my client will do nothing I do not tell it to do.
If you want to use gemini and you want inline images I believe https://proxy.vulpes.one does inline images of some form or other.
That said, images have other issues beyond causing page loads/requests to be unpredictable: they are an accessibility nightmare (as we have seen on the web).
Audio is an accessibility nightmare for people who can't see, text is an accessibility nightmare for people who can't see or people who can't read, German is an accessibility nightmare for people who can't speak German.
At some point we have to accept that not every way something is presented is going to be equally accessible by every person, but the solution isn't to just decide we should jettison a rich form of communication because there is a small subset that can't fully benefit from it. Even books that are expected to be used by people who can see all the images usually describe the purpose of the image, what it is illustrating, and why it was included.
By this line of reasoning, you would have to manually approve every init process that your computer would want to start every time you boot it up.
"images" == "client doing things I don't tell it to do" is completely false. Clients have been built that have configurable policies for loading images and scripts, and they're conceptually very simple and easy to use - e.g. "don't load images by default, click to load temporarily, control-click to load and permanently whitelist" is an example of a user-agent policy that not only supports images, but conforms to your extremely convoluted definition of a user-agent "do[ing] nothing I do not tell it to do."
> requires more requests
Is the purpose of a document browser to minimize requests, or to actually serve useful information? Images can encode data that cannot be encoded in text, and a vast quantity of information is much more easily read and understood in graphical form. If you want to minimize requests, then just don't use the web at all.
Also, this isn't even necessarily the case. You could encode images as part of the page, as base64 or something.
> they are an accessibility nightmare (as we have seen on the web)
The web supports alt-text for images. When people don't provide alt-text, that's not a technical problem, that's a social one.
This is solved by HTTP/2 multiplexing https://en.wikipedia.org/wiki/HTTP/2
> breaks the concept of "one url/document == one request"
I don't think anyone cares about this "concept"
I exploit this in my Unnamed Gopher Client[0], a client for the predecessor of the Gemini protocol, where I render links in a familiar files/folder format:
https://i.imgur.com/dw3e4Ou.png
And there are many more creative things that can be done with this.
Related: why can’t we just point the blind at a protocol optimized for just sharing text documents?
Managing image assets is tedious. The web design community still by and large hasn’t figured out a great standard way to do for images (versions with reversible/cherry-pickable diffs) what git does for code.
Instead, diagrams and formulas could follow the lovely ideas of mermaid, graphviz, dot, and mathjax inlined into the markdown as text. Tooling for VSCode handles inline diagrams beautifully for Markdown already.[1]
And then, inline SVG would let you illustrate nearly anything.
WSJ got by fine without photos, as did most journals for most of my lifetime, and Kindle books mostly don’t have them today. I wouldn’t be too quick to say a medium has to be filled with photos.
1. https://github.com/shd101wyy/vscode-markdown-preview-enhance...
If you mean something like Base64 encoded inline images, then those might be viable.
If we can have spam filters for email, we can have ad filters for images.
Streaming video is probably here to stay. /s
I would really like to see structured text that is self-descriptive (e.g. this is the document title, this is a paragraph, this is a header, bullet list, etc.) but have no ability to influence HOW those things are displayed- eventually maybe we'll have browsers that can support rich theming, etc.
Others have noted that lack of images is an oversight. Perhaps the language needs a "binary file download" structure, and if the binary in question is a media file, then the browser could choose to display it. Maybe signal with mime types?
Worth noting that this is modern browsers/web, and was initially not like this.
The term "user-agent" comes from that the _user_ has control over the experience, no matter what the publisher thinks. The agent (browser) acts for the user, hence user-agent.
User-agent CSS files were rampant back in the days, when a lot of content was unstyled. So you could navigate between websites and they looked the same, as they would use your user agent css files.
But then everyone decided they had to have a unique look on the web (CSS). Then they decided they needed unique functionality on the web (JavaScript). And here we are :)
users then predictably wanted pages to look different, to have style, and that's likely the principal cause of user stylesheets' decline, not corporate coercion. that's not to argue against user stylesheets per se, but that they'll likely never have wide usage.
It's also the reason why it caught on. On one hand people reject the ability to express individuality on the web, on the other a similar crowd is nostalgic about geocities and praises similar revivals. It's either one or the other.
> I would really like to see structured text that is self-descriptive (e.g. this is the document title, this is a paragraph, this is a header, bullet list, etc.) but have no ability to influence HOW those things are displayed- eventually maybe we'll have browsers that can support rich theming, etc.
How about publishing markdown over HTTPS? Then make a client that renders just that?
I like to think about books as of an example where content is way more important than presentation. Most of the web sites these days spend a lot more effort on how you present it than what, in the end a 1000 thousand words article now has a very complex architecture behind it, hundreds or thousands of time more than the content.
For that matter you can serve images or whatever binary files as individual requests (that is, not inline with another repsonse).
I've been playing with it and I rather like it.
TLS: keep it as it is. Crypto is hard and TLS is proven crypto. Mandate something like 1.2+ and be done with it. Every mature language has TLS implementation or bindings.
HTTP: use subset of HTTP/1.1. Parsing is very easy: it's just bunch of lines. Full HTTP/1.1 is hard and probably unnecessary. Things like connection reuse are not necessary and should be excluded for simplicity.
HTML: use subset of XHTML. It must be valid XML, so parsing is just one call to the XML library which is available on every language.
CSS: I don't really know, that's a tough one. Something like CSS 2 I guess. There must be a balance between complexity of implementation and richness of presentation.
JavaScript: just nope. That rabbit hole is too deep.
If you take this position to the extreme, you can even reduce HTML + CSS to some kind of markdown-like language, but I don't think that we need to go that far.
A good WWW provides linked documents in a format that is easy to display and process (e.g. extract links, text, headlines, images, etc.) and makes it impossible to hide content. If you publish a document, it should be publicly accessible.
So like I said, you've basically just described gemini :)
Re:XHMTL: as somebody pointed out here, there are rules to "normalize" unbalanced HTML5, but they have to be implemented and add to the mountain of "implicit" knowledge one has to have and implement...
a body with sequence of <img>, displayed vertically. you can look at imgur and see such format has been used for simple messages, blogs, collections of memes, recipes, news, informational content, engineering content, fitness advice etc etc.
no css, no nothing, the user agent takes care of formatting them according to the display device etc.
I can't think anything more flexible, simpler and yet capable of doing 90% of what the static web can do today. you can even have a comments section, just add <img> to the bottom and alt the commenting user&Timestamp.
HTML5 defined a concrete, final mechanism for parsing tag soup and presenting it as a standardized tree. While the library itself isn't simple, using it is, and being standardized, most non-fringe languages ought to have a library for it by now. It should probably use that, for all the same reasons trying to use XHTML didn't work the first time. XHTML raises the bar on writing correct HTML too far.
How is a network protocol proof against being used to transport CSS files? Does the network stack inspect what you're shipping and ensure you're only sending 100% Pure Plain Text?
> The Gemini transport protocol is unsuitable for the transfer of large files, since it misses many features that protocols such as FTP or HTTP use to recover from network instability.
Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?
Finally:
> Now, what does Gemini currently have to offer? The best way to find out is to head over to the official site: gemini.circumlunar.space in your Gemini browser.
Back in the Gopher days, my "Gemini browser" would be my Web browser. That was one of the reasons Web browsers took off: You could use them to access all of the information on the Internet, including the WWW, Gopher, Usenet, and Email. Only more recently did Mozilla morph from the Netscape Communicator software suite into the slimmed-down Firefox browser without email, spinning off Thunderbird in the process, and only much later did Firefox drop Gopher support from the core binary.
maybe he’s talking about higher level features, like the possibility to restart a download from a certain point, without redownloading the initial part? haven’t used this since dialup days, though
> Gemini has no support for caching, compression, or resumption of interrupted downloads. As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection.
That said, I can't tell whether or not I've used it recently. I know I don't use it when I play with personal projects, but I don't know what other sites do because I rarely have a console pulled up in my browser when I'm just using it, rather than developing.
The Gemini specification includes its own format for pages, which is a text-based scheme inspired by Markdown and Gopher menus. You can use the Gemini protocol to transmit things other than Gemini pages, sort of like how you can use HTTP to transmit PDFs and Word documents, but you wouldn't build your whole site out of them. (At least that's my impression, I haven't gotten around to actually visiting many Gemini sites yet.)
It's just like the web, the transport protocol (HTTP/S) can be used on any file. But there is a separate spec for the document format (HTML etc.). You could transport CSS over Gemini, just don't expect any of the browsers to render it. Just like how web browsers won't execute alternate scripting languages natively.
> Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?
I didn't really elaborate on this point while writing, because I had nothing to add. I will quote from the projects FAQ:
>> Gemini has no support for caching, compression, or resumption of interrupted downloads. As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection.
Hopefully that clears up what I meant.
> Back in the Gopher days, my "Gemini browser" would be my Web browser.
You might be interested in Castor[1]. It's a browser for the minimalist internet. Rolls support for Gemini, Gopher and Finger all in one.
I can understand why FF removed support. But hopefully smaller applications, like Castor, can fill this gap.
Which honestly is pretty silly, as lots of caching is about reducing latency for small files not saving bandwidth for large files. Suppose it matters less if the documents are self contained.
If Gemini is ever of even domain-specific serious use, I'd expect both the format and protocol to be added to what is supported by existing major web browsers (it can't be both tractable for small implementers and intractable for Apple/Google/Mozilla), which, as it turns out, know how to support the combination of HTML/CSS/JS just fine and won't likely forget just because a different transfer protocol is involved. Presenting a DOM mapping for Gemini format pages and exposing it at least to extensions even if there is no way to include page scripts doesn't seem unlikely, either.
I know it is an idealogical choice to only have text, but being able to embed standard image formats (on a totally plain, non fancy way) would increase the utility of this hugely. They mention blogs and tutorials and recipes here - those would benefit hugely from having simple inline images within the body of the text, just like you expect in a newspaper etc.
I guess I am not the target market then.
If I were designing it, I would say: "you can have images, but they always display as a 'block element', with nothing to either side. No worries about wrapping text; no background images under other elements, etc." I think that keeps the spirit of simplicity.
It's text. The client displays that text and renders links, headings, etc, however it wishes. If it really wants to, it could just not format them at all. There's a gemini client made for plan9's acme text editor that doesn't render links, and instead displays them verbatim, because the plan9 plumber can handle the hyperlinking aspect. All of that is eye candy and fluff.
If a client finds a link to an image, it can in-line it if it wants. If you wrote a client, when it found a link to an image, it would in-line it "with nothing to either side." That's not something that has to be specced.
Same with how headers are displayed (maybe i want folding or something), whether an ToC is displayed, colours, fonts, etc.
The point is that the user can decide all this stuff, without having to hack it around the author's own styles and scripts.
Technical paper is what I was thinking about there. Furthermore, since Gemini apparently lacks support for mathematical notation images would be necessary for such even if the paper doesn't intrinsically contain non-textual images (e.g. pictures, charts, or graphs, which are common though not universal).
I can even understand why they did it. To keep the doc format very simple.
I hope that more clients will add unique rendering features that will turn this drawback on it's head. It could be in-line rendering or a gallery-like feature.
Setting it up on a separate protocol / markup allows you to make hard reasoning about what kind of privacy, features and protection you get as a user, rather than relying on the goodwill or current promises of your content provider.
It'd be better to declare a new doctype and use a reduced html. Just make it simple and make ads and JS bloat impossible.
Enforcing ssl is kind of silly since browsers are starting to do that anyway independent of this. It's orthogonal.
[1] gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/why-not-just-use-a-subset-of-http-and-html.gmi
He goes on to say 'Supposing you had such a browser, what would you do with it? The overwhelming majority of websites would not render correctly on it.' - A very good point, but equally applicable to a Gemini browser.
IMO, they have confused the network protocol with the presentation. You don't need to drop HTTP in order to change the way websites look. Likewise, you don't have to implement HTTP features that you don't like (e.g. cookies). This just strikes me as another mistaken belief that rewriting code from scratch will solve all your problems.
Building separate protocols for all the various use-cases of the web would be interesting, but would still need some interconnection. But I'm not convinced that has many advantages besides not being accidentally linked to a websited of the "Old web." A problem that could be reduced by a browser extension that strictly blocks any external urls and javascript.
There was a protocol for searching documents, a protocol for looking up someone's email, it was all partitioned out.
The web was seen as just another fish in the pond.
After the web became big, these things still lasted for a while
However spam and crooks changed it all. Usenet became useless, DNS full domain lookups (you used to be able to get a list of all the subdomains of a domain through the command line and you could just browse then out of curiosity), using whois for email (you could just query for a name and get an email address over whois), it's all gone because there's too many snakes trying to scam people and flood the network.
Things used to be much better tools but it turns out they were too good and had no defenses. The dream of everybody connecting has sort of been retracted a bit. RMS, TBL, Torvalds, I could just send them an email in the 90s and they'd respond, it was pretty remarkable.
It's not the case any more. Not even minor players in history (such as an author from a 25 year old book) respond to my questions. People just don't do that anymore.
Spam, harassment, criminals, ill will, this all has to be a big priority if we want to try it again.
The future should be the dreams of our better angels, building better tomorrows...
I don't think this stopped just because of spam, harassment, or other bad behavior. A big part of it is just community size. When the community of internet users was smaller, you could interact with everyone who reached out in a reasonable amount of time. As it got bigger, that is no longer possible because of the sheer number of people.
This is an exceptionally good point. Security is also one of the top problems with the web (alongside the asymmetrical difficulty of hosting content vs consuming it and the lack of consistency for web content). The problems with the web are mitigated by "good enough" solutions from browser vendors, out-of-band third party extensions and even some services on the web itself (e.g. archive.org, though I don't know how sustainable that is, and it's far from perfect).
Whilst using Castor, www urls would auto-open in Firefox, and the other way around.
From an individual point of view, there's not much of a difference. If I wanted to migrate my blog to Gemini, it would take very little and it would lose almost nothing. But the second you click a link to another domain you are back in the bloated web.
Once you open a Gemini page, however, you know exactly which experience you are getting. No bloated websites are allowed, so you won't see those at all,ever.
The issue isn't bloated websites as much as the web itself.
Introducing new technology doesn't change the technology everyone else is using if it doesn’t provide a reason for them to switch. Gemini seems to appeal very much to the issues of a very narrow group of users and, I suspect, an even smaller proportion of content creators. I don't see how it has any effect on the technology everyone else is using.
The creator of Gemini has a post about this, linked above.
Probably won’t stop someone from trying.
(Nothing stopping you from building a browser that handles gemini format documents and does special things with JS links, either, though to avoid accidental execution issues you would probably need to extend the format to distinguish “links I want to execute” from other links.)
[0]https://portal.mozz.us/gemini/gemini.circumlunar.space/softw...
So the selling point of Gemini is that by staying rudimentary, it can limit it's appeal, and subsequently stay unpopular enough to be more like "The Old Web". I think that's worth noting, because you could get trapped into thinking this is a technology problem, but it's really a people problem.
However, Gemini does not exist in a vacuum. The web will be there. There will be social media platforms, multimedia, awesome webapps and all that. And Gemini is just text.
When you have the choice between easily consumable infinite multimedia and just text, you only pick the latter when you really care about the quality of text content. It's not sexy so all the spammers, content marketers and ego boosters have nothing to gain on Gemini. And so there can be this esoteric little corner of the internet, with down-to-earth text content written by ordinary people.
Your implication may be true, but Gemini will never become as popular as the web (well unless the web becomes extremely unpopular at the expense of something else besides Gemini).
My wife would see "no images" and that would be the beginning and end of using Gemini for her.
> The server closes the connection after the final byte, there is no "end of response" signal like gopher's lonely dot.
This just seems like a bad idea, especially if one is on shitty connection.
Since the response body is not encoded, there's no safe end-of-response marker byte(s) to use.
So content-length seems like the way to go. But knowing content-length ahead of time is difficult for dynamically generated content (CGI is supported after all), so they also need something similar to HTTP chunked encoding, which does complicate things a little.
I understand that keeping the Gemini client simple to implement is one of their design goals, but I don't think the same is true for the Gemini server. So I hope that they would consider adding these to the protocol. They could probably stuff the content-length or the word "chunked" in the <META> string.
I feel like that would strike reasonable balance. Client are still simple (arguably more simple since they don't have to guess if they got everything) and the protocol is still trivial. For dynamic content, it would increase time-to-first-byte and ram usage on server, but both imho would not be an issue for the type of content gemini aims for.
I think it gets updated semiregularly.
and also
> it misses many features that protocols such as FTP or HTTP use to recover from network instability
What? These statements are at totally different levels of the OSI model.
about network instability: it doesn't refer to congestion and packet loss handling in TCP, but to the "Range" feature of HTTP, which allows downloading only a subset of a file, to resume an interrupted TCP connection.
I think you might have misunderstood the latter, which just refers to the Gopher model having no transfer resume functionality, such as HTTP Ranges, meaning an interrupted transfer must restart.
I mean, for example, if Gemini evolved, it would still somehow be what the web became!
I have to admit that this opening statement almost stopped me reading the rest of the article. Which is a pity, because Gemini does sound like an interesting endeavour. I went searching (via the bloated World Wide Web) and found the Gemini FAQ page (https://gemini.circumlunar.space/docs/faq.html) which (in my opinion) makes a much better argument for considering this alternative approach to delivering content over the wire.
> I could totally see Gemini being used as an alternative particularly for the non-comerical individuals who use text as a primary medium. Blogs, poems, recepies, tutorials are perfect for the Gemini format.
The one big thought I had - as a content developer (I write poems: I will never apologise for this) - as I read through the FAQ was: "Yet another distribution channel to maintain" ... because Gemini reminds me (probably unfairly) of WAP and its Wireless Markup Language. Back in the day I was very keen to inflict my poems on everybody in the world: I posted them on Usenet (mainly RAP), various web-based bulletin boards, a Blogger Blog (with a blogroll!) and, of course, my own poetry website. Reaching out to a mobile-centred audience was the next logical step. But the mechanics of the effort defeated me, and I soon grew to truly detest WML and its stupid limitations.
I suppose, in 2020, adding another communications channel to my current website's toolchain should be a lot easier ... but I don't want to do the work. If the people around Gemini can get more passionate content creators to do the necessary work, then maybe it will have an interesting/exciting future?
Don't apologise, share a link!
I’ve always wished browsers handle site menus in their chrome, so that the document can be focused on content not navigation. It’s the browsers job!
For a while Opera supported these related links in the head for some pages but the dev was unable to add their own, it was limited to a small number of standard items such as Index. These were shown in a browser toolbar.
Nonstandard navigation have always been a point of friction for users as it precludes universal access by having to relearn how each site works.
Mandating the reliance on third parties in the protocol itself does not seem to be a great choice. If I have a simple webpage which I use as a daily diary, why should I go to the trouble of asking a random third party to provide me with a certificate?
And really,why replace http? The complaint seems to be mostly with html, so why not just makr a gemini text format,build some browsers that use that as the default instead of html and specify semantics for how tls works, like custom status codes to request a client certificate and recommend TOFU certificate trust. And maybe specify certain headers that shouldn't be used, like cookie.
I mean QUIC is here, waiting for us.
Why throwing away 30 years of HTTP ideas . If images and cookies are to be forbid that should be made from the web developper decision.
Choosing Gemini is like accepting restriction by law. I feel like this is old behaviour, that confidence and responsability is the way forward.
In a way Gemini could have been published by writer of European Union , North Korea or Soviet Union laws, I can't belive this is a US products, as it contains too much to liberty constrain ;)
Unfortunately even today that's not 100% under your control. I don't have to accept cookies nor load images from your site with the proper settings or browser.
You seem to be forgetting HTTP is a user-initiated protocol and while a lot of it is hidden behind Javascript and common browser features, ultimately it's the user agent that initiates everything. You as a web developer can only control the files on your webserver, put cookies in headers (which the user agent has to send back to you) and possibly take advantage of some other Javascript features like DOM storage (which I can turn off).
I'm 100% on board with Gemini being a 'liberty constrain' for those who put information online - honestly it's not necessary for remote systems to be executing code on my system just to display text. Yes, you can't monetize it as easily. That's a feature, not a bug, for a user like me.
If I wear a polo and dress pants, and I'm on the train at 8am, I'm going to white collar work. If I wear jeans at the same time and have my partner with me, I'm a middle class, middle aged, probably-parent on personal business that could probably be described as "running an errand". If I'm a 42 year old man wearing bright purple halter top, with black lipstick and combat boots on the train at 8am--you don't know me! Where the hell am I going? How am I living? You don't understand how to talk to me, so don't bother unless you are a 27 year old woman with red eye liner, green air, blue lipstick and a brady bunch t-shirt on! We wouldn't understand each other!
Elaborate protocol jokes aside, it's an apt analogy. It works--for some people, some of the time. They are dreamers living life waiting for a tomorrow that may never come, but the cause gives them their identity. Chances are that Bob and Linda still have to straighten up on Monday mornings and assimilate to the general protocol. But that's the world we live in, is it not?
I like it. I don't like to deal with it when I'm at the bank or the brokerage, but Friday night, it's alright with me.
I don't begrudge their them identities. However, it's a weak, unopinionated protocol. No inline images? Just because you support them doesn't mean they don't exist.
Users will have their inline images, and they will build clients, and the protocol will be defined. If not by you, then by someone else.
That is the story of the modern web, and that is, funny enough, how we got here.
Nostalgia isn't productive. A new protocol isn't insurmountable, but it has to be native to the time you are living in. You don't need to necessarily inline videos and graphics, but you need to define how these should be handled, or at the very least, the boundaries of the protocol. Waxing whimsically at people creating readers to handle inline images in an ad hoc way... lol, why? Why are they doing this?! They were just bemoaning the current state of the web! My god, have some foresight!
Make a protocol, make a browser, define the boundaries and perhaps adjacent protocols, set your browser roadmap accordingly. Stop when you feel the coverage of the desired space is sufficient. If that's text-only, fine. But you must have answers to how an image or video should be served to the good people of this community.
CommonMark currently has no tables, it's up to other markdown dialects to add it.
Related discussion: https://talk.commonmark.org/t/tables-in-pure-markdown/81
this is telling. not only it's inconvenient, but claiming link to images are good enough for blog and recipe pages makes me think the audiences are completely misunderstood.
weird because text driven interface like airline reservations still exist and porting them on a common protocol would provide immediate tangible benefits today without the backward thinking about media
I don't get it.
The main advantage this has is that it will not get popular enough to experience the scope creep that the web did so will probably remain relatively pure.
Soo umm. Just use netscape 2.0 (+modern TLS)
Everything I find on Gemini will be compatible with my browser.
Having a "web browser" that can't do interactive content at all (no, server-side CGI doesn't count) is a non-starter in 2020. What if I need an interactive chart?
"When I picture it in my head I think of the early web as more of a library.
Over time it has transitioned into a shopping mall."
- chris_f (Hacker News comments)
If Gemini sounds like a dumb idea, I'd highly encourage you to move along. If Gemini sounds intriguing, you'll probably have fun.
Lots of opinions in this thread, but doesn't look like many armchairs have tried it. Personally, I've enjoyed the rabbit hole.
1. Gemini is great, no spam and commercial crap
2. Someone realises it would be great to have simple inline images, and makes a cool client that supports “gemini+img” syntax that they make up. The syntax gracefully degrades, so you can use it in your docs even if your users aren’t using the new browser!
3. Protocol is technically text-only but in reality everyone uses img-enabled browser
4. Repeat with basic styling, then simple scripts. Eventually authors rely on more and more “optional” features and syntax extensions, and we end up with a similar feature set to what we have today.
5. Advertisers move in as Gemini gains mainstream adoption, and we’re back to www
Go read the mailing list. Implement a client in your favorite language, or that weird language you've been wanting to try...
Write a blog, or some fan fiction, or a screed or some poetry. (There's a choose-your-own-adventure you can play.)
Have fun with it.
- ToS that strictly prohibits commercial use and advertising. We have the WWW for that, no need to duplicate it.
- Uses HTTPS or something similar. This allows use of efficient servers like Nginx.
- Based on a virtual display with fixed dimensions and orientations, 2-3 aspect ratios and vertical/horizontal orientation. Fixed virtual pixel solution. Every page is fixed in size and in the length of unicode text it can display.
- Uses a structured document format with a limited number of logical tags. The client displays the page as it likes (no styling directives in the document markup). Every page written in this format is compiled into an efficient and compressed binary representation for transmission.
- Limited number of links, overlays, and images per page. Input fields with validation should be allowed. Inline images and movies are limited in size.
I'm planning to implement something like this in my forthcoming virtual Lisp machine (z3s5.com), though it's going to be a bit less general and probably not be based on HTTPS.
https://github.com/electronstudio/2face
Currently it’s TUI, but will add GUI eventually. It’s fun to have a protocol small enough you can implement it yourself, but I currently have a weird bug where some Gemini servers work and others don’t because they don’t seem to follow the SSL spec.
Also, some of the CSS and JS hatred is piffle. Publishers absolutely abuse these languages and it gets pretty bad on news websites especially. But I do not find that most or even many of the sites I visit perform badly on my hardware (2016 iPhone SE and a 2017 MBP). They work fine. Moreover, I appreciate nicely designed and competently implemented experiences on the modern web.
I have no interest in trading the modern web - warts and all - for some spartan plaintext utopia.
Its probably going to stay as just an idea because other projects have priority.
1. No tracking beyond what the server gets via standard logging 2. Document styling control in the hands of the user agent 3. Navigation control in the hands of the user agent 4. Compatibility with existing web browsers would be a bonus
Points 2 and 3 imply some kind of semantically-clear markup. Would definitely want to think of forward/backward compatibility (something the web has been fairly good at).
Point 1 means no cookies, likely nothing like JS, images need to come from the same server (either packaged in the initial request or forced to come from the same host).
Point 4 is a nice to have and may be possible if this is built on a subset of HTML and HTTP. One possibility is that if the server receives a request that looks like it's coming from a standard browser, it can serve up the page with some JS and CSS that fill in the stuff that would normally be done by the user agent.
IMHO, something built on a stack that looks like that would be a better fit for 2020 than something based off of Gopher's approach.
The author mentions that fancy Gemini reader apps could allow linking to images, since that some terminals allow images to be displayed[1] that would fit nicely too.
Why not just use text based websites and something like w3m? Well it's hard to tell when opening a link in the terminal will be useful and when it would be better to open the link in a "real" browser like Firefox.
e.g. after a git push to github I'm provided with a link to create a PR. I really when I click that link I really want it to open in Firefox.
[1] Off the top of my head Kitty and iTerm2 both allow image display from apps such as the ranger file manager.
Yip and gemini's markup is so simple that it is useless for me. :-(
Combining a restricted HTML maybe with 1-file-only limit (use data url for insets) with gemini's protocol could make sense for me.
"rHTML" like PDF, all in one file, maybe a bit JS for rendering maths, but maybe there are other/better ways to do it (no maths in PICs please!).
Or brutally different? Distribute DVIs over gemini://?
I like the 1-file-only style in the dimension gemini and apart from not yet having automated images to data-url-conversion, ... sigh ...my image-less HTML stuff already is 1-file-only.
Then again, which script would you use?
The overall web itself is going WASM for a lot of projects. Pure javscript that is actually readable isn't exactly common now either as more frameworks build multiple layers on top.
I see this as an interesting step sideways. Less is more and all that. Perhaps check in 2 years from now and see what major shifts it caused.
Honestly the web could be great with the technologies that are out now. At this very moment. But it isn't.
This is never a good idea.
JK, interesting read but the idealism is stronggg.
[1] https://rreusser.github.io/explorations/sphere-eversion/
Frankly I think a lot of commentary stems from backend people being annoyed that frontend people earn a bunch of money for work they deem insignificant.