Mycelium Network: State Report after Stage One Bootstrap
Khleedril, October 2025

This document is intended for a general, lay, audience, though preferably with some awareness of PGP keys and their use. The Mycelium network itself currently is only suitable for software developers with their own Internet servers, and this document contains some detailed, though simple, technicalities for completeness, but the reader can safely skip over these without loss of understanding of the rest of the document.

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 #mycelium.

The source text for this document and all of the referenced source code exist as commits in a GIT repository — at this moment in time residing at https://khleedril.org/forge/mycelium/mycelium — signed by khleedril@a.b, the PGP public key available at https://khleedril.org/gpg-key, 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}; note that the last clause is the fingerprint of the aforementioned key.

The empathetic Internet is erring towards peer-2-peer (or even peer-4-peer) distributed systems. This is great when you are part of a posse of trusted peers, but what if a stranger turns up and asks to join? Unfortunately Byzantine interlopers, AI-powered robots and information scrapers, are always in eminence and you really don’t want any of those in your network.

Another use case, for which the Mycelium network is specifically designed, is where a project needs a vote of its users on some proposed change. In this case, one would want anybody to feel free to have a say, just as long as they are a bona fide, honest person. You would also like to offer them the opportunity to vote anonymously.

Suppose, in real life, you are invited to a party, and turn up at a big house with a hundred guests milling around. You are going along with two friends, but otherwise will be a stranger amidst the crowd.

The first thing you might do is say, “Hello,” to some random stranger who looks to be equally at sea. You might strike up a conversation aiming to find out something about the person, and whether they know any of the crowd here. At this stage you don’t know if they are trustable or not; whether any information they give can be taken as truth.

After a time you notice a person who seems to be of great interest to lots of other people. You ask either your new friend or your companions who that person is. Nobody knows, but one of your own friends turns around and nudges a friend of his, who your posse is lingering close to. They don’t know either, but turn to their own group to find out if anyone there knows. Eventually they turn back round and tells your friend, who tells you, that the person is a scallywag and that you may safely be entertained by their tall tales but don’t believe a word they say.

The Mycelium network is designed to work similarly to the social situation above. If a stranger turns up online and you want to find out if they are actually a person, and a reputable one at that, you ask a friend you trust, and they may in turn ask their own friends, until a positive ID maybe turns up. The trust between friends is mutual; you can only ask them for help if they have already given you the means to do so. In this way members of the Mycelium network can feel safe that they won’t be inundated with pointless requests from random people, or data-reaping bots.

In fact, the whole network is non-discoverable. You have to know that a person exists in the first place to make an enquiry about them, and then you can only make the enquiry to the few friends who have trusted you with their assessor end-point: a hidden address on the World Wide Web which Mycelium participants only disclose to their friends.

The original design of the PGP (Pretty Good Privacy) system had the intention that keys of unknown people could be fetched from a trusted server, and can even be discovered there. The keys were associated with e-mail addresses, which were effectively the keys’ handles. The trust in a key involved participants putting trust labels on the keys they knew something about, and then one trusts the trust assigned by those trusted by them.

Within the Mycelium system, keys are deliberately not discoverable. They are not assumed to be attached to any e-mail address or other name tag; they are known only by their own cryptographic fingerprint.

However, this does not preclude the possibility that they are associated, and this will, in fact, help to strengthen the provenance of the person. Also, these keys might have been used to sign commits in a GIT repository, adding reputation to a person as a software developer.

In the first instance, there are two immediate questions you want to know about a key fingerprint: does it belong to a real, actual, person, and is that person reliable as a member of the Mycelium network? Thus there are two immediate ‘contexts’ we are interested in. Within the protocol, contexts are referred to by unique identifiers, and Universally Unique Identifiers, UUIDs, are specifically used.

Moving on from this, contexts can be created to address many other types of issues, such as preferred one-of-many choices, multiple choices, ballots, and general governance decisions which have to be acceptable to a suitable majority of interested parties; questions of membership, or level of association with a foreign project, might also be asked. Furthermore, projects can use different algorithms for assessing the vote, such as first-past-the-post versus Condorcet, for example, or weighting of votes according the degree of separation of a person from a project.

The first bootstrap phase of the Mycelium project, which has just concluded, demonstrated how a simple ballot could be run by a project. The ballot is deemed to be owned by some person, and a new context is created. Then anyone can express their opinion by providing an assessment of that person in that context, and the project could simply ask them for their opinion. But the network is non-discoverable so voters can’t be just found; they have to come forward. We would also like to offer voters a degree of anonymity if they wish to exercise that. And so the methodology which is used consists of the following steps.

1. People come forward to the projectʼs polling web site and register themselves, via their public PGP key, as voters, using their secret key to encrypt the end-point address they want to use for the vote (this should be different from the one they tell their friends about). The encryption ensures that the person really does own the secret key behind the fingerprint, hence they are who they say they are.
2. The project then reaches out to its trusted members, probably governors, to attempt to verify, via the fingerprint of the public key, that they are a known, real, person, with dependable agency in making choices.
3. If the voter is discovered to be real and reliable, the project then reaches out to the voterʼs given end-point, and gets their opinion on the vote directly from them.
4. The project must then summarise, according to project policy, all the votes, and draw a final decision based on the outcome.

