Sections replacing Groups


So I found a pretty good explenation about what sections are and how they use Data Chains here. However, there are some things I don’t quite understand and I hope some of you might be able to help me. So, before the introduction of Sections, nodes used to be organized in groups and a node could be part of many different groups, which is not the case anymore for sections (each node just one section). In my understanding groups were tightly related to personas, does the change to sections mean that personas don’t exist anymore? With groups a client’s actions were managed by Client Manager personas surrounding it, and data was managed by Data Managers whose IDs were close to the data’s ID. So Sections seem to do what Data Manager personas used to but do Sections also take over the client manager responsibilties now for all their group members? In the link provided above, there are Network events mentioned that have to be voted on by the section members respectively elders, but I couldn’t find a description of what network events are, except for maybe a node joining the network or leaving it. Is an attempt to store data by a client a network event that the previously client managers, now section members respectively elders have to allow or how does the management of clients work in this section concept?


At the moment for Fleming these are network infrastructure events, like new nodes, promote, relocate, split, merge etc. When data is back in then we will again have data/client type events. These are very likely to be managed by the data manager persona’s as was, similar with node manager etc. but the infrastructure management will be the section Elders, I believe anyway at this stage. We are so Fleming focussed right now we have not committed to changing groups for data or clients in any way, but we have not discounted it either yet.


It is confusing as the meanings of the terms have evolved over time and group and section are sometimes used interchangeably.

As I understand it a section is a range of XOR addresses which is looked after by a group of nodes. Those nodes run vault software, which allows them to take on a number of personas, such as Data Manager and Client Manager, in order to carry out the various tasks relevant to the section they are looking after.

The group of nodes managing a section will always try to reach consensus on any state and action. They can also ‘group sign’ messages that travel over the wider network so that other nodes in other groups can cryptographically verify each messages and actions (such as groups forming, splitting and merging - examples of events). These group signatures are stored in data chains which are secured and held by all vaults in the group.

Nodes move from group to group by having their XOR address changed. After a number of such moves they may become elders with voting rights, having proved themselves to be reliable. @dirvine is that the correct terminology now?


Okay, thanks that helped, but I have some follow up questions.
I remember reading that only elders are listed in routing tables, I can’t find the source anymore, but in the Data chains deep dive, it says that adults and infants are only connected to their elders, so that would make sense. Does that mean that only elders can take the persona of a ClientManager or DataManager (since those personas need to be found within the network I guess)?

I know this article is somewhat old but I’d like to quote it to get some further clarification.

Within the SAFE Network the close group size is 32 with a quorum of 28 required to enable a specific action to be taken. An example may help explain this point.

Lets assume that Alice was to store a new photo. As Alice stores the image it is encrypted and broken up into chunks as part of the self encryption process and passed to a close group of Client Managers. This close group are comprised of the closest vault IDs to the users vault ID in terms of XOR distance. This is distance measured in the mathematical sense as opposed to the geographical sense. The Client managers then pass the chunks to thirty two Data Managers, chosen by the network as their IDs are closest to the IDs of the data chunk, so the chunk ID also determines it’s location on the network.

Once consensus is reached, the Data Manager passes the chunks to thirty two Data Holder Managers, who in turn pass the chunks for storage with Data Holders. If a Data Holder Manager reports that a Data Holder has gone offline, the Data Manager decides, based on rankings assigned to vaults, into which other vault to put the chunk of data. This way the chunks of data from the original file are constantly being monitored and supported to ensure the original data can be accessed and decrypted by the original user.

So is the number 32 still correct? I know that a section has on average 8-12 elders. So if my assumption above would be correct, that only elders can be DataManagers and this article quote is still valid, would that mean that data is stored in 3-4 sections?


These numbers are not fixed and the optimum section size is being experimented with, as mentioned in this thread.