Discriminatory Code Sharing



July 17th, 2018 by Diana Coman

While the world at large is making itself busy with the current fashion of discrimination hunting and public pillorying of any offenders it can get its public hands on, TMSR is peacefully and earnestly discussing in the forum the introduction of a new code release paradigm that is quite as discriminatory as it can be and as a result to rather significant benefit to all. The initial proposal as stated by Mircea Popescu in #trilema has the following parts (split and formatted from the logs in a way that I find easier to read):

the following code release paradigm :
client (code) author
a) releases code encrypted to l1, signed and deeded (so basically, gpg -aer asciilifeform -r ave1 -r etc) ;

b) releases precompiled binaries for allcomers.

advantages:
1. permits us to control binaries, which means stuff like http://btcbase.org/log/2018-07-16#1834888 (which i'm very much impressed with, btw) ;

2. permits to reserve some interest for the author, because the strategic thinking over at minigame is that we'll want client competition (from skinning all the way to all the way) and remuneration by installs (hence all that hash dance in the new c-s protocol) ;

3. very clearly quashes the idiocy of rms-ism AND ers-ism ("open source" bla bla), and makes the strong political statement that indeed there is a difference between nose breathers and mouthbreathers and so on.

disadvantage:
this only works if we can rely on l1 to keep a secret ; which means things (such as, that it can't be as big, for instance).

The discussion can be found in the logs but it can be a bit difficult to follow as it spills over into next day and into other topics on the way. The initial focus was on the issue of "keep a secret" and then on that of "controlling binaries". While both those aspects are worth discussing and are certainly covered to some extent in the log throughout yesterday, they are actually NOT at all central to the proposal as I came to understand it at length. And the discussion perhaps focused on those at first mainly because the speakers - both I and Stanislav - have more practice with the technical perspective and so we read the proposal first through that lens. However, as I kept prodding the issue with questions, various bits and pieces fell into place for me and the whole thing started making more sense. Specifically, this is my current understanding of this proposal:

Discriminatory Code Sharing

The proposal is simply a clear and pointy (i.e. with actual practical power and means to use this power) discrimination between:

a. the general "public" who has access to binaries and nothing else.

b. qualified individuals (l1) who have access to sources.

Note the mass noun in a. and the distinct persons in b.

Note also that the a/b distinction above is a political issue first and foremost. It *does not matter* nor it could possibly matter if some non-l1 somewhere gets at some point his hands on some code or the other. So it sees it. So what? For as long as the "seeing" happens outside the walls of TMSR or otherwise put outside the structure of authority, there is no meaning to it. In practical terms, they can of course see the code, come within the walls and contribute as a result and then what's the problem or the loss? Or they can herp and derp outside and be ignored by TMSR just as they were before they found that code in the woods, so again what's the problem or the loss?

Essentially, code is to be shared but not with anyone able to push some keys. Code is to be shared with and even offered to those who can do something meaningful with it - and only to those. What they decide to do with it, if anything, is of course their own call entirely.

There are significant advantages to this approach:

1. It makes explicit and it gives more meaning to an existing and unalterable difference between "users of software": some can and will read source code, others will just execute whatever they download. Those who consider themselves in the first category but possibly unjustly lumped at the moment with the second, have the option of doing some work and getting into l1.

2. It offers quite a few things to those who actually write useful code:

  • a way of getting help from those most able to give it;
  • as much protection as there currently is anywhere to be found against the significant and eternal pressures of the mindless horde1 as well as against the very real monkeys who are always looking to pick up the fruit of someone else's labour when it's ready;
  • a clearer and arguably easier avenue to making a name for themselves and in the process finding their own place, be it in l1, l2, lx or outside the walls entirely.

3. It adds more meaning (power and responsibility, what else) to the l1 status.

4. It puts more pressure on the need for reproducible builds since the practical and technical aspects of most of the above relies to some extent on those and the actual exercise of the new powers will inevitably run into the issue of non-reproducible builds (as well as any other relevant technical issues that are perhaps yet to be revealed as people stumble upon them).

The only disadvantage stated from the beginning was the fact that the approach is unlikely to scale very well as the size of l1 increases - there needs to be a rather close agreement within l1 at the very least on the core aspect here: code is not secret but sharing it is a responsibility and choosing the recipients is a matter not to be taken lightly.

I can perhaps see a potentially different issue with submitted code that keeps growing in volume. However, I'd expect that it is a bit too early to worry about that and the solution is more likely to be naturally found - if nobody actually reads it, there is no effect. For the code's author it's just as if the code wasn't even submitted in the first place if not even worse since he might easily land in the soup for being an idiot who can't read the log and doesn't understand at all how lines of code are weighed in the first place.

Based on my above understanding of this proposal, I must say that I'm all for it. From all I see, it's a rather significant improvement for everyone even remotely touched by it and at relatively little real cost to anyone involved.

It might be of course that I misunderstood the proposal in parts or entirely in which case I very much want to hear in the comments below where I'm mistaken.


  1. Also known as the horde of idiots, mountain of idiots, sewer rats and so on. 

Comments feed: RSS 2.0

3 Responses to “Discriminatory Code Sharing”

  1. Diana Coman says:

    It turns out I even forgot one advantage: it arguably makes it easier to "drink the ocean" in search of the few who can be helped on to the shore, where people live.

  2. […] excuse, nothing at all. What fucking democracy, I ask you again ? The world is neatly split among they who need an excuse to be here and they who do not, what more is there to it […]

  3. […] ; we can all print articles about it, after the fact, like I suppose in a sense this one, and like diana's, and so on -- but it, the it itself, belongs in retrospect exactly where it went and found its own […]

Leave a Reply to Diana Coman