Names for non-immutable data (ie sequences / maps, do we have a catchall name for these?) are current set randomly by the client (see sn_api/safe_client L249 and L427) which means clients can pick any name they want.
This seems potentially dangerous and unnecessary, since we can end up with a lot of data permanently in a very tight group at any particular part of the network, which would be much more difficult / expensive to do using immutable data (see data density).
It seems like we have a pretty simple way to set the name safely and automatically:
Use the hash of a random bls publickey+signature (eg add a locationProof
field here, and the address is the hash of that field). This means the name is unpredictable, verifiable, evenly distributed. The name can come from any random publickey but must have a matching signature for some constant predefined message (eg [1u8; 32]). A name can be chosen without any network interaction (just like immutable data). But the name ends up being well spread out across the network.
To create dense data an attacker would have to iterate over many public keys + signatures to find results that all end up close to each other. The similar technique for immutable data would be to iterate over many random blocks of data to find results that end up close to each other. Generating a name using a bls signature takes about the same time as generating a name by hashing 1 MiB of immutable data (see stats in bls performance).
The downside is it adds extra data to the object (144 bytes = 96 byte signature + 48 byte public key, the const message data can be excluded).
Should we use something like this to name non-immutable data or keep random names? Any issues with doing it this particular way or is there a better way to approach it?