3 ms·

Gemini may unfortunately be the best hope in terms of what gets adoption but I feel like it swings way too far in the other direction. I see this a lot: your c

Gemini may unfortunately be the best hope in terms of what gets adoption but I feel like it swings way too far in the other direction. I see this a lot: your choices are either massively obese or minimalist to a fault. Where is the middle ground? From an engineering perspective, I think that is the most interesting area: designing something that is small and simple yet surprisingly capable. That is also what I want from software as a user. I think Gemini goes in the "weekend project" category whereas a modern browser is more like hundreds of man-years. I evaluated Gemini, wanted to like it, almost like it, but I think it just doesn't allow me to do what I want to do. It is too simple. I think it should be possible to design something that is more flexible, yet for which a competent programmer can write a basic client implementation in a few weekends (with some features missing but the client still being entirely usable), make it feature-complete in an additional dozen weekends or so, and also add & finish all the extras and fluff and polish over the remaining year. From there on it's maintenance and bugfixes and minor features which can be worked on as a hobby by a small group without having to devote all their lives to it. These projects are also small enough that if someone's not happy, they can fork and customize (and still be able to "keep up" with whatever developments might happen in terms of standardised functionality).

skyfaller 6y ago
How would you propose achieving a middle ground? Anything in the middle will still have to have a lot of features, and once you have a lot of features, how do you hold the line and prevent people from adding more features until it is just the absurdly complex modern web-as-operating-system again? The reason Gemini is so simple is not simply to keep it simple enough that anyone can write their own client or server, although that is certainly one goal. A big reason it is so simple is a general policy of rejecting new features, and that minimalism may be necessary to prevent scope creep.
- thrwaeasddsaf 6y ago
  If you think scope creep is an inevitable consequence of not making a protocol non-extensible, I have a thousand RFCs to show you.. Really you just need to outline some goals and rules and have the right people at the top calling the shots. Plenty of things are designed and developed with a conservative mindset where adding new features has to be very carefully justified. I'd also like to point out that it's worthwhile to think of the complexity of all the systems you require, and not just one protocol/document format. Gemini may be simple, but when it is too simple, you will need a different protocol or format. So now you have two, with somewhat overlapping functionality that you can't merge if you insist on keeping everything absolutely minimalist. Only two isn't going to be enough.. so if you're willing to do what you do, complexity is inevitable, whether it is in a single protocol or spread across a clusterfuck of dozens of protocols. Again, it is good engineering and good abstraction to find a solution that gives a lot of bang for buck, i.e. is reasonably simple yet covers multiple bases.

skyfaller 6y ago

How would you propose achieving a middle ground? Anything in the middle will still have to have a lot of features, and once you have a lot of features, how do you hold the line and prevent people from adding more features until it is just the absurdly complex modern web-as-operating-system again? The reason Gemini is so simple is not simply to keep it simple enough that anyone can write their own client or server, although that is certainly one goal. A big reason it is so simple is a general policy of rejecting new features, and that minimalism may be necessary to prevent scope creep.

thrwaeasddsaf 6y ago
If you think scope creep is an inevitable consequence of not making a protocol non-extensible, I have a thousand RFCs to show you.. Really you just need to outline some goals and rules and have the right people at the top calling the shots. Plenty of things are designed and developed with a conservative mindset where adding new features has to be very carefully justified. I'd also like to point out that it's worthwhile to think of the complexity of all the systems you require, and not just one protocol/document format. Gemini may be simple, but when it is too simple, you will need a different protocol or format. So now you have two, with somewhat overlapping functionality that you can't merge if you insist on keeping everything absolutely minimalist. Only two isn't going to be enough.. so if you're willing to do what you do, complexity is inevitable, whether it is in a single protocol or spread across a clusterfuck of dozens of protocols. Again, it is good engineering and good abstraction to find a solution that gives a lot of bang for buck, i.e. is reasonably simple yet covers multiple bases.