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.
Why? I actually think it’s pretty clean. You have a one-to-two letter opening tag and an equivalent closing one.
Markdown looks aesthetically nicer and is easier to type, but it’s less precise.
Maybe it would, slightly. But would it make the browser anymore complicated then the unessential features that Firefox has in its default build right now?
Pocket integration, FF Sync, some screenshot function?
The web is so broken that my Firefox even has some Protection Dashboard thing (about:protections). Not that I've ever used or noticed it before.
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.
I encourage every web developer to try running NoScript for a week. You will find it enlightening.
For frequently visited sites you can save which bits you want to allow so its not as onerous as you'd think.
Blocks Google Analytics and Facebook's poison by default.
...or let's just P2P our Emacsens... the last non divisive browser... :-P
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.
And if it's that important that EVERYBODY deploys JS to render client side to avoid the refreshes, why isn't this handled at the browser level in the first place (i.e. declare "ExtendDisplayTime"-something on your document and the browser should replace the screen content only AFTER the new page is completely painted).
But at the core of it, the web is a document-display system, and back-hammering and shoe-horning apps that masquerade as documents will always be painful.
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.
I'm tempted to creat a new GeoCities and see how that goes for non-technical folks
[0] meaning in the average folk psychology, of course a simpler cleaner web has value, just not to them AFAIB
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.
That misses the fact that people don't want any of that; people just want to continue using the current infrastructure without functionalities that rely on a limited subset of features made available by the current infrastructure.
And that doesn't justify the effort of reinventing the wheel.
I imagine the exclusivity of something like this is part of the appeal. They don't want to be part of the current infrastructure, they don't want to interact with it, or anyone on it.
They did. That's the Gemini protocol. I recommend reading the spec to properly understand the constraints they were trying to meet.
> 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.
Gemini protocol could have been a subset of HTTP and the document format could have been a subset of HTML. For instance, if you decide to not implement cookies, javascript etc but if you retain the ability to have formatting for texts, tables, images etc it would have been sufficient.
And even in the case of images, the protocol could have mandated that images cannot be accessed cross-site. The same restrictions could have been placed on other aspects such as the style sheets.
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.
Doesn't work over time. You link somewhere, the other site owner a month later decides they want to use Google Analytics, now you're linking your readers back to the web they're trying to avoid.
> And the biggest challenge with Gemini is creating a great search engine.
Not really, it's discovery in general, which can be solved in many ways that don't involve search engines; Wikipedia's references are often a good discovery tool, for example. I use aggregators to find Gemini content and follow discussions which are happening across the space.
What if instead of a direct link, there was an intermediary that verified that the source and target of the link conformed to spec? If either side didn't conform, the link would just not work. Ideally the intermediary would be built in to the source's web server for privacy reasons. If the target site decided to quit and break spec, people could still access the site from links posted outside of the network.
The entire purpose here is to build a community of people who care about this sort of thing, who write content for that community, where taking your content away from that community is not an easy decision of adding a <script> or <style> tag.
Maybe there's another way?
For example, Gemini could only link through a centralized link management server, and that link server will verify links to be "clean" , and if a link isn't clean it will become dead ?
Of course, that depends whether said link gets most of his traffic from within Gemini or outside.
Hmm...
Have you ever spent any time in small communities? It's lovely to just... not have to care about gaining followers or making arbitrary counters go up or whatever it is people do, and just talk/create for the sake of it. There's no "brand" to care about.
But will that work, and compete with the web for knowledge sharing communities? I'm not sure.
But many users will expect search. And it's really hard to change people's minds.
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?
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.