I have been a little concerned with how exactly the choice can take place without compromising privacy: in particular, if the active enquirer sends all their answers to the other (distributed) local servers, even without classic identifying data, that might allow a server that kept all the answers to work out who the enquirer was.

In order for a fit between requirements and answers to be assessed, the two sets of information must necessarily meet somewhere. The obvious question is, where? Possible approaches are suggested, aimed at reducing the spread of property answers.

Two kinds of information are in play:

1. Personal property information and credentials that are private to each chooser, and stable. This includes all personal identifying information, such as date/place of birth, current location, physical characteristics, stable innate characteristics, acquired characteristics, knowledge, skills, competences, etc. All of these have the potential to be attested or verified (or not) by other parties.
2. Information of choice. This is to do with what is wanted by each chooser, both concerning the relationship with the other party, and the properties of the other party. For employment, this would include the nature, duration, and other characteristics of the position. For personal relationships, this would include the scope, depth and desired duration of the relationship.

Potentially, up to three kinds of device/server are in play:

1. The chooser's device, whatever it may be. The assumption is that this is used intermittently; it may not be connected 24/7, whether it be smartphone, tablet, laptop or otherwise. We won't be talking more about these devices, as they are just ancillary to the process, enabling contact with the choosers.
2. The trusted (or “spoke”) servers. These are where all the property and relational information from individual choosers is stored, so that it is accessible all the time for fitting. Think about the simile with financial banks: anyone can choose which bank they trust to keep their money safe; similarly for keeping valuable personal information safe, secure and private. Some kind of always-on service to keep chooser information is necessary for RegenCHOICE to function effectively.
3. There may also be central, hub, or fitting server(s). There could be one, or more of these if desired for redundancy and spreading load.

Recall also that there are two complementary modes of enquiry.

1. Active enquiries are ones that are being tried out in the moment by the enquirer.
2. Standing enquiries are ones that are left waiting on the servers by the respondents, to be available to fit with active enquiries.

It is possible to imagine RegenCHOICE working with no central servers, purely distributed, preserving privacy as follows.

1. Active enquiry requirements only, not property answers, are broadcast from the originating server to all other servers.
2. Each server checks the active requirements against all the standing enquiry answers.
3. For each standing enquiry all of whose answers fit the active requirements, a message is returned with an internal ID of the chooser plus their requirements.
4. The enquirer's server checks each one against the enquirer's answers, and counts up the total number of fits, N.
5. Unless 0 < N < 10, the enquirer is told the total number.
6. If N = 0, further messages are sent to assess which questions the enquirer needs to answer, if any; or if there are no remaining respondent requirement questions to answer, some guidance on fruitful requirements to relax.
7. If N > 9, further calculations are performed to suggest what other requirements could be fruitfully added.
8. If 0 < N < 10, further messages are sent to request all the details needed to present the candidates to the enquirer.

1. When an enquirer stops being active and decides to save the enquiry as standing, this enquiry is distributed to all the other servers and held there until changed or revoked.
2. This means that some initial calculations can be done on the enquirer's server. If the enquirer's answers fit the respondents' requirements, the enquirer's requirements are sent to each appropriate other server, and the process continues similarly to above.

An alternative arrangement involves central servers where the actual fitting process takes place. Having one would work; however having more than one would be more resilient. The rest is written as if there is just one central server.

1. Whenever an enquiry is left standing from being active, its requirements are stored on the central server, including a local server id and a personal id within that local server.
2. When an enquirer makes an active enquiry, they send all their active answers along with the active requirements to the central server.
3. The central server then fits the active answers with the standing requirements, resulting in a list of standing enquiries that so-far-fit the active answers.
4. The active property requirements are then sent to the respective local servers along with a list of so-far-fitting respondents on that server.
5. The local servers check the active requirements against the standing respondents' property answers and send back a list of both-ways fits to the central server.
6. The central server adds up the potential fits N.
   • If N > 9, sends N to the active local server
   • If N = 0, more information can be sent to the local server: what exactly, and how gathered, will be the subject of further study.
   • 0 < N < 10:
     • requests the passive local servers to send all the relevant info,
     • then passed on to the active local server