One computer and Multiple Maidsafe accounts


#1

I’m a bit confused as to the situation with multiple users on the same machine using maidsafe. So far all the examples of using maidsafe have been using a single user. What happens when you have multiple users? Say you have a computer with 1 TB of space. User 1 logs in with maidsafe and uses some of that space, say 30% of it, for their maidsafe account to generate space and safecoins. Then logs off and then what? The system resets, no safecoins are generated, maidsafe shuts off? What if someone comes along and uses up all the system resources? Say user 2 comes along expecting to have 1 TB of space to play with and ends up only have 200 gb left because user 3 in the meantime came along and used up all the space to download who knows what? If user a logs off does he then stop generating safecoins until he logs back on again? Do users take turns? Like user a logs on for half an hour and generate some safe coins and has to log of and then user b would log on for an hour and generate more safecoins, then user c would only get 15 minutes and then user a would get back and have the computer for 2 hours. Clearly this could create some competition for time on the terminal when it came to safecoin mining. I guess I’m a bit fuzzy about how the maidsafe system works in relation to multiple users using the same computer.


#2

Its OK, each user may be running a farmer. The machine itself would limit the number of chunks stored. The farming will be measured on stored / lost per farmer and on Get requests. So one farmer or several per machine will still work. Many small farmers will still far like a single large one will. We will get the numbers better calculated soon.

The farmers will be working in the background in any case, unless a user specifically asks to switch it off.


#3

This discussion got me thinking - how do we prevent malicious multi-user computers? Specifically while farming.

Example:
Two immature brothers share a computer and both want to farm using it and their 1 TB drive. Brother A gets the client installed first and uses all available free space to set up his farming operation.
Brother B sees this, realizes he doesn’t have any space available and deletes the vault file from Brother A and sets up his own.
Repeat.

Now, while there is a bit of Nash equilibrium keeping either brother from farming and downgrading their node, the network is still no better off for it. Are there any plans to help mitigate this? Is it something I/we should be putting thought into or is it already figured out? Or do we think we should let this nash itself out and let people come to their own conclusions about playing nice with each other.


#4

I’m sure this is wrong. But maybe it could work this way?

100% of computer resources is used regardless of how many login accounts are created. The safecoin credit goes to whoever is logged in to their PMID, this is the vault. We have decided to call this “Farm Mode”

Example:
Bob initially sets up the computer to provide 500GB storage for farming on the Network.
The Network plants 200GB of data. Now the farming process can begin. Bob earns 2 safecoins while he is logged in.

Ted, who shares the computer with Bob and Jennifer, makes an account and logs into his PMID. He starts the farm mode. There is no need for Ted to delete any data. He instantly gets the benefit of 200GB already being planted. So he starts earning safecoins. Ted earns 2 safecoins. At this time, the Network plants an additional 100GB of data, bringing up the total to 300GB.

Jennifer, who shares the computer with Bob and Ted, makes an account and logs into her PMID. She starts the farm mode. It would be stupid for Jennifer to delete any data since it already has 300GB of farming potential. She earns 3 safecoins during her session.

This would alleviate the users deleting data. Now all that is left is for them to fight over who is using the computer for farming. Since they “share” it, they will have to sort it out with each other.

What do you think?


#5

I think this works just fine as long as someone is using the system. What about system downtime? It doesn’t farm overnight (I’m thinking office computer setting [permitted by management]). I would not want to leave my computer logged in overnight for security reasons, however, I think it should still be in farm mode overnight anyway. I know it’s still helping the network without “farming” and might seem a little selfish to want to squeeze every coin out of it I can, but it’s going to happen. I don’t think forcing someone to be logged in to get that is a good idea.

That being said, I don’t have a better solution just yet - it just seems like there’s got to be a better solution we haven’t come up with yet.

EDIT:
Possibly splitting the farming between all users with an account on the system instead?


#6

We need users to be logged into their PMID because that how the Network knows who to pay. Also, “Farm Mode” tells users it’s farming, so they understand why their bandwith is slower, or the drive is running.

I like your idea to have it automate it in the background, but it can lead to some complications. Example: if they are trying to run a graphics editor or some other high resource program, they need to free up the computer resources. If we can solve those issue, I’m all for it. For now, I like the user to be in full control.


#7

is it possible to have farm mode and consumer mode be separate things?

reasoning:
We could allow all users who want to join the terminal mining pool to (at the application layer?) sign into / sign up for a portion of the mining profits. Those are the accounts sent to the daemon that runs all the time. The users can then sign into the client to access individual personal data.
Any user on the daemon on pause if the need the bandwidth or other resources.

thoughts?


#8

This would require some changes from the way it is currently structured.

  1. We would need the Network to pay directly to a farm instead of the user account. The farm would then distribute payment to each user associate with it.

  2. We would need to disassociate the farm from the Passport. This could open vulnerabilities to hack attempts, say a hacker gains access and creates their own account in the farm.

I don’t know, this is beyond my tech level :frowning:


#9

This is OK, the vault config file will be populated with the wallet address to send safeocin to. This is of course a security consideration, but the config file itself can also be further secured. This security concerns is the same for apache severs and BTC wallets etc.

