Why wouldn't app developers stuff their GET requests?

Development
41

If all of the developers made 1000 movie getting applications, then they would likely overlap data, targeting the same files all the time would enter into cache the most watched or loaded movies. So when this happens the applications will no longer gain Safecoin from those get requests to the same applications. So then 1000 applications will eventually have near zero returns in terms of Safecoins, and quickly reach that zero point everytime someone gets some new unique movie for the first serveral times.

So then the developers will now have no choice but to look for new applications to new forms of data on the network. The getting of data firmly relies on the putting of data: someone had to spend safecoin to get the data there first.

This leads to developers or people need to form a demand for new application for which they can use their safecoin to PUT different kinds of data.

So, all developers will stuff their applications with GET requests. Definitely.

based on maidsafe.net/safecoin chart I think this is a close guess to how much 400k GET requests to a forum could calculate to in safecoins per month from a forum application.

It seems more realistic with a figure like this. And makes a good perspective, remember that a forum wouldnt have all of the range of features of every application available, although it could., and just like any other application that hits a mark on utility.

2 Likes
42

But if two people GET each other’s app data and keep quiet, no one would know.

And one shouldn’t host secret government data on a DIY mail server, but she does. People are doing what is in their economic interest. Politicians lie and steal if need be. I don’t think it would work out if the system was game-able and relied on honestly of anonymous participants.

How many GETs in one PUT? If n, the. I need to PUT a huge file and GET it n+1 times.

Correct. The trick is to wait 1 second longer than that period before a new GET request is issued.

You may very well be right, that’s why I would run hundreds or thousands of them as long as I make more than I spend doing that.

If a regular person can create apps and game the system to just slightly improve his monthly SAFE income, we should consider the possibility that thousands such apps will run 24x7.

1 Like
43

I’m not sure that is possible because you don’t know what that period is, maybe file cahced never goes out of cache for 20 years…

the rest,… yes okay but look at the calculation,… all that conspiracy and activity will net you a few hundred coins here and there, and maybe you get a gold medal for demonstrating automatic payment methods…

and a few hundred safecoin is your prize, though remember that as does the network expand into the 20th year etc… the number of gets can increase exponentially and then these applications which will run 24x7 will only grant you 1 safecoin per year or 1 safecoin per month since your gets will be so scarcely producing gets in comparison to the scale of the network. Imagine you would need to do a petabyte of unique get request worth of data to generate 1 safecoin, … do you have some petabyte worth of data laying around youll PUT into the network just to auto get it later for your safecoin back?

and how many several times you need to auto get your petabyte and to pull it to where? etc etc etc… and consider that the model there scales with data capacity and data consumption. and remember the app reward is 1/7th of the farming reward…

2 Likes
44

I think caution should be the first thought with app GET payments. The network does not need them to function and it could cause issues.

Maybe get v1 out there and then experiment with this stuff on test nets later?

4 Likes
45

Safe Network most certainly needs GET requests because that is how it retrieves data from itself.

1 Like
46

I mean the app reward concept, not the payment for retrieving data to the network (and rewarding farmers). I don’t think there is any issue with paying farmers (via the network) to give you data - it is the rewards allocated to the developer/artist etc that has potential to be gamed.

5 Likes
47

+1.0.
I wanted to say this myself, but I got enough heat for the idea to discuss introduction of coin functionality for v1.1.

One alternative to not rewarding app owners for GETs is to let them charge their users on their own, but from the very beginning the plan was to reward app vendors, so another (non-gameable) way would have to be found which wouldn’t be easy.

I know, but maybe it be prudent to spend a bit more time on coin implementation and related audits (security, economics). This is one way to cheat, but there may be more than just one.

1 Like
48

I agree this is an issue that deserves thought and experiment. There’s no doubt there will be ways to game SAFEnetwork, no system is immune to that, so what we need to achieve is making sure the various types of gaming that does happen is tolerable.

I think that we need to continue to work hard to find ways of providing app (and content) rewards, and other network growth incentives, that create more benefit than cost. If we can’t, we can always remove them.

We shouldn’t give up too early - the only way I know to solve hard problems is to keep working in them and not give up. Discussion is part of that, then analysis, then experiment, often failure, then repeat.

2 Likes
49

Most post begins with the assumption that the user does not consider the data consumed by an App. This can occur in the developed world, where flat rates are common, but there are billions of people who pay per use. Even this pay per use is still common in mobiles data almost everyone. For these people an App which consume more data costs money.

As discover data consumption of an App is not difficult, in the end the developer will have to choose. Or not trick the App, and could have many users and a good reputation, or trick the App, and will have less users and worst reputation.

My impression is that act honestly will be more profitable than trying to cheat their customers.

3 Likes
50

Also having a plugin in the background that would report this data usage would enhance the visibility of this threat.

But I believe that type of plugin would only gain momentum and popularity once one or two of these malicious APPs are exposed and reported on. In fact, I would not be at all surprised if an APP of this sort started out as a debugging tool initially.

1 Like
51

I think it should be a basic feature of the safe launcher. I don’t know what are the plans but having usage statistics of all app that connect through the safe launcher is very important.

4 Likes
52

I’ve still not yet been able to wrap my head around what all is parsed by the launcher, but in addition to this one there are a few other - what I believe to be - common sense plugins that should be able to be implemented therein.

