💾 Archived View for station.martinrue.com › resetreboot › 2260d395e4e94e0bb716800a67ad86df captured on 2024-07-09 at 01:16:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-06-16)
-=-=-=-=-=-=-
Read this from the pico.sh "Finally, we have noticed great projects that over time continue to expand their scope until it buckles under its own weight. Without restraint, projects quickly expand until they require a team to maintain them or the developers burn out and get bored" I think this applies to Gemini perfectly too.
1 year ago · 👍 eph, jsreed5
gemini should be an rfc. then it is easier to manage and everyone is free to not support extensions that one don’t like. in that process, i think, instead of bloat we would see an even further reduction, taking some ideas from spartan. ietf people are very good at reducing stuff to the bare minimum if they want to. · 1 year ago
@jsreed5 No, no. I think that when Solderpunk made the protocol limited and not extensible, he was on the same boat as the pico.sh people. Scope creep, adding things "because we can" and becoming an enormous monster that no one really understands fully is what he was preventing on the first place.
Then some people talk about extending Gemini and I'm «you've not learned anything from the web». · 1 year ago
Can you elaborate on this? Do you feel Gemini as a technology is too big to continue unguided? Do you feel a particular service or capsule paradigm has led to that? I'm interested in hearing more of your thoughts. · 1 year ago