How about approaching the hot problem of 'getting people to care about what software they run'¹ from a place of meaning rather than mere ease of use?

To get to such place of meaning, one would need at the very least to be able to tell confidently at any time what a software version even is and what does it mean. Surprisingly or not, the current way in which software versions are 'defined' and reported doesn't really provide much to be confident about and even less to rely on. Luckily though, the needed tools to change this for the better are in fact available, so let's look at the whole trouble and then the working solution to it all, too.

Through historical accident rather than planning of any sort, software ended up with a rather weak approach to versioning that seems good enough only as long as one doesn't try to lean on it too strongly. Generally, versions for software code are given simply as numbers picked more or less transparently², embedded in the code and then simply read and reported to the user at runtime, on request. So the code says that it's version x.y and the user... takes the code at its word because there isn't much else to do.

Well, there *wasn't* much else to do until now but from now on, there is, courtesy of VaMP: software editions rather than mere versions, offering cryptographic guarantees and embedded historical records that you can check at any time and as often as you like.

Let's start directly with an illustration of use, checking the software version and edition of VaMP itself - and not just any edition but precisely the one that makes available... software editions:

$ vamp version vamp_sw_ed/
************
The code in vamp_sw_ed/ matches a signed software edition and has the following version description from manifest.vamp in vamp_sw_ed/:

787977 vamp_sw_ed Diana Coman Adds software editions, check and reporting via the new 'version' command including authorship (from patch), readership (from sigs) and version info (from manifest file). Further cleanup and improved usability including consistent usage help and order of parameters for all commands (generally the aim is to have command input(s) resource(s) output(s) where resources are supporting the task rather than direct inputs to the task at hand and are usually given as paths, e.g. location of patches, sigs or keys to consider). Adds better support for multiple signatures of the same file through a naming scheme for sig files that includes the base name of the relevant keyfile (which is by default the key's fingerprint).

The software edition producing this exact code version is:
data/patches/vamp_sw_ed.patch
authored by 7ddde85da027e48a9a23aa8573079fff
signed by 7ddde85da027e48a9a23aa8573079fff

Software editions are the code equivalent of literary editions. Just as there are any number of drafts produced before an edition of a book is published, so there are any number of code versions made before a software edition is published. Just as there are others besides the author of a literary work that have a role in and responsibility for a literary edition of a book, so there are other roles and responsibilities for a software edition besides that of writing code. In the most direct terms, a software edition contains and requires more than the code itself - it's a more rounded product that includes as a minimum and in cryptographically verifiable forms, three main parts: the record of the code's history, the published code and the personal responsibility assumed by the publisher, whether that is the same person as the writer or not.

In more concrete terms and as a standard minimum, a software edition will therefore include:

1. The cryptographically verifiable means to obtain a specific code version, consisting in:
   1. A VaMP patch.
   2. The publisher's³ matching signature of the above patch.
   3. The publisher's public key that can be used to verify the above signature.
2. An embedded record of the code's versioning history in the form of a plain text file called manifest.vamp that is part of the code version published in this edition. Each code version adds a new line to the manifest.vamp file, including:
   1. The Bitcoin blockheight at the time when the new code version was created, as the only universal timestamp currently available. Wherever you are in the world when you write a new code version, the blockheight is a more accurate description of time than any 'local time zone' and as such, it's entirely immune to any and all 'challenges' of traditional timestamps, of course.
   2. A short name for the new code version. This tends to serve as the filename for the patch that results in the new code version but note that this is just a convention, not mandatory in any way. The patch can really be called anything at all and one can certainly have any number of different patches that still result, each of them, in the same code version⁴.
   3. The name of the writer of this new code version
   4. A summary of the main changes/additions to the code brought in by the new code version.

In addition to the above, a software edition can include, of course, just about anything else that the publisher wants to include. There is for instance a reasonable case to make perhaps for a record of editions themselves, seeing how they are essentially on a different level than software versions and as such not included in or made visible through the manifest.vamp file. To make the distinction clear, the manifest.vamp file is a historical record of all changes made to the code, hence strictly speaking of all code versions whether published or not. By contrast, editions are signed packagings of specific code versions for which the publisher assumes personal responsibility by signing them with their own key.

Different publishers can maintain their own sets of editions even for the same software and the patches involved may very well be different but the same version of the code has to have the exact same manifest.vamp file in all editions - if that's not the case, then it's simply not at all "the same version of the code" regardless of what one might claim. So publishers may well keep an additional record of their own software editions, whether signed or not, whether in file format or web format and so on. In doing so, they build up their own record, of course and as such can reap the accumulated benefits for their own work over any period of time.

For some additional clarity, let's see also side by side what would the differences be between software changes, versions and editions as supported by VaMP:

In a nutshell, by providing software editions, VaMP leverages cryptography to empower personal users, writers, readers and publishers of software or in other words, everyone who uses computers at all. Combined with RSA keys for personal identity and the Web of Trust (WoT) as public record, software editions are a part of the wider structure and approach that can give people as opposed to bots (or the 'AI') the edge even in this digital environment which is otherwise not at all human-friendly.

Whether enough people figure it out and make good enough use of it before the deluge of bot-created 'content' is too great to even find one's way to any meaning anymore is something that depends on each individual person, as simple as that. As my public record shows, I have always been firmly on the human side on this and I don't plan to stop any time soon so I'll continue working to increase and support people's leverage as connected individuals, first and foremost, not the bots' training data sets or the like. What you do though, as always, is entirely your choice and note that you make it with every action you take or refuse to take, whether you realise what you are thus choosing or not.

1. It is actually a hotter problem than it might seem. It's not *just* that so much runs today in and on software of all sorts but also that the bots (alternatively termed 'AI') have the natural advantage when it comes to the digital environment in general and code or machines in particular. The popular current approaches to 'make coding like plumbing' or to rely on 'AI' to 'write code' can only make it worse, not because they'll take away jobs but because they'll end up inevitably by drowning everyone in such an endless amount of meaninglessness that it would take several lifetimes to even filter through it, let alone get to understand or use or be in control of any part of it. And if you go along with it and get therefore well and truly caught, what you'll end up doing under the guise of 'using it' is much more 'being used by it.' There are better options for sure but they tend to require work. ↩

2. The main approach uses two numbers, one considered 'major' and thus changing only when there are 'significant' differences and the other 'minor' and thus changing in principle for any code change. Note that there isn't any clear definition for what 'major' or 'minor' mean in the first place and I doubt there can even be some reliable definition that holds for everyone involved since quite often the versioning is not even a matter of coding really but one of marketing and/or responding to market pressures of all sorts.

   Even leaving this aside for the moment and to make matters more confusing, it's quite clear that not all changes get to increase even the minor number since there are plenty of code changes that are lumped together at a later stage into what counts then as a new minor version.

   Worse even, there is no reliable way to actually *check* a version, whatever that might be. The traditional way in which versions are 'checked' is simply by interrogating the code itself at runtime and such self-reporting is nothing more than reading and reporting some embedded numbers, without checking anything and without any real link to the whole as such - whether the code changed or not overall or in any of its parts, it can certainly keep reporting the same number for ever and ever.

    ↩

3. Note that this may or may not be the same as the writer of the code. More importantly here is the *reader* of the code and this means specifically the one who is willing to publicly and personally assume responsibility for a software edition by putting their signature on it. ↩

4. A VaMP patch fully describes and guarantees a *resulting* code state starting from an equally well defined *starting* code state. Hence, to obtain the code version you want, you can use one patch or another depending on what code state you are starting from, there's no problem with that and there are clear benefits to it, too. For instance, there's no reason to have to apply 101 patches every time just because the version you want happens to be, indeed, the 101st - you just make a 'shortcut' patch that gets you straight to version 101st and use that without losing for it any of the history or any of the guarantees, it's as simple as that. ↩

Category: Coding, VaMP

Comments feed: RSS 2.0