The difference will be the damage is limited. We have some options here, I will go into in another thread perhaps. The wallet address may be locked into the vault PMID identifier which is locked on the network, thereby protecting the account and owner. The damage is then limited of a DOS type attack while the config file is out of sync with the network.

This is beyond the security of apache et, all at this stage though. The network acts as a verification against a digitally secured authority to alter the wallet address then. Its very cool. Think of it as multisig for locked wallet addresses on farmers.


#10

->

I think what he’s getting at is the possibility of someone adding themselves to the farm distribution list? In which case, maybe require the consent of NofM users already on the list (like D.I.'s multisig suggestion)


#11

From my understanding of the system, here are my assumptions for my solution:

  • Files can be owned by multiple people
  • Files have a modification record (we keep old copies once the file has changed)
  • Every farmer has a unique ID

Things that would need be (possibly) be implemented:

  • Have “file change proposals” - basically a pull request
  • NofM consensus for file change pulls
  1. Every farmer has a unique ID. Any user can request to be added to any farmer instance using that ID (need a large enough keyspace that guessing / mass creating is useless [like bitcoin addresses that can be created at random without likely chance of duplicate])
  2. That request is added to the config file for that farmer as a “pull request”
  3. Once 2/3 (or some other fraction over half) agree, that request is made the new config file for the farmer.

Again, my low level understanding of the protocol just yet isn’t that great, but D.I.'s response above makes me think something like this might be possible.


#12

Haven’t had time to read all the answers so this might have been proposed already but one of the problems I saw asked about was how do we deal with users fighting over processor time AND what do you do when no one is logged onto the system? What if we created a kind of “holder” account that basically logged onto the system, farmed, and sent the safecoins to a list of users evenly. So say you have Bob, Jane, and Ted. Each farms normally when they’re online. But when no one is online this automated account basically logs in for them, uses the computer to generate safecoins and then splits the amount generated between them; so thats (amount of safecoins generated)/(number of users) = (what each user will receive) So in this scenario there are 3 users, if 3 safecoins are generated then Bob, Ted and Jane each get 1 safecoin. If one safecoin is generated then each get a third of it. This is a case where a bot is a good thing. Please note that’s all this type of account does. It doesn’t generate random data, it doesn’t perform malicious activity. It merely does what the user would do if the user were online. It simply logs in and uses the resources.


#13

Yes, we are trying to go a step further.

The idea is same as those vendor snack machines in public. If we split the (vault function) away from the (users login), then we have the same setup as a vending machine. The owner(s) need not be logged in to the Network. The vault runs in the background, and can be “paused” if the computer resources are needed.

When any of the owner(s) of the vault log in, they will just see Cha Ching! Cha Ching! safecoins in their wallet.

The issue I was concerned about is a hacker comes along and adds their wallet address to the payout list on the vault. David refers to it as the config file. It looks like it can be secured, by requiring the original owners signature when adding another payee to the list. We assume the original owner who setup the vault also owns the hard drive.


Proof of unique human
#14

Probably this remark has already been made. If another user comes, they will have a different PMID than the previous users, so the stored vault on that machine will not prove useful. [EDIT] With their PMID they will only be responsible for chunks a DataManager previously appointed to their vault/PMID.

This is why I proposed the SAFEspace browser: the owner of the machine can run his vaults, and users can simply login with their MAID. If they own a computer somewhere, they run SAFEspace at that computer with their vaults. No need to start your PMID vaults on any computer you quickly log in on.

[EDIT] Thank you Chris (@caguettaz) for correcting me.


#15

Yeah, I figured it wouldn’t work because each PMID would have a unique vault allocation of data stored.

We can still solve the multiple user sharing 1 computer situation, if the original owner who setup the vault, adds the wallet addresses of the other users, right? This is so they can receive safecoin while the vault farms.

Example situation: A group of friends or family, with little money, pull together and buy a dedicated storage drive. They would want a distribution of the safecoin farmed from it. And if we really want to get fancy, we can even include a percentage split function. Say one member is paying for the ISP 50%, while the other is paying the electricity 30% and the 3rd purchases the drive 20%.


#16

I would suggest a ‘Minimal Viable Product’ approach: when rolling out a product, start with the minimal number of features that are required to have a valued product for end-users. The question of multi signatures is easily resolved by end-users by simply having 1 collection wallet and then dividing the earned safecoins manually every month to the individual wallets.

It’s a nice idea though, and if it’s a single line of extra code, great. It rarely turns out to be simple though.


#17

If I am a end user I just need my SAFEspace, and I want to access from different machines when i need.
As a farmer I want “always on” machine running SAFEfarm. One PC can run one SAFEfarm with one address.
End user is not necessarily a farmer, and farmer will have his SAFEspace account apart of his farm.

Is this correct or I am missing something?


#18

Correct :wink:


#19

If mining safecoin is seperate from your safespace then isn’t that unfair to multiple users that might use the terminal? If youre the owner of the terminal you set up the safefarm and have it running all the time, get all the safecoin, regarless of who or how long anyone else uses the terminal. But isn’t one of the major points of maidsafe to reward people for using it? How does it reward people for using it if someone else is getting the safecoins?


#20

The point is to reward people for contributing resourses to the network. You’ll be able to have a pretty potent account for free, but whoever is running the node on his/her own computer is the one who is actually contributing, and thus should get the reward.