The reason I didn't is to avoid a discussion of how I personally would design tools for an alternate web. I think gemini is a step in the right direction, but not enough to supplant the web for a large enough minority of users. Not that it takes many users - the web was vibrant in 1995 with 100x fewer people on it than today.
I don't know that the specific qualities I personally would want for a web replacement are the right ones for everybody, but I would add to the philosophy of gemini some sort of control - not necessarily centralized - to curb commercial activity and abuse. To attract users, it would also need more cultural cache than Gemini. There wouldn't be much content on it at first - unless its design found a loophole to facilitate piracy - so its early adopters would need to feel like they were part of some exclusive community.
Nevertheless, it can be of interest, in case someone does have the ideas. (I have seen other stuff in Hacker News and elsewhere, too.)
What are the specific qualities you personally would want for a web replacement? (You are probably right that they are not the right ones for everybody, but still it might be worth to mention.)
About control, to curb commercial activity and abuse, how would you expect that it should be done? (For most things the existing security is good enough but for commercial business you will want a better security for the purpose of the identification. But, maybe you have other ideas.)
I also have my own ideas for what I would want for a web replacement too (but, like Gemini, it does not have to destroy or be mutually exclusive with WWW or with anything else; see Gemini protocol FAQ 1.13), which I had made available (I wrote Scorpion protocol/file-format specification document).
One thing is that, it shouldn't be between Gopher (or Gemini) and WWW; instead it should be between Gemini and "WWW as it should be if it was designed better".
(Also, Gemini protocol can be made by making a TLS connection to port 1965 and then send the URL and a carriage return and line feed. This is a simplified explanation, but it is good enough to find the specification document in case you want to access it directly rather than HTTPS or something else.)
(Also note: I think that non-extensibility of Gemini protocol/file-format does not really work so well as they had expected. Some files do use extensions not mentioned in there, such as SGR codes. There are also many other ways to put extensions, such as into the X.509 certificate (and since TLS is mandatory, such a thing will always be available), as hidden Unicode characters (since they insist on using Unicode), trailing spaces (like ProleText does), and other ways.)
I'd be happy with something like markdown instead of HTML. If the format is simple enough, the user could choose a global stylesheet and have it actually make sense for all the sites they visit.
For most sites, Javascript provides negative value. So... build a browser that has a couple hooks for very common, useful dynamic functions, and include no scripting language.
Images are kind of a conundrum. They're pleasant, but open the door to obnoxious garbage like ads, and workarounds for missing features. One compromise might be to allow only thumbnail resolution images - maybe use ML to scale them back up, maybe just show them blocky.
Another problem with the modern web is the unimaginable amount of fraud and lies. There are a few initiatives out there to provide pseudonymous identity verification and also information authentication. A better web would include something like these so that an author can prove data about what they claim (eg: that they live in France, that they have a PhD in Biology, etc).
I believe some of the newer social networks (like Mastodon?) have worked on distributed moderation. That is an important piece also, because humans are very creative about abusing rules, and there needs to be a way to eject bad actors.
Those are some of the thoughts I've had, mainly about sites for articles and blog posts. One would need to change a few details to support other use-cases, such as commerce sites or social networking. On the current web, these essentially all work the same way. So a browser without much scripting could provide some basic template to support them.
I agree. (It also has some features that are counterproductive, or things that interfere with other possible useful features, etc. Some of the commands are potentially useful but CSS and JavaScripts can get in the way.)
(Another problem with the complexity of WWW is the mess it makes by having to add or change other stuff to work around it and then that does not work very well either and is also not very well designed either.)
> If the format is simple enough, the user could choose a global stylesheet and have it actually make sense for all the sites they visit.
I agree that the user can specify global stylesheet to make sense for anything, is suitable. Gemini and Scorpion file formats deliberately do not allow authors to specify styles, in order to ensure that the user can control it instead. (This also means
However, this can work even with HTML in some cases (although I don't know of any implementations of this), that only uses a subset of it. However, if a CSS is provided anyways it might not know how important it is, but one way is to detect only styles of standard HTML commands, and if those are the only styles that are present, then it should probably be safe to override it with the user's stylesheet without breaking it. (Even if it does not meet these criteria, the user could still override a specific site or a specific stylesheet with their own, and I often do so on my computer.)
> For most sites, Javascript provides negative value. So... build a browser that has a couple hooks for very common, useful dynamic functions, and include no scripting language.
I also agree with that, too. However, there are a few different kind of dynamic functions.
There is also the consideration of separation of "document web" and "application web", although the way that this separation is doing and how much separation, is another question, and one that I had considered and have some ideas about, too.
My idea in Scorpion protocol is the conversion file. This is always a separate file from the document file; it deliberately cannot be used inside of the document file. This can be used to display unrecognized file formats, and some other uses, but it is always by the control of the end user (who can also override it with their own), never automatically executes programs,
> Images are kind of a conundrum. They're pleasant, but open the door to obnoxious garbage like ads, and workarounds for missing features. One compromise might be to allow only thumbnail resolution images - maybe use ML to scale them back up, maybe just show them blocky.
Another problem is making the file size for loading bigger than it needs to be. I think that what you describe is not the solution anyways, though. Another way would be to make pictures to not be loaded automatically by the document, but you can link to them and select them if you want to view them.
> Another problem with the modern web is the unimaginable amount of fraud and lies.
This is a different issue than the protocol and document itself. However, if you can add metadata, then digital signatures, X.509 certificates, etc can be added in case you want to verify it. In some cases, it is better to just go there instead of using the computer to prove it, but that is not always appropriate. (It also does not have to be mandatory; you can still have free speech to write what you like to do. Nobody will be required to read it, but they can if they want to do.)
> One would need to change a few details to support other use-cases, such as commerce sites or social networking. On the current web, these essentially all work the same way. So a browser without much scripting could provide some basic template to support them.
For commerce, I had idea of a "computer payment file" (probably DER-based, and with asymmetric cryptography, and some other stuff), that is independent of the protocol and is also independent of the internet. Such a file can be prepared locally using suitable software and then sent to the business that you are making a purchase from.
For social networking, it can depend on some specifics, also.
(You can also see my other comment about the Scorpion conversion file. When it needs to execute a program, uxn is used (which is much simpler than JavaScript or WebAssembly), and it is always under the control of the end user; furthermore, it is specified for a specific use (unlike WWW; since in WWW, programs will run (or not run) without anyone knowing why) so that if you already have your own program for that use, you can use that one instead (which might be more efficient as well as other benefits).)
About control, to curb commercial activity and abuse, how would you expect that it should be done? (For most things the existing security is good enough but for commercial business you will want a better security for the purpose of the identification. But, maybe you have other ideas.)
I also have my own ideas for what I would want for a web replacement too (but, like Gemini, it does not have to destroy or be mutually exclusive with WWW or with anything else;
instead it should be between Gemini and "WWW as it should be if it was designed better".
(Also note: I think that non-extensibility of Gemini protocol/file-format does not really work so well as they had expected.
I am not sure that it is necessarily what is or should be the requirement, or that such a system is that helpful enough anyways.
If you are trying to do business, then you should need to verify that it is with the business that you are trying to communicate with and not a different one, so Let's Encrypt is not good enough since that only verifies the domain name. However, sometimes this is not necessary, anyways.
For revoking access, I agree that there can be other ways. For example, someone can provide revocation files and then some users might decide to trust those revocation files or not.
> I'm actually not so sure it's good to provide easy access from the normal web.
You might be right. (Scorpion file format uses TRON code rather than Unicode, which might have the side effect of making it difficult to access from the normal web, although that was not the reason for this decision. However, as you describe, this side effect may be beneficial, anyways.)
> Yes, Gemini is a little too dry.
Yes, and a few people had thought so. However, my comment is not only about what Gemini doesn't do, but also about things that WWW doesn't do, too.
> I've always found it interesting primarily because Gopher is nostalgic to me from my first few months on the internet way back in the age of the dinosaurs
Gopher is still in use, and Gemini FAQ also says it is not going to destroy Gopher either.