Mycelium Totally Un-Discoverable Developer Network: Bootstrap Stage Zero
Khleedril, August 2025

This document is aimed at software developers who manage an Internet web server, and are comfortable with HTTPS, JSON, and PGP.

Wide dissemination of this document is strongly encouraged, but modifications are not permitted. The document should be referred to by the title and date shown above. Legally the work should be considered to be copyrighted by the author with terms according to the Creative Commons (CC) BY-ND¹ license. The document is being discussed on Mastodon under the hash-tag #myceliumboot0.

The source text for this document and the referenced source code exists as commits in a GIT repositiory — at this moment in time residing at https://khleedril.org/forge/mycelium/mycelium — signed by khleedril@a.b, PGP fingerprint E23C21ED864FF4F3A7114CDFCA471FD501618A49, the same key that I’m using in the Mycelium network; it will hopefully develop reputation as the network evolves!

If you have access to the Guix command, you can run

guix git authenticate \
       d92072679363b63576862ca206add26f8039114c \
       E23C21ED864FF4F3A7114CDFCA471FD501618A49

to assert the authenticity of the entire repository after you have cloned it to your own machine.^{2, 3}

We look back over the work of Indymedia⁴, Occupy Movement⁵, and Hamish Campbell’s ideas on an open web governance body^{6, 7}, and realize that there are two imminent problems: the choice of first use case, and the ramp-up process to arrive at something which works. We believe the first application of governance is the managed development of the governance project itself. This gives us an immediate Catch-22: we want to develop code to enable fully federated governance; we want the code development to be governed by the fully federated governance: we need to bootstrap the process of assembling a governance of developers to develop the governance infrastructure. So we lay out here the smallest first step (which we christen Stage Zero) to get this process started, or bootstrapped.

The extant projects are trying to single-handedly get funding. This points to another Catch-22, wherein a movement of sorts needs to be established so that funding can be justified, yet real (i.e., full-time) progress may be stilted without some funding.

As to a final Catch-22: it is acknowledged that governance is a messy business unsuited to inflexible algorithms. But on-line governance needs to be managed by a network of computers, and computers run on algorithms. Thus here we endeavour to make the smallest possible working algorithm we can imagine, and leave it to further effort to put actual governance structures in place, using the Mycelium network as the unassuming root of trust in the system.

There is no central register of keys, and no way to traverse the Mycelium network to discover them. The best any member of the network can do is ask other members they know about to provide an assessment of trust in some known key — person — in some known context. The assessor end-points which people provide SHOULD be at some very obscure uniform resource indicator (URI) which will be hidden from prying eyes by transport layer security (TLS). The only people who will know your assessor URI are the friends you tell about it. If you don’t trust them not to denial-of-service (DOS) attack you, they are not your friends!

There is, in fact, no centre-point at all. The project does not have an Internet domain name, a web server of its own, or an official GIT repository. I might be special just at this moment in time in that I’m the first to have a Mycelium assessor end-point, and a GIT repository with the code (and this document) in, but that’s as far as it goes.

The request should be the JSON object

{ “request-id”: “<UUID: string>”,
  “request-depth”: <positive integer>,
  “key”: “<GPG fingerprint: string>”,
  “context”: “<UUID: string>” }

presented as UTF-8 text in the body of a HTTPS POST request, asking for an assessment of the trust of the given key in the given context. The key and the context are the important parts, obviously, and then the request-id should be a new UUID created by the original requestor and passed along to others in the chain; if a node sees a UUID twice in a short space of time it means there is a loop in the friend network (not uncommon), and so the response in this case should be a no-basis one, i.e. there is no basis on which to make a judgement of measure.

The request-depth is set to some value by the initial requestor and decremented by one whenever the request is passed from one friend to another; if zero is reached a no-basis response should also be assumed (as a safety measure, nodes should ensure that the depth is not unreasonably large so as to flood the network). This will guarantee termination of the process and not flood the entire Mycelium network. If the theory holds that everyone on Earth is related by up to seven degrees of freedom, then setting the parameter to seven would seem to make the system conclusive. However, this will flood the network and take a long time to return, so for practical purposes the parameter should probably be no more than three or four. In practice it would be expected that people will associate in rings (e.g. all members of a project), so a low fan-out should suffice. This may need tuning in light of experience with the protocol, and adjusting as the network matures.

The HTTP response body would be either

“no-basis”

in the case that the service has no basis for making an assessment of a level of trust, or

{“trust”: <integer 0-100>}

presented as UTF-8.

The trust levels — ‘trust’ being some measure of trust, belief, provenance, reliability, &c., depending on context — between 0 and 100 are to be understood thus. A value of 50 means there is no opinion on a person’s trust, less than 50 means that the person is actively untrusted, and above 50 means that they are trusted to some extent; between 50 and 75 means that a person is trusted with some reservation, whereas a value above 75 means they are more trusted than not. In many cases actions by people should only be considered valid if their trust level in the context of the action is above 75.

Of course these are executive decisions being made unaccountably for the purpose of bootstrapping the project; it should be regarded as a minimal seed for the bootstrap process, and not impervious to changes in future made by a governance structure in the context of the Mycelium project, which has been given the ID 7a484ea4-82c6-4bf2-a4d9-c31001079f69.

While the communication protocol above is absolutely rigid, and services which do not conform simply will not work, the assessment procedure used by an individual is much less enforced, or even enforceable. Remember that the only people you will deal with are people you innately trust.

If the request-id has been seen recently (in the last 60 seconds), or if the request-depth is zero, then an assessor should return ”no-basis”.

The assessor might directly have an opinion of a key in a context, in which case it would be fair for them to simply return that.

If however they don’t have a measure of this key in this context, they ask all of their friends, or a random subset if they have many. First, check their person context and ignore them if the measure is less than 75 (why are they on your friends list if you don’t really believe they are people?) Then check that their assessor rating, taken to be a weight, is at least positive. Then send a request asking for their assessment, decrementing the depth number by one. If they return “no-basis”, ignore this. Anything else, we update our trust, starting from 50, with an updater which effectively takes the mean of all trust assessments we receive from our friends, weighted relatively by their assessor context measures (context ID b5cd757f-54fa-4ec3-a1e3-bd5544533c1b) whose value we MUST have locally.

Sample implementation code is enclosed with this document, written in Rust, with the code — not this document — to be understood as definitive; the protocol itself is considered language agnostic. It is kept as simple as possible. You might question the wisdom of hard-wiring friend data, including keys, into the code, and so you should. Remember that this is the zero-stage bootstrap and we are taking baby steps, so we are taking some slightly desperate measures to keep all things simple, and, importantly, introspectible; we don’t want anybody to feel compelled to do anything they are not comfortable with. It is very likely that in the near future this will change to a local database which is updated dynamically, so that some measures, such as reliability estimates, can be automatically updated over time, as well as through a web interface so that non-technical people can join in with more worldly projects than dry protocol development. But we need to get experience with the simple set-up first, and get the tuning right early on.

Note that the communication protocol imposes very little on the assessment methodology. Individual users might come up with their own scheme, which might include caching of historically seen values, turning a node into an aggregator. At this time, such behaviours are discouraged. It should be further noted that most assessments will be weighted averages of those obtained through all friends, and so outliers (disgruntled friends!) and generally bad behaviour in the network, including gaming of the system, should be suppressed, and such things as aggregation behaviour become unworthwhile.