2 ms·
Okay, but how many implementations do you need for a protocol that is proudly useless and actively targeted at a narrow community? At first glance it seems like
by danShumway 5y ago
Okay, but how many implementations do you need for a protocol that is proudly useless and actively targeted at a narrow community? At first glance it seems like there's a little bit of circular reasoning here.
Gemini's selling point is that it's a narrow spec that's basically good for one thing: displaying largely unstructured text. It's not good for PDFs or layout, it's not good for media-heavy documents, it's not good for apps. You probably wouldn't write something like a book in Gemini. It knows exactly what it's doing, what kind of community it wants, and it focuses only on that use-case -- which is why its community likes it.
But how many different implementations do you need to build for this kind of narrow project? Are we really expecting that 50 different hobbyists are going to build custom Gemini parsers? Why? I'm not sure I understand what reason there would be for that kind of implementation diversity with a spec that is deliberately designed to decrease application diversity.
On the web, we have a lot of reasons why we are scared of having only one browser rendering engine. But most of those reasons don't seem to apply to Gemini, because it has different goals from the web. So say there was one zero-dependency C/WASM binary for parsing that was compiled for every platform and could be imported or transpiled into other languages for use in your custom browser/app. What do you feel would be missing from Gemini in that world?
- minitech 5y agoWhen I say that not being complicated to implement is an advantage, I mean I can have much more confidence that whatever implementation I’m using is bug-free and secure (e.g. by auditing the entire thing and its dependencies, something not even remotely feasible with a web browser), not that it should be constantly reimplemented. Contributing to a Gemini client or even just building it is a lot easier than doing the same for a web browser component. Plus, being able to implement something from the ground up in not much time means it’s possible to explore foundational advances, like building the entire client/server in a memory-safe language.
- danShumway 5y agoGreat answer, I buy all of those reasons as strong justifications to prioritize simplicity. I think it seems a little bit extreme in some ways, because when we talk about Gemini's implementation being simple, the FAQ isn't just talking about structure/readability, it's saying 100-200 lines for a basic client. To me that crosses from 'should be auditable' into something else entirely -- I'm not sure why having a 1000 line client would make this significantly harder to audit, or build, or re-implement in Rust. I'm not sure Rust is that complicated of a language. But :shrug:, I guess if you shoot for an extreme metric, then you know you'll end up with something that meets all of your other goals as well, so those requirements do make some sense to me when phrased as part an overall architectural stability/reliability goal.
- minitech 5y agoYeah, I would have liked to see different trade-offs made too (especially giving the same treatment to TLS), but I’m satisfied that it’s at least a good direction to start exploring and putting some level of support behind.