7 ms·

A client for HTML and CSS is much more complicated to implement than a client for Gemini and its rich text format. But you can serve HTML pages over Gemini eith

A client for HTML and CSS is much more complicated to implement than a client for Gemini and its rich text format. But you can serve HTML pages over Gemini either way.

benrbray 5y ago
Why a whole new protocol? Why not start a collective of like-minded users who design plain HTML/CSS websites that work for users who have JS disabled by default? As far as I can tell that would be a strict improvement over Gemini.
- josephg 5y ago
  Probably. But you can see what would happen - without a new protocol or new document structure, traditional web browsers would work with the system. And because of that it wouldn't have an identity outside "the web, but worse". Gemini's different protocol isn't important for technical reasons. Its important for social reasons - to make it effortful to move content to gemini, and effortful for users to start using it. The result is that all the content and users on gemini are people who have done work to opted in to it. And the space populated by small community like that will necessarily end up different from the culture on the web. (If they were happy with the web, they would have stayed there.)
  - krapp 5y ago
    >And the space populated by small community like that will necessarily end up different from the culture on the web. (If they were happy with the web, they would have stayed there.) But they have stayed there. Gemini users still use the modern web all the time, mostly to remind everyone that they exist and are rejecting the modern web so hard you guys.
    - selfhoster11 5y ago
      Well duh. If you have a race bike, of course you'll also keep a metro pass or a car. You still need to get places. But the race bike is your instrument of leisure and a place to unwind. This role cannot be fulfilled by a car or a metro pass for some people, because it just doesn't have the same relaxed atmosphere.
      - kstrauser 5y ago
        That’s an excellent analogy. I make my living building web stuff. When I get home, I want to play with other things as a hobby. I also have a ham radio license, but that doesn’t mean I only want to use that instead of the gigabit Internet drop at my house.
        josephg 5y ago
        Yep absolutely. Another way to think about it is that using the web doesn't mean we delete all our local native apps. As users we don't gather into camps who only use one type of software or another. Modern computing environments are mixed spaces full of all sorts of different kinds of software. It very rarely makes sense to be exclusionary or exclusive about any particular type. Gemini is no different. There's overlap with the web's use cases, but its its own thing. As a user, why not both?
        krapp 5y ago
        >Gemini is no different. There's overlap with the web's use cases, but its its own thing. As a user, why not both? What does Gemini have to offer to web users that the web itself doesn't? It's entirely possible to write small, simple HTML documents without javascript on the web. Indeed, one could replace Gemini entirely with a Geocities-like service that enforced the same rules, including only allowing linking within the platform. Alongside the web, Gemini is just a worse version of the web, it isn't different enough to be its own thing, nor does it offer anything unique. Gemini only makes sense as a means of forging a separate identity from and exclusionary of the web, as you yourself said in the original comment I replied to[0]: (If they were happy with the web, they would have stayed there.) [0]https://news.ycombinator.com/item?id=27491175 https://news.ycombinator.com/item?id=27491175
- foobar33333 5y ago
  Because its easier to create an in group of sites which follow the same standard. Gemini sites will link to other gemini links only which you know will be minimal before clicking.
  - coldtea 5y ago
    That's trivial to do in participating "minimal web code" group too. You could e.g. color the links to other participating sites to highlight them (and still have the option to link to a conventional bloated website).
- hollerith 5y ago
  One advantage of Gemini is that it is easier to attract new users to the cause: even if a particular user is being helped by the collective you describe, he or she probably won't realize (because most users are oblivious to many/most of the effects of UI and architectural design decisions). He or she will ascribe the good experience provided by the collective to the web. The web is like a badly architected government such that most citizens are unaware of the badness. The collective you describe is like a group who use their own awareness of the badness to improve the country, but that does raise awareness of the government's badness whereas starting fresh by founding a new country does. Actually, the analogy I just gave is a little too harsh on the web. A more charitable description is that a subset of the web's users is poorly served by the architecture of the web, but most of that subset is unaware of that fact (what with not being experts on the effects of subtle technical decisions on something as vast, open and complex as the internet). I am not defending Gemini in particular; I use it but have yet to form an opinion of it; I am defending the strategy of founding a new internet service to compete (for the time and attention of users) with the web.
  - coldtea 5y ago
    >One advantage of Gemini is that it is easier to attract new users to the cause: even if a particular user is being helped by the collective you describe, he or she probably won't realize (because most users are oblivious to many/most of the effects of UI and architectural design decisions). He or she will ascribe the good experience provided by the collective to the web. I don't buy this argument. Even if "he/she ascribes the good experience (...) to the web": (a) the subset of users that could fell into one of the "participating sites" would be much larger than the subset of users that would install something like Gemini. The subset is open with no barrier at all to every web user. They just need to visit a page. The second subset requires them to have heard about Gemini, to care enough about it, and to actively download a client. (b) For this reason, even the subset of (a) that could tell "Ahh, this site is fast and nice because it's simple web code" would be much larger than the subset that would install something like Gemini. (c) If the subset that recognizes the benefits from the simple web design designs to join the movement, they just need to code simple html and deliver to everybody (an easy sell, no new tools needed). For the subset that discovered and likes Gemini, they'd need to find a host and install a Gemini server (much fewer options, no turnkey-host that supports it, unknown code quantity/quality), and then their potential audience is severely limited to Gemini client users (a much harder sell).
