This essay is an admirable display of restraint. I would have been far crueler.
In my experience, protocols that claim to be simple(r) as a selling point are either actually really complex and using “simple” as a form of sarcasm (SOAP), or achieve simplicity by ignoring or handwaving away inconvenient details (RSS, and sounds like Gemini too.)
After years thinking and reading RFCs and various other documents, today, I finally understood. “Simple” refers to “Network” not to “Management Protocol”! So it is a Management Protocol for Simple Networks not a Simple Protocol for Management of Networks
Let’s not forget ASN.1, DCE, and CORBA. Okay, let’s forget those. In comparison SOAP did seem easier because most of the time you could half-ass it by templating a blob of XML body, fire it off, and hopefully get a response.
achieve simplicity by ignoring or handwaving away inconvenient details
Exactly, and the next-order effect is often pushing the complexity (which never went away) towards other parts of the whole-system stack. It’s not “simple”, it’s “the complexity is someone else’s problem”.
Pretty sure that’s because RSS2 is not supposed to contain HTML.
But RSS2 is just really garbage even if people bothered following the spec. Atom should have just called itself RSS3 to keep the brand awareness working.
Well, Winer’s way of arguing was never really via the legal system, it was by being a whiny git in long-winded blog posts. Besides, RSS versions <1.0 were the RDF-flavored ones (hence RSS == RDF Site Summary), and no-one wanted that anymore.
<=1.0 and people kept using 1.0 long after 2.0 existed because some people still wanted that :) Thought those people were mostly made happy by Atom and then 1.0 finally died.
O god, don’t get me started. RSS 2 lacked proper versioning, so Dave Fscking Winer would make edits to the spec and change things and it would still be “2.0”. The spec was handwavey and missing a lot of details, so inconsistencies abounded. Dates were underspecified; to write a real-world-useable RSS parser (circa 2005) you had to basically try a dozen different date format strings and try them all until one worked. IIRC there was also ambiguity about the content of articles, like whether it was to be interpreted as plain text or escaped HTML or literal XHTML. Let alone what text encoding to use.
I could be misremembering details; it’s been nearly 20 years. Meanwhile all discussions about the format, and the development of the actually-sane replacement Atom, were perpetual mud-splattered cat fights due to Winer being such a colossal asshat and several of his opponents being little better. (I’d had my fill of Winer back in the early 90s so I steered clear.)
This is probably quite a useful write-up for anyone looking to improve the Gemini spec.
There are a few criticisms however that I don’t think are valid given the goals of the project:
The protocol was designed to be hard to extend and develop on; not versioning the protocol makes sense in this context.
The protocol was designed to make user tracking difficult and values simplicity. Closing connections after every response makes sense in this context. A resource pulling in more resources (and therefore benefiting from connection reuse) feels like it would be implicitly against the goals of the project.
I don’t know why anyone that was interested in Gemini would be using to throw around HTML, so the criticisms of it being a poor transport for the web feel pointless. That’s kinda the point.
Precisely! I think the criticisms in the article are valid… If your goal is to have a Web replacement! Gemini’s trying to be a document only platform, not an OS/application platform. Not saying that the Web’s evolution into an OS/application platform is bad, but Gemini is actively trying to avoid that route.
I don’t see how things like “have more precise descriptions”, “be more efficient” and “fix your security” are about being a web replacement. I read this criticism more as coming from an expert on protocols and their client-side implementations.
I find it especially ironic that Gemini enforces using TLS, but then has such weak security guidelines as to make it essentially useless. That’s like all those folks running websites with self-signed TLS certs. The only advantage that gives you over an unsecured connection is when you have a passive attacker who can only eavesdrop but not actively put stuff on the wire. This article goes into detail as to why, with solid reasoning. But this kind of stuff is like arguing against a brick wall.
Note that even his gripe about not being able to share multiple resources over one connection isn’t web-specific: a Gemini crawler or archiver would also massively benefit from doing this.
a Gemini crawler or archiver would also massively benefit from doing this
A significant bunch of Gemini fans are perfectly fine with gemspace being harder to crawl and archive.
Anyway, Daniel’s critiques are on point, but it won’t sway most of the community. The shortcomings of the spec have been endlessly hashed out. The people losing out are the ones who would prefer Gemini to become a bit more mainstream, with support in curl and other tools (like Lynx). The solution, of course, is to code your own tool, which is what Gemini is explicitly designed to be easy to do.
Seems like an unambiguous protocol specification would be a critically important part of making it easy to code your own tools, assuming you want them to talk to other peoples’ tools.
There were plans for that, according to the FAQ (section 1.5):
Going forward, the main focus of the project now is on growing the community around the protocol, as well as working on translating the existing specification into a more precise and formal version which might be considered for submission to internet standards bodies such as IETF and IANA.
However, the main driver behind the protocol work (solderpunk) seems to have stepped back, and the mailing list used for discussions has been defunct for more than a year IIRC.
That’s how I see Gemini too. The original post that inspired it all was titled “Pondering what’s inbetween gopher and the web.” It was a Gopher post to a community of Gopher users.
So I think of Gemini as Gopher-plus rather than a Web-minus. If the intent was to be anything more than Gopher-plus, the spec would be open.
This essay is an admirable display of restraint. I would have been far crueler.
In my experience, protocols that claim to be simple(r) as a selling point are either actually really complex and using “simple” as a form of sarcasm (SOAP), or achieve simplicity by ignoring or handwaving away inconvenient details (RSS, and sounds like Gemini too.)
The “S” in “SNMP” is a vile lie.
via
It’s simple compared to CIMOM, in the same way LDAP is lightweight compared to DAP.
Let’s not forget ASN.1, DCE, and CORBA. Okay, let’s forget those. In comparison SOAP did seem easier because most of the time you could half-ass it by templating a blob of XML body, fire it off, and hopefully get a response.
Exactly, and the next-order effect is often pushing the complexity (which never went away) towards other parts of the whole-system stack. It’s not “simple”, it’s “the complexity is someone else’s problem”.
what’s inconvenient about RSS?
Some of my personal grievances with RSS 2.0 are:
Obviously, neither are too important – RSS works just fine in practice. Still, Atom is way better.
RSS never specified how HTML content should be escaped, for example.
The Atom protocol resolved that however.
Pretty sure that’s because RSS2 is not supposed to contain HTML.
But RSS2 is just really garbage even if people bothered following the spec. Atom should have just called itself RSS3 to keep the brand awareness working.
[Comment removed by author]
The RSS trademark (such as it was) was claimed by Dave Winer, who opposed Atom.
But I don’t think every enforced against the RSS1 people whom he also opposed.
Well, Winer’s way of arguing was never really via the legal system, it was by being a whiny git in long-winded blog posts. Besides, RSS versions <1.0 were the RDF-flavored ones (hence RSS == RDF Site Summary), and no-one wanted that anymore.
<=1.0and people kept using 1.0 long after 2.0 existed because some people still wanted that :) Thought those people were mostly made happy by Atom and then 1.0 finally died.Incorrect, RSS2 was 2002, Atom was 2005.
Teaches me to not read wikipedia correctly.
O god, don’t get me started. RSS 2 lacked proper versioning, so Dave Fscking Winer would make edits to the spec and change things and it would still be “2.0”. The spec was handwavey and missing a lot of details, so inconsistencies abounded. Dates were underspecified; to write a real-world-useable RSS parser (circa 2005) you had to basically try a dozen different date format strings and try them all until one worked. IIRC there was also ambiguity about the content of articles, like whether it was to be interpreted as plain text or escaped HTML or literal XHTML. Let alone what text encoding to use.
I could be misremembering details; it’s been nearly 20 years. Meanwhile all discussions about the format, and the development of the actually-sane replacement Atom, were perpetual mud-splattered cat fights due to Winer being such a colossal asshat and several of his opponents being little better. (I’d had my fill of Winer back in the early 90s so I steered clear.)
Which version of RSS? :)
I see what you did there.
Suggest
networking, since this is about a networking protocol.Suggest removing
rant, since it really isn’t a rant (not particularly vitriolic) but instead just a long list of issues and thoughts.This is probably quite a useful write-up for anyone looking to improve the Gemini spec.
There are a few criticisms however that I don’t think are valid given the goals of the project:
Precisely! I think the criticisms in the article are valid… If your goal is to have a Web replacement! Gemini’s trying to be a document only platform, not an OS/application platform. Not saying that the Web’s evolution into an OS/application platform is bad, but Gemini is actively trying to avoid that route.
I don’t see how things like “have more precise descriptions”, “be more efficient” and “fix your security” are about being a web replacement. I read this criticism more as coming from an expert on protocols and their client-side implementations.
I find it especially ironic that Gemini enforces using TLS, but then has such weak security guidelines as to make it essentially useless. That’s like all those folks running websites with self-signed TLS certs. The only advantage that gives you over an unsecured connection is when you have a passive attacker who can only eavesdrop but not actively put stuff on the wire. This article goes into detail as to why, with solid reasoning. But this kind of stuff is like arguing against a brick wall.
Note that even his gripe about not being able to share multiple resources over one connection isn’t web-specific: a Gemini crawler or archiver would also massively benefit from doing this.
A significant bunch of Gemini fans are perfectly fine with gemspace being harder to crawl and archive.
Anyway, Daniel’s critiques are on point, but it won’t sway most of the community. The shortcomings of the spec have been endlessly hashed out. The people losing out are the ones who would prefer Gemini to become a bit more mainstream, with support in curl and other tools (like Lynx). The solution, of course, is to code your own tool, which is what Gemini is explicitly designed to be easy to do.
Seems like an unambiguous protocol specification would be a critically important part of making it easy to code your own tools, assuming you want them to talk to other peoples’ tools.
There were plans for that, according to the FAQ (section 1.5):
However, the main driver behind the protocol work (solderpunk) seems to have stepped back, and the mailing list used for discussions has been defunct for more than a year IIRC.
That’s how I see Gemini too. The original post that inspired it all was titled “Pondering what’s inbetween gopher and the web.” It was a Gopher post to a community of Gopher users.
So I think of Gemini as Gopher-plus rather than a Web-minus. If the intent was to be anything more than Gopher-plus, the spec would be open.