While the launcher should indeed be able to monitor these types of statistics and influence certain types of the network’s behavior, the presentation thereof to the user should be based on their individual preferences. I would be very surprised if there didn’t evolve different flavors of default setups, much like there are various Linux distros that are targeted towards different use cases.

3 Likes
53

Where are you getting these numbers?

0.000430837% of 430 million?

What? You clearly must mean 4.3 BILLION, as in the 2^32 possible safecoins that will ever exist.

I have no idea what the other numbers are.

Futhermore I don’t understnand why you’re equating 400k page views to 400k chunk requests.

They’re not the same thing.

The total number of GET requests on that 400k page views is really: (400k page views) * (the average page size in mb).

Because each chunk is 1mb of data.

Every successful farming request earns you 1 safecoin.

The farm request is divided like so:

  • 10% chance to core devs
  • 20% chance to the app developer
  • 70% chance to farmers

Let’s say my app is making 100,000 farmable GETs a year in the 2nd year of the network. Using the chart on the page you mentioned I know that 20% of safecoins exist, so there is an 80% chance the new safecoin does not already exist.

My chance at earning a farm reward (and thus a safecoin) would be:

(100,000 farmable GETs) * (20% chance for app developer reward) * (80% chance the safecoin has not already been created) = Number of safecoins rewarded per year

100000 * 0.2 * 0.8 = 16,0000 safecoins rewarded per year

At only 100,000 farmable GETs a year that seems significant.

And that’s in a whole year from probably only 5,000 users (and even that is on the high end I think - at that number of users each user only has 20 farmable GETs in a whole year).

If an app had 100,000 USERS, or 1M+? The reward seems pretty significant.

1 Like
54

That is not correct.

There is a so-called lottery system. So the issuance of any safe coin is on a lottery. Not sure how the core devs are done so I will leave it out.

  • The system determines the Average chance of any one successful GET getting a coin for the farmer.
  • The system determines the Average chance of any one successful GET getting a coin for the APP dev
  • The system determines the Average chance of any one successful GET getting a coin for the producer/uploader

The system rewards each independently of each other and they do not change the rate any is rewarded. The farmer reward is not affected by any of the other rewards

Initially the app dev might get 2/10 the average the farmer gets, but the amount the app dev gets will not change the amount the framers get. That is the farmer gets the same whether an APP dev is involved or not

1 Like
55

I thought it was 90% farmers 10% developer of the app

56

Nope they are independent rewards. App dev rewards do not reduce farmer rewards.

Just initially the maths behind the rewards will average at devs getting one rate compared to farming rate. But one is not reduced by the other. approx 1 to 10 or is it 2 to 10

Its not like a purse where a coin is taken out and given to one of the reward streams on a GET that “wins the lottery”. But rather the framer lottery asks for a coin and the network pays/not pays according to the farming rate. And then the app lottery asks the network and it pays/not pays without consideration of what happens to the farmer lottery

Lottery is one of the terms used to describe how the rates are handled with an indivisible coin and the rate is less than a coin per get

1 Like
57

How does it matter in practice, compared to Backseat’s model?

1 Like
58

Just correcting that point. Otherwise its a reducing series, rather than independent series. Might not matter now but it might matter when he considers other things, so why not get it right first time. Thats all.

2 Likes
59

From the RFC Farm attempt:

Rate attempts

1.PmidNodes -> tested at 100% of FR [i.e. Farming rate * 1]
2.App Developer -> tested at 10% of FR [i.e. Farming rate * 1.1]
3.Publisher -> tested at 10% of FR [i.e. Farming rate * 1.1]
4.Core development -> tested at 5% of FR [i.e. Farming rate * 1.05]

Payment address

1.PmidNodes -> Registers an Optional (if set by user) wallet address on any store of data to it
2.App Developer -> App developers will include wallet address in any Get request
3.Publisher -> As data is stored a wallet address of the owner is stored if this is first time seen on the network (stored in DM account for the data element)
4.Core development -> Initially every node will be aware of a hard coded wallet address for core development. This will likely lead to a multisig wallet.

Farm process

When the initial farming test above is true (the modulo division ==0 ) then the DataManagers send a Farm request message Post to the group closest to the combined Hash (i.e. Hash of (ImmutableData + PmidHolder)). This request includes the original hashes + hash of chunk requested +current farming rate of the group as well as wallet address. This is confirmed at the receiving group and they check for the existence of a safecoin space (ie, there is no safecoin with this name). If this is successful then a further check is made to confirm there is a DataManager group (implicit as routing does this). A safecoin is then created and a message sent to the wallet holder of the request. All these requests must be digitally signed and confirmed at receiving end (implicit in sentnel).

1 Like
60

Thank you @neo I clearly must read more into it.

And thanks @digipl for citing the resource.

When you say “App dev rewards do not reduce farmer rewards”, you mean by CHANCE, right? So the app dev chance does not effect the farmer’s chance?

Because as a new safecoin address is taken it still reduces the overall probability of reward for everyone, right?

[quote=“neo, post:56, topic:5563”]
Just initially the maths behind the rewards will average at devs getting one rate compared to farming rate. But one is not reduced by the other.[/quote]

Would you please expand on that for me? I’m not sure what you mean by “initially” (because of programmed logic, or because of network size?) and how you mean the maths will average.

Edit:

Why is each reward chance given a magic number to change the probability in terms of farming rate? (why not just increase the % chance against the farming rate itself?)