yes but as we discussed in other topics your available data depends on how much you contribute to the network via how many safecoins and how much of a farmer rank you can generate. Using your model basically if you don’t own the machine you’re stuck with a free account and can’t increase your data storage.
Say for example one’s only access to the maidsafe network is via a public terminal and one doesn’t have any money for safecoins. how is one supposed to generate a farm rank in your system? They don’t own the machine and in your system the machine owner gets the safecoins. Therefore a user that doesn’t own the machine can’t gain farm rank. And they can’t buy safecoins either they cain’t increase their NS or NSL no matter HOW MUCH they use the system.
Your system basically discourages using maidsafe for use in public access points.
The whole point of “farm rank” is that you are contributing some sort of resource to the network, i.e., actually managing some stored data and routing for the network. Even if it is minimal, in which case you’d have some sort of farm ran-- like from a smartphone or the like. If you didn’t have money for safecoin or a computer, etc., yet you could really use more than the free account (which may end up being a pretty generous allocation), it would be relatively easy to appeal for a donation of safecoin from someone for that purpose.
We’ll see how it finally gets worked out, but farming safecoin has to be as a result of supporting the network in some way, not just using it.
I’m not sure why that would discourage someone from using the system from a public access point.
you get rewarded for contributing resources. The equivalent question is ‘why does the farmer get paid for his harvest, while I’m the one eating the vegetables?’ By decoupling are giving everyone free food, but the rewards for the farmer still have to be collected through the increased value of safecoin and eg a small transaction fee on services outside of SAFE, paid in safecoin.
Sorry if this is slightly off-topic, but I believe the following is fairly important in order to reason properly about farming:
PMIDs do not store chunks that are close to them in the address space. A chunk’s address determines which DataManagers are responsible for it. These DataManagers are free to select the four or more PMIDs which will actually store the chunk according to whichever criteria they like.
I don’t believe these criteria have been set in stone yet (@dirvine may correct me if I’m wrong), and I’ve not read that part of the code, but based on my recollection of past discussions I believe these criteria are a mix of:
Node reliability: reliable nodes will get picked over unreliable nodes for storage.
Available space.
Geographic diversity: the network tries to guess how far away two nodes are using ping, are tries to ‘diversify its portfolio’ by storing copies of the same chunks at separate locations.
The consequence for farming is this: just because you’re running a PMID doesn’t mean it’ll get (or hang on to) chunks to store and mine from. If your node is too unreliable, it’ll get passed over by the network.
And even if it manages to store some chunks, it will lose them if it stays offline for too long: the DataManagers responsible for its chunks will distribute the chunks to other nodes. When your node comes back online, it’ll become a fallback solution and will only be eligible for GETs (are therefore mining attempts) if and when a node holding one of its chunks goes offline.
That’s bad for people wanting to run part-time farmers, but that makes a lot of sense from a network health perspective: we want to make sure that chunks don’t disappear, and we want to minimize the cost of self-healing from churn.
Thank you for setting me straight on this one ! I did get this one messed up! I knew the consensus chain went over NodeManagers, DataManagers and PMIDManagers, but I did get it wrong. The datamanagers are closest to the chunk hash and are responsible for managing the data, yes.
Any idea how DataManagers then discover or select a PMID? Do the DataManagers need to reach consensus over which PMIDs they choose, or does every DM simply pick one at best effort. Is there a reason why he should not just always pick his own PMID, to increase his chance of farming (negligibly arguably)?
Also which ID is assigned to a DataManager in order to determine his distance to a DataName/chunk?
No problem!
My guess would be that the DHT paper mislead you - it’s an interesting read, but the system seems to have changed a lot since some of the papers available on Github were written.
I’ve not read this part of the code yet, so all I can offer is guesswork. I would imagine that PMID selection happens by consensus, as that doesn’t seem to hard to do. I’ll continue reading the code, and get back to you when I know the answer… unless someone more qualified wants to chime in of course. [EDIT: Someone more qualified has chimed in, see below.]
Again, guesswork. I think each vault has an address that is shared by its different personas. If this is correct then the DataManager’s address (its ID) is the vault’s address, which should be negotiated with the network when the vault first connects.
So really, when you’re running a full (i.e. non-client) node, you have one 512-bit network address that can provide several services to the network (managing MAIDs, managing Data, storing data…) via its different ‘personas’.
The alternative would be to have each persona use a different address, but this seems to me like an inferior solution any way you look at it.
Since addresses are assigned when nodes connect to the network, a disconnected node that rejoins the network will find itself responsible for different MAIDs and chunks every time, respectively via its MaidManager and DataManager personas.
It will, however, still hold the chunks that it was storing (as a PMID), and will announce this fact to the corresponding DataManagers, so that if the disconnect was short enough, no data movement is necessary.
This assumes that node addresses distributed by the network change from one connection attempt to the next, although I’m not completely sure this is/will be the case. What I’ve gathered so far is that at least until recently, clients alone were responsible for picking an address. Of course, you can imagine that being able to pick any address would be preeeetty bad for the network, so what joining nodes had to do was provide an address as well as a piece of data that hashes into this address.
This made it crypto-hard to pick any specific address, but falling into a sufficiently large address range could be brute-forced easily. That was still terrible, since large parts of MaidSafe rely on the fact that you shouldn’t be able to pick your neighbors in the address space.
So the idea was to have the network participate in address assignment. I don’t know how exactly, so it’d be great if someone from the company could enlighten us. But I’m guessing this process will yield addresses that depend on the network’s current state, so that two subsequent attempts will yield different results.
Anyway, the code knows all the answers, and will tell us if we take the time to listen. So I’m diving back in. Cheers!
Currently the DM’s select a PMID each. saves 4 copies. As the live count drops to 2 they all store again to a new node (6 stored). This process continues (2 ↔ 6 live copies, several (16) dead copies).
Since farming is now introduced this will change (testnet2 hopefully) where the DM will combine with the PMID Managers. They will store locally in the routing matrix (up to theoretical 64 nodes, most likely a group of 16) and use a similar mechanism to store except keep 2 chunks alive. These will be chained (consensus chains) with a chain of three sets per chunk (so H(chunk) and H(H(chunk) etc…). This means data will be then closish to the hash and the hash of the hash etc.
This is the reason we will drop all data from testnet1, it is a lot of refactor in the core code, so we will be a busy with this one, but will significantly speed up the put and get process.
The DM is just a node so gets the id assigned, currently the hash of his public key plus signature (signature is the ANPMID). This will also alter in testnet3 to include a positioning key, this key will alter the address to prevent off line attacks (where an attacker can create millions of key pairs and passport packets to try and get a group together).
We are looking for some core code help if you are up for that and able to read the code. Vaults is a nightmare, so we can help you through those parts. It’s gonna change a good wee bit, but you will see the patterns used. sync, acc xfer and accumulator are mind bending, so what looks obvious is not really, there is elements there for a huge amount of edge cases (nodes churn at any time and any number of them etc.)
If you have time and inclination then please let us know, we are all hands at the moment and are really getting pulled in many directions (I am off the rest of the week in Amsterdam etc.) so any help will get the nets up faster if you are up for it.
We will have pivotal tracker tasks to make engagement easier.
Thanks David for this answer. I’m going to try and rephrase this to make sure I’ve understood:
Before farming, we could trust individual DataManagers to pick PMIDs on their own, and that’s what the code currently does. But now, being a PMID is advantageous, so a healthy dose of mistrust needs to be introduced in the design.
So now there’s a consensus method for picking PMIDs. Data Managers (which now include the responsibility of PMID Managers) pick PMIDs among nodes in their routing matrix, which they share.
And (I’m really not sure I got this part right) which PMIDs they pick among their routing matrix is whichever node is closest to H(chunk) for the first, H(H(chunk)) for the second and so on…
Is that more or less on track?
Ok so it looks I was dead wrong on this one. This means each vault persona is actually a separate node with its own address, doesn’t it?
Right now I’m mostly reading the code in a bottom-up way, and @benjaminbollen and I are trying to synchronize to write a bit of documentation to ease others into the code.
But if you think I can be of help, just give me pointers and I’ll see what I can do!
I am jumping on a plane now, I know were are looking to try and get some people in the office and also working on the field. I will post to the guys to progress this if that’s OK. Thanks folks all this is amazing and we will make sure everyone is rewarded somehow. Fantastic.
All personas use the node address. I added confusion there, sorry about that.