Participation requires three things: a secret PGP key, an assessor end-point, and a small number of friends you trust who are also either erstwhile participants or wishing to become one.

1. Your identity on the network is the fingerprint of the public part of the PGP key. It goes without saying that you must keep the full secret key to yourself.
2. You must supply an assessor end-point: a difficult to guess HTTPS address (i.e. a secure web address), which reads JSON (Java Object Notation) payloads and returns a JSON response. The payload will ask for your opinion of some PGP key fingerprint over some context, and you reply by giving a number between 0 and 100 accordingly (or you can give a “no-basis” response to indicate that you have no basis on which to make a judgement about this person).
3. You work with your friends to set your end-point up so that it knows all your friends’ end-points, and provides the opinion that each of your friends is a person with a weight of 100 and some assessor (reliability) value. Your friends should return the same favour to you (though they don’t have to).

This section is a short summary of the details of the Stage-0 Bootstrap step white paper⁴, which forms the formal introduction to the protocol.

The voting process is formally defined in the Bootstrap Stage 1 white paper⁵.

A vote is identified by some context under some person. To take part in the vote you need to

1. Be a participant in a Mycelium network, preferably connected by some degree to the project.
2. Modify your assessor end-point to give a measure to the vote person/context pair, according to your opinion on the matter.
3. Modify your front web server to access the end-point through a new, undiscoverable, URL (Uniform Resource Locator, a.k.a. web address), so that you don’t reveal the end-point you use to communicate with your friends, (if you are paranoid you can put your voting end-point on a completely different, unrelated, host).
4. You then go to the voting web-site, and register your new end-point.

The project will, over a period of time, verify you through the Mycelium network starting with its own trusted friends, and then will contact your end-point directly for your vote.

You should close down the temporary end-point after the vote finishes as it will not be accessed again.

A project which wants to run a vote must first have some parameters in place, such as when registration ends and counting begins, how the votes will be combined, and how the result determines the ultimate resolution of the issue at hand.

The next step is setting up the vote itself, which, at the moment, involves some programming and system management. The code developed for the Mycelium stage one bootstrap, described below, can be taken as a starting point. It is, of course, anticipated that this will become a general-purpose tool which laypeople can use. Publicly, the vote is given a context UUID and is considered to be against the person who would be the beneficiary of the vote; these parameters and the vote itself, the URI of the web service at which registration may be made, are advertised widely. Once the deadline passes for registrations, the results are almost immediate as it involves simply visiting all the votersʼ end-points and totting up the results. The final result is left at the web service for all to see.

In the case of the Stage-1 bootstrap which has just completed, voters were asked whether or not they accepted the idea of the bootstrap. The votes given in the range 0-100 were taken to indicate favour on a scale 0-100, and the arithmetic mean was used to summarise all the votes. The motion was carried if the result was anything above zero. This is all of course very pathological (the self-referentiality is the reason this is termed a bootstrap of the Mycelium project), but forms the prototype of how project governance bodies need to think about the nature of votes they want to run.

The bootstrap was implemented as a front-end web server called polling-booth where voters register and which provides the current status of the voting process, a middleware daemon called adjudicator which sees the registrations, verifies them, and collects their votes. The two programs communicate through the medium of a back-end Mysql database. The full source code for these programs, written in Rust, are available and are intended to be adapted by other projects.

The bootstrap opened on 14th September 2025, and the registration deadline was end-of-day 28th September, 2025. It was advertised on Mastodon, and there was an interim advertisement there on 21st September, halfway through the registration period, to drum up more interest.

The registration point was https://khleedril.org/mycelium-vote. This is still live at the time of writing, but will disappear or become re-purposed at some point in the near future.

There were two faults that showed up with the software (these have been retrospectively corrected in the code repository).

1. After the counting finished an indicator was moved to Phase 5 of 4(!), but the software was not prepared for this and had no HTML to present, resulting in a HTTP 505 error.
2. Internally, the code put key fingerprints into the back-end database in a non-normal form (lowercase instead of uppercase) leading to incorrect final reckoning.

Further, it proved rather painful to set up the software, including a special internal end-point to represent the project and its associated governors (just the sole developer at this time). This is due to the minimalism which had been adopted to leave the code malleable for onwards developments in light of the experience gained from running this bootstrap stage: all vote parameters were hard-wired in the source and the programs had to be re-compiled and re-deployed when changes were needed.

There were 13 registrations, which all took part in the first week of the registration period, plus the developer. Of the 13, one group of seven referred to each other, and a group of 5. These people did not make themselves known to the project, but were presumably rings of contributors to two different projects. The final registrant, who also did not make themselves known, was not associated with anybody in the network.

The voters accepted the proposal with a unanimous 100/100 rating. The proposal was duly passed and the updated code is considered the official head of the project development repository.

The GIT⁶ repository contains the definitive mycelium.rs, found on branch boot-0, at version 1.0.2, and a more user-friendly version plus polling_booth.rs and adjudicator.rs, on branch main at tag v1.1.2, at version 1.1.2. The current HEAD of the main branch is at version 1.2.0 and contains versions of the three programs which are further refined for user-friendliness (but still only really accessible to programmers at this point).