For all the gauzy what-could-have-been speculations about Gopher, it really was more like a hierarchical wiki. WWW's freestyle document model quickly expanded to an application platform that could support all manner and style of services. Fees or not, Gopher didn't have a chance.
The Gopher standard mixes a document format with a networking protocol. The HTTP standards don't say a damn thing about HTML, but the Gopher standard defines a standard for sending directory information to a client, right down to the fixed list of file types that can occur in a directory. (MIME Type? What's that?) This is the hypertext part of Gopher, as only those directories can link to other places, so constraining that gives you a nice, simple way to have pretty plain-text sites with an enforce separation of lists of links, one one hand, and images and documents, on the other, which HTTP has no equivalent for.
(Not just file types, in fact, in that they have a special type for tn3270 telnet sessions. Yep, those IBM mainframes with block-mode terminals were quite important back then, but it's a bit out of place now. They also have a type for GIF and a generic 'client-figures-it-out' image type. How forward-thinking.)
HTTP stands for Hypertext transfer protocol. The whole thing was predicated on sending HTML documents and couldn't originally send anything else.
> (MIME Type? What's that?)
MIME is a hack to add attachments to email that was later also hacked into HTTP so you could send add "attachments" to a protocol designed only to transfer hypertext, it's a kludge added in version 1.1.
Gopher's main difference with the web was that its linking was directory-based with directory tree documents rather than embedded hyperlinks. This was inferior, strictly speaking since you can easily make a directory HTML document on the web, but you could also cross-link.
I'm sure that would have been changed though, along with additional file-types or whatever had Gopher succeeded. The web's success over Gopher was never down to technical details.
OK, HTTP/0.9 was apparently like that. By HTTP/1.0 (1996) they'd learned better, and that was the growth phase:
https://www.w3.org/Protocols/HTTP/1.0/spec.html
> MIME is a hack to add attachments to email that was later also hacked into HTTP so you could send add "attachments" to a protocol designed only to transfer hypertext, it's a kludge added in version 1.1.
Like how Gopher got kludged to add other item types? All useful protocols evolve, and Gopher is no exception.
https://github.com/gopher-protocol/gopher-plus/blob/main/gop...
> Gopher's main difference with the web was that its linking was directory-based with directory tree documents rather than embedded hyperlinks. This was inferior, strictly speaking since you can easily make a directory HTML document on the web, but you could also cross-link.
Yes, that's true.
> I'm sure that would have been changed though, along with additional file-types or whatever had Gopher succeeded. The web's success over Gopher was never down to technical details.
Also true, and that New Gopher is now called Gemini.
It also defines a hypertext document format (Gemtext) but it allows HTML-style free linking and (depending on client) inline images, although that's not really what the Gemini users want. Again, this is more social than technical, and more self-consciously social because it's a deliberate reaction to existing paradigms: The Web as it is now (too invasive, too busy) and Gopher as it is now (a moribund retrocomputing exercise that can't realistically incorporate new technologies or serve new goals).
Speaking of clients:
https://gmi.skyjake.fi/lagrange/
https://thelambdalab.xyz/elpher/
Both do Gemini and Gopher.
A design based on directories of static files makes it a lot easier to mirror the entire site, or a subtree.