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).)

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.