Hey everyone, Solderpunk at some point mentioned a temporary spec freeze, unfreezing for early 2021, then permanently finalizing the spec. I have no idea if this is still the plan or not, but I still feel it would be a good idea to discuss: what modifications would be made to the spec in an "unfrozen" period, if any; what modifications would be made to the spec in its permanent finalization stage; and how companion specs and the like would be dealt with, both now and in the finalization stage. Firstly, how spec changes should be approached in an unfrozen period, if any of those pop up. We may be in one now, since Solderpunk updated the spec to fix schemes? But at any rate, I believe most would agree that the current state of debate is probably not the best in terms of actually coming to an agreement. Not that you'll ever reach 100% consensus, but most current debates seem pretty evenly divided which isn't conductive to actually choosing a side to reflect in the spec. I'm unsure how to remedy this, but I'm bringing it up. On what changes should actually be made, in my opinion the only changes that should be made at this point should be to fix glaring problems in the spec. I guess that creates another problem, because people can't even agree what a "glaring problem" is! Solderpunk's been pretty reasonable, so I'll leave it up to them to actually decide what's a problem and what's not, but it's a rule of thumb to say that things that "would be nice" shouldn't be included at this point (I'm saying this as someone who has a few would-be-nices of my own[a]). As a second rule of thumb, I'd say no breaking changes, even if they do fix a problem in the spec. Backwards compatibility is painful, but luckily we only have a year and a half to deal with as opposed to the decades some projects have to be compatible with, so hopefully it isn't as much of a hardship as it possibly could've been. Onto a permanent spec freeze, if such a thing would occur. I believe making the spec totally immutable would be arrogant on our part, because you can't pretend that it is 100% perfect. I'd say that no feature changes, and few to no major changes in general should be made. I'd say that there should only be three classes of changes in a finalized spec: technological upgrades, clarifications, and error corrections. Technological upgrades would be if a component of the stack has an upgrade or a replacement, particularly when there's security involved. To use TLS as an example, it would be removing TLSv2 support when TLSv3 reaches wide support. Clarifications would be just that, clarifications of the spec in areas that are unclear or create ambiguity. Error corrections would be fixing minor errors and edge cases that can be fixed without breaking anything, and add no new features. This is breaking so wouldn't count, but an example of error correction would be the most recent spec change that adds a mandatory scheme to requests. Finally, I'd like to address companion specs. Especially if the spec is permanently finalized, there will be companion specs popping up all over the place. This can be viewed as good, because it means that each spec is nice and unix-y, doing only one thing each. This creates the problem the web has though, where authors are expected to support an amorphous and constantly changing group of specs and results in huge applications that are impossible to maintain. Even if companion specs like Titan are fine now, it leaves a huge opening for the web-ification of gemini in the future WHEN (not if) FAANG-inspired malicious actors take an interest in it. There are a few ways to address this, from the hardliner approach of completely disallowing companions to the 100% inclusive approach of creating a dedicated RFC listing. Obviously a middle ground will have to be found, but a discussion on where exactly that may be is warranted. You don't want to cut out useful things like titan, but you also don't want to leave a huge extensibility window open. A long rambling of my thoughts, but there's some discussion points (that in hindsight should've been broken up into multiple emails) that IMO should be addressed before any firm decisions are made regarding the future of the spec. ~nytpu [a]: gemini://gemi.dev/gemini-mailing-list/messages/003748.gmi -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/5311 299b/attachment-0001.sig>
---
Next in thread (2 of 25): 🗣️ Stephane Bortzmeyer (stephane (a) sources.org)