plant: the plan

This is a public draft - and slow updated document - and attempt to summarize my notes on paper and other places, from 2015 to now. There will be rough edges, no explanations, and everything you could possibly do wrong with designs for a while. What will follow from this is at some point if necessary a formal specification, so that you can have a reimplementation based on design spec + good documentation + (some day) existing source code. At times I have chosen to explore solutions I haven't tried yet, and the purpose infotropique and plant in particular is to only build things which are necessary, not to explore yet another take on some well-explored subject. If any PM can be wrapped around or contributed to in a way which meets the requirements, I'm more than happy to leave this be as a mere thought-experiment. The eventuality of contributing this somewhere in its entirety does not only depend on technical reasons and community.

In some parts I don't use capitalization of words or sentences. This is intentional.


  • must be implemented in the most energy efficient way possible at this time
  • must be documented in extensive detail to remove the concept of a one single knowledge keeper
  • must be extensible with custom extension
  • must hold no opinion about content it is used for to distribute, in other words you should be free to use it for whatever purpose fits your usecase
  • should encourage reproducible builds
  • should encourage build recipes which promise to be build reliable regardless of time or system (frozen DAGs)
  • must neither encourage nor default to distribution via longrunning build-machines
  • should encourage sharing receipes and built artifacts with a group of people which might be interested in the same topics;
  • should be built and maintained on an interest-driven sharing community
  • should encourage bootstrappable build practices
  • must not include an entire operating system or tools to build it; if anything the ability to do so should be an extension
  • must include tools which enable and help self-governance

From these principles, we can derive more specific requirements:

  • interoperation with other package managers should be possible (out of the box or as plugin)
    • import, export, direct processing
  • the core of the software or extensions of it should enable writing extensions and other consumable pieces in the language of your choice.

technical choices and requirements an implementation of plant should consider:

  • it should be able to be ported to different operating systems
  • support for older architectures would be nice to have
  • memory safety would be nice to have

Not yet broken down into general requirements:

  • There must not be any possibility for traffic analysis in the long-run. Using TLS etc is not really necessary when you know the hash in advance. But if this protocol stack is reasonable well defined and developed (or parts of it), we can see package installations and traffic around packages as a part of a bigger picture. Every networked action can be used as cover traffic. Today you can easily give away information or get compromised through server attacks. Why should I involuntarily tell anyone but the people I disclose it to which (for example) software packages I have installed? If the underlying network stack programmatically ensures reliable, secure data transactions not for the sake of anonymity but for the sake of not consenting to be profiled and so forth, this is a worthy tradeoff.
  • speed (in execution and so forth) is not a necessary requirement
  • "Tools which enable and help self-governance" are necessary since we do not make authoritative definitions of what can be packaged ("generic package manager") and we still need to let people whi use plant handle what they do with it.

tor, as inspiration.

  • do no harm (the code should not be a liability to the user)
  • have confidence in what is deployed
  • reduced size/memory requirements
  • developer friendliness
  • productivity
  • cross platform compatibility
  • not adding too much overhead
  • re-use existing test vectors
  • reproducibility

see 2017Amsterdam notes from Tor.