- yoz-y 5y ago
  You could also build a community around a static site generator (and maybe a hosted version), where everybody would pledge to not customise anything except a set of offered css variables. Then federate those blogs somehow. Though I somehow doubt that such a community would stay “pure” for long.
- rakoo 5y ago
  The faq answers your question: => https://gemini.circumlunar.space/docs/faq.gmi https://gemini.circumlunar.space/docs/faq.gmi > 2.5 Why not just use a subset of HTTP and HTML? > Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites can track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they have to. Why not just build non-evil websites using the existing technology? > Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done. > The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render. > Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they can't. You can do all this with a client you wrote yourself, so you know you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
- alexwennerberg 5y ago
  People have said this for years, and yet, no such formal community has been created, while Gemini only grows in popularity. I think such a community would be great, but it's hard to maintain a strict separation with the "rest of the web" in the way that Gemini has.
squiggleblaz 5y ago
That's true. Perhaps the solution is to explicitly agree that the Gemini format will expand to a certain goal complexity - so that there's always several implementations, and it's possible to ramp up to something with more flexibility. > But you can serve HTML pages over Gemini either way. The important question is what people can read over Gemini, I guess. Do Gemini clients effectively render that? I imagine it would be difficult to take Webkit and make it work without supporting JS.
- selfhoster11 5y ago
  Basic HTML doesn't need WebKit. If what you want is basic HTML 4 tags set with a couple of HTML 5 tags, this is not a big task.
chacha2 5y ago
What good is competing implementations if they all have to keep to the same spec?
- smichel17 5y ago
  Read the spec, it's not long. It leaves plenty of room for variation.
- turminal 5y ago
  Not keeping to the same spec is one of the reasons why modern web is a dumpster fire.
- coldtea 5y ago
  Different quality, support, tradeoffs, maturity levels, focuses, and add-ons? Might as well ask "what good is competing webservers".
- selfhoster11 5y ago
  The same reason that it's good to have different clients for other protocols. Some clients lean heavily to one side on the CLI vs GUI vs VR debate, some choose to have convenience over technical complexity and so make choices that other Gemini users would disagree with, some allow a degree of automation, some are a multi-protocol client that has Gemini as just one supported option.
swiley 5y ago
I wrote an HTML parser while waiting for Firefox to build once, it didn't take a ton to turn it into a minimal browser. Web browsers are hard when they have to be an application runtime instead of a document viewer, HTML grammar is easy.
- pfalcon 5y ago
  HTML parser is trivial. There's a huge difference between HTML parser and HTML rendering engine. "A minimal browser" which you allegedly wrote isn't something you or anyone else does, or would, use.
  - swiley 5y ago
    I didn't "allegedly" write it, it's on my github. Yeah it doesn't do box model layout but (and this was my point) that's not as big a deal without js because the pages are still perfectly usable.
    - arp242 5y ago
      I wrote a toy browser in a weekend too; I just used an existing HTML and CSS parser. The hard part isn't the HTML parsing, that's pretty easy and mostly just basic lexing/parsing stuff. It's applying the CSS to the HTML and rendering a document that vaguely looks right. There are loads of different interactions, and even Firefox and Chrome actually get it wrong in many edge cases (and also frequently in not-so-edge cases). I wrote a list some time ago of all the interactions "position: sticky" breaks in Firefox, and there's loads of them (I can't find that list now though, it was a HN comment from last year). It was pretty basic stuff like z-index, tables, flexbox, etc. Nothing too obscure. If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
    - leephillips 5y ago
      Point taken, but you probably know that some pages will not be usable in a browser that does not implement CSS. As in, completely unreadable.
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 ago
  When 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 ago
    Great 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.

A client for HTML and CSS is much more complicated to implement than a client for Gemini and its rich text format. But you can serve HTML pages over Gemini either way.

benrbray 5y ago

Why a whole new protocol? Why not start a collective of like-minded users who design plain HTML/CSS websites that work for users who have JS disabled by default? As far as I can tell that would be a strict improvement over Gemini.

josephg 5y ago
Probably. But you can see what would happen - without a new protocol or new document structure, traditional web browsers would work with the system. And because of that it wouldn't have an identity outside "the web, but worse". Gemini's different protocol isn't important for technical reasons. Its important for social reasons - to make it effortful to move content to gemini, and effortful for users to start using it. The result is that all the content and users on gemini are people who have done work to opted in to it. And the space populated by small community like that will necessarily end up different from the culture on the web. (If they were happy with the web, they would have stayed there.)
- krapp 5y ago
  >And the space populated by small community like that will necessarily end up different from the culture on the web. (If they were happy with the web, they would have stayed there.) But they have stayed there. Gemini users still use the modern web all the time, mostly to remind everyone that they exist and are rejecting the modern web so hard you guys.
  - selfhoster11 5y ago
    Well duh. If you have a race bike, of course you'll also keep a metro pass or a car. You still need to get places. But the race bike is your instrument of leisure and a place to unwind. This role cannot be fulfilled by a car or a metro pass for some people, because it just doesn't have the same relaxed atmosphere.
    - kstrauser 5y ago
      That’s an excellent analogy. I make my living building web stuff. When I get home, I want to play with other things as a hobby. I also have a ham radio license, but that doesn’t mean I only want to use that instead of the gigabit Internet drop at my house.
      - josephg 5y ago
        Yep absolutely. Another way to think about it is that using the web doesn't mean we delete all our local native apps. As users we don't gather into camps who only use one type of software or another. Modern computing environments are mixed spaces full of all sorts of different kinds of software. It very rarely makes sense to be exclusionary or exclusive about any particular type. Gemini is no different. There's overlap with the web's use cases, but its its own thing. As a user, why not both?
        krapp 5y ago
        >Gemini is no different. There's overlap with the web's use cases, but its its own thing. As a user, why not both? What does Gemini have to offer to web users that the web itself doesn't? It's entirely possible to write small, simple HTML documents without javascript on the web. Indeed, one could replace Gemini entirely with a Geocities-like service that enforced the same rules, including only allowing linking within the platform. Alongside the web, Gemini is just a worse version of the web, it isn't different enough to be its own thing, nor does it offer anything unique. Gemini only makes sense as a means of forging a separate identity from and exclusionary of the web, as you yourself said in the original comment I replied to[0]: (If they were happy with the web, they would have stayed there.) [0]https://news.ycombinator.com/item?id=27491175 https://news.ycombinator.com/item?id=27491175
foobar33333 5y ago
Because its easier to create an in group of sites which follow the same standard. Gemini sites will link to other gemini links only which you know will be minimal before clicking.
- coldtea 5y ago
  That's trivial to do in participating "minimal web code" group too. You could e.g. color the links to other participating sites to highlight them (and still have the option to link to a conventional bloated website).
hollerith 5y ago
One advantage of Gemini is that it is easier to attract new users to the cause: even if a particular user is being helped by the collective you describe, he or she probably won't realize (because most users are oblivious to many/most of the effects of UI and architectural design decisions). He or she will ascribe the good experience provided by the collective to the web. The web is like a badly architected government such that most citizens are unaware of the badness. The collective you describe is like a group who use their own awareness of the badness to improve the country, but that does raise awareness of the government's badness whereas starting fresh by founding a new country does. Actually, the analogy I just gave is a little too harsh on the web. A more charitable description is that a subset of the web's users is poorly served by the architecture of the web, but most of that subset is unaware of that fact (what with not being experts on the effects of subtle technical decisions on something as vast, open and complex as the internet). I am not defending Gemini in particular; I use it but have yet to form an opinion of it; I am defending the strategy of founding a new internet service to compete (for the time and attention of users) with the web.
- coldtea 5y ago
  >One advantage of Gemini is that it is easier to attract new users to the cause: even if a particular user is being helped by the collective you describe, he or she probably won't realize (because most users are oblivious to many/most of the effects of UI and architectural design decisions). He or she will ascribe the good experience provided by the collective to the web. I don't buy this argument. Even if "he/she ascribes the good experience (...) to the web": (a) the subset of users that could fell into one of the "participating sites" would be much larger than the subset of users that would install something like Gemini. The subset is open with no barrier at all to every web user. They just need to visit a page. The second subset requires them to have heard about Gemini, to care enough about it, and to actively download a client. (b) For this reason, even the subset of (a) that could tell "Ahh, this site is fast and nice because it's simple web code" would be much larger than the subset that would install something like Gemini. (c) If the subset that recognizes the benefits from the simple web design designs to join the movement, they just need to code simple html and deliver to everybody (an easy sell, no new tools needed). For the subset that discovered and likes Gemini, they'd need to find a host and install a Gemini server (much fewer options, no turnkey-host that supports it, unknown code quantity/quality), and then their potential audience is severely limited to Gemini client users (a much harder sell).
yoz-y 5y ago
You could also build a community around a static site generator (and maybe a hosted version), where everybody would pledge to not customise anything except a set of offered css variables. Then federate those blogs somehow. Though I somehow doubt that such a community would stay “pure” for long.
rakoo 5y ago
The faq answers your question: => https://gemini.circumlunar.space/docs/faq.gmi https://gemini.circumlunar.space/docs/faq.gmi > 2.5 Why not just use a subset of HTTP and HTML? > Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites can track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they have to. Why not just build non-evil websites using the existing technology? > Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done. > The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render. > Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they can't. You can do all this with a client you wrote yourself, so you know you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
alexwennerberg 5y ago
People have said this for years, and yet, no such formal community has been created, while Gemini only grows in popularity. I think such a community would be great, but it's hard to maintain a strict separation with the "rest of the web" in the way that Gemini has.

squiggleblaz 5y ago

That's true. Perhaps the solution is to explicitly agree that the Gemini format will expand to a certain goal complexity - so that there's always several implementations, and it's possible to ramp up to something with more flexibility. > But you can serve HTML pages over Gemini either way. The important question is what people can read over Gemini, I guess. Do Gemini clients effectively render that? I imagine it would be difficult to take Webkit and make it work without supporting JS.

selfhoster11 5y ago
Basic HTML doesn't need WebKit. If what you want is basic HTML 4 tags set with a couple of HTML 5 tags, this is not a big task.

chacha2 5y ago

What good is competing implementations if they all have to keep to the same spec?

smichel17 5y ago
Read the spec, it's not long. It leaves plenty of room for variation.
turminal 5y ago
Not keeping to the same spec is one of the reasons why modern web is a dumpster fire.
coldtea 5y ago
Different quality, support, tradeoffs, maturity levels, focuses, and add-ons? Might as well ask "what good is competing webservers".
selfhoster11 5y ago
The same reason that it's good to have different clients for other protocols. Some clients lean heavily to one side on the CLI vs GUI vs VR debate, some choose to have convenience over technical complexity and so make choices that other Gemini users would disagree with, some allow a degree of automation, some are a multi-protocol client that has Gemini as just one supported option.

swiley 5y ago

I wrote an HTML parser while waiting for Firefox to build once, it didn't take a ton to turn it into a minimal browser. Web browsers are hard when they have to be an application runtime instead of a document viewer, HTML grammar is easy.

pfalcon 5y ago
HTML parser is trivial. There's a huge difference between HTML parser and HTML rendering engine. "A minimal browser" which you allegedly wrote isn't something you or anyone else does, or would, use.
- swiley 5y ago
  I didn't "allegedly" write it, it's on my github. Yeah it doesn't do box model layout but (and this was my point) that's not as big a deal without js because the pages are still perfectly usable.
  - arp242 5y ago
    I wrote a toy browser in a weekend too; I just used an existing HTML and CSS parser. The hard part isn't the HTML parsing, that's pretty easy and mostly just basic lexing/parsing stuff. It's applying the CSS to the HTML and rendering a document that vaguely looks right. There are loads of different interactions, and even Firefox and Chrome actually get it wrong in many edge cases (and also frequently in not-so-edge cases). I wrote a list some time ago of all the interactions "position: sticky" breaks in Firefox, and there's loads of them (I can't find that list now though, it was a HN comment from last year). It was pretty basic stuff like z-index, tables, flexbox, etc. Nothing too obscure. If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
  - leephillips 5y ago
    Point taken, but you probably know that some pages will not be usable in a browser that does not implement CSS. As in, completely unreadable.

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 ago
When 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 ago
  Great 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.