Question regarding message holding and swarms

[Sepero]

Unfortunately (or fortunately?) I do not have a bug to report today. I'm simply seeking a definitive answer to a question that I cannot seem to find an answer for.

Lokinet Service Nodes will hold messages for up to 14 days. For redundancy and verification, a message sent will be held by a "swarm". According to the initial white paper, each swarm is a collective of 9 Service Nodes. The assignment of a user to a swarm is automatic and based on identifier of the user.

Assuming all of that is correct.

• Are Lokinet swarms still 9 Service Nodes, or has the number changed? (I read someone mention it was 5 to 7?)
• Does a user ever change between Service Node swarms? (Messages are stored on swarm X now, and swam Y later, to prevent all messages always passing through the same Service Nodes?)
• If swarms are periodically changed, what is the time frame (or other criteria) for this change?

[jagerman]

This is a little bit off-topic: Lokinet itself is responsible for packet routing, not storage (storage and storage swarms happen entirely in https://github.com/oxen-io/oxen-storage-server).

However, to answer your questions:

Service Nodes will hold messages for up to 14 days.

This is true for public (i.e. incoming) messages. It is also possible to store encrypted data for yourself (i.e. in your own swarm, in your own account) for up to 30 days, in various non-public "namespaces" within your storage location. This is mainly used for encrypted configuration messages that are used to synchronize settings across devices.

Are Lokinet swarms still 9 Service Nodes, or has the number changed? (I read someone mention it was 5 to 7?)

Swarms are dynamic, depending on the size of the service node network. The precise logic is complicated, but the high-level overview is that new swarms get created when existing swarms are too full, and get collapsed when they are too sparse. Currently there are 306 swarms across 2138 service nodes. The minimum number of nodes in a swarm is 5, and the maximum is 10, with an average of 7.

Expansion generally happens once the average service node to swarm ratio across the network rises above 7.

As service node counts drop, the swarms thin out by transferring a node from one swarm to another (e.g. if that other swarm would drop below 5); if there are no excess nodes at all (i.e. every swarm is at 5, and someone leaves), then two swarms will be merged together, to form a larger swarm of up to 10 nodes.

Does a user ever change between Service Node swarms? (Messages are stored on swarm X now, and swam Y later, to prevent all messages always passing through the same Service Nodes?)

Yes, this can happen in a couple of ways: the swarm space could get split by a new swarm being introduced "near" the user, or by the user's swarm getting collapsed and joined into a nearby swarm.

To depict this, its necessary to consider what "near" means: essentially you take a session pubkey and reduce it to a 64-bit integer, then you consider the swarm IDs (which are also 64 bit integers) and then that Session account goes to the closest swarm. For example:

...---A---------------------------B--------------------------C---...
                       S

where the S indicates your Session ID's swarm location value. Since it is closest to B's swarm ID, that's where S's messages belong.

As for a change in swarm, the two scenarios are a new swarm entering: the new swarm gets positioned by dividing the largest free space (and the first free space in the event of ties). Let's suppose that means a new swarm D gets created at the midpoint between A and B:

...---A-------------D-------------B--------------------------C---...
                       S

now S belongs to the D swarm.

For swarm collapse, suppose (starting from the original example) B gets disbanded, then it looks like this:

...---A------------------------------------------------------C---...
                       S

and S now belongs to swarm A.

When these transitions happen, affected stored messages gets transferred from the existing swarms into the appropriate place: in the adding-D case, some messages would transfer from A and some from B; in the dropping-B example, some of B's messages would transfers to A and some to C.

If swarms are periodically changed, what is the time frame (or other criteria) for this change?

There isn't a defined periodic change: swarm changes only happen as a result of nodes joining or leaving the network, and even then the change is localized to session IDs that are closest to the affected swarms. (So, for instance, someone with a Session ID just to the right of C wouldn't be affected at all by the changes I described in the examples above).