Network supporter reward

wilsonk commented

2017-11-20 17:55:27 +01:00

(Migrated from github.com)

The Issue

We need some changes to the app to pick up the new 'supporter' reward once it is finalized. I am not exactly sure what changes are needed, but wanted to get the ball rolling on this here, so that others can chime in.

## The Issue We need some changes to the app to pick up the new 'supporter' reward once it is finalized. I am not exactly sure what changes are needed, but wanted to get the ball rolling on this here, so that others can chime in.

tzarebczan commented

2017-11-20 18:30:41 +01:00

(Migrated from github.com)

@wilsonk can you give us an overview of how the API will determine who is qualified for this reward?

wilsonk commented

2017-11-20 18:52:19 +01:00

(Migrated from github.com)

@tzarebczan Yes, you bet. The network support reward is determined by API accesses over a four week period.

If you have 5 or more accesses in the last week, then you start out at a 1 LBC reward, this continues to escalate to a maximum of 4 LBC if you continue to support the network over the upcoming 3 weeks. You will continue to receive 4 LBC every week that you access the API 5 or more times once you reach this level.

If you do not access the API 5 or more times in any given week, then the reward resets to 1 LBC and you must continue to access the API 5 or more times per week for 4 more continuous weeks again.

So basically you need continuous support to increase rewards, otherwise you will restart from the lowest support level if you miss a week.

Please let me know if this is unclear in any way.

@tzarebczan Yes, you bet. The network support reward is determined by API accesses over a four week period. If you have 5 or more accesses in the last week, then you start out at a 1 LBC reward, this continues to escalate to a maximum of 4 LBC if you continue to support the network over the upcoming 3 weeks. You will continue to receive 4 LBC every week that you access the API 5 or more times once you reach this level. If you do not access the API 5 or more times in any given week, then the reward resets to 1 LBC and you must continue to access the API 5 or more times per week for 4 more continuous weeks again. So basically you need continuous support to increase rewards, otherwise you will restart from the lowest support level if you miss a week. Please let me know if this is unclear in any way.

tzarebczan commented

2017-11-20 19:20:11 +01:00

(Migrated from github.com)

That makes sense to me in terms of the mechanism and reward structure. Does the "API access" mean the user will have an entry in the access API table? Does the user need to have "Share Diagnostic Data" turned on for this to work?

wilsonk commented

2017-11-21 00:10:53 +01:00

(Migrated from github.com)

Yes the user will have an entry in the access table. I am not sure whether the "Share Diagnostic Data" needs to be turned on. Perhaps @lyoshenka would know?

lyoshenka commented

2017-11-21 03:41:05 +01:00

(Migrated from github.com)

"Share Diagnostic Data" does not affect internal apis

tzarebczan commented

2017-12-14 23:11:39 +01:00

(Migrated from github.com)

Related to https://github.com/lbryio/lbry-app/issues/871

tiger5226 commented

2018-05-21 04:41:51 +02:00

(Migrated from github.com)

We should keep this generic so that there can be a category of LBRYNet rewards for network participation. Every user of LBRYNet is assigned a randomly generated node_id. This id can be linked to our already anonymous/unique auth_token for rewards. In our current rewards system, if these two are linked we can present additional rewards for network participation. Once we have the node_id linked to the auth_token we can ping, ensure certain files being made available, when they are available, how often etc.

We can pass the node_id when claiming rewards. The first reward they claim will link their auth_token with the node_id which will then list new rewards for network participation.

We should keep this generic so that there can be a category of LBRYNet rewards for network participation. Every user of LBRYNet is assigned a randomly generated `node_id`. This id can be linked to our already anonymous/unique `auth_token` for rewards. In our current rewards system, if these two are linked we can present additional rewards for network participation. Once we have the `node_id` linked to the `auth_token` we can ping, ensure certain files being made available, when they are available, how often etc. We can pass the `node_id` when claiming rewards. The first reward they claim will link their `auth_token` with the `node_id` which will then list new rewards for network participation.

tzarebczan commented

2018-05-25 18:53:25 +02:00

(Migrated from github.com)

@tiger5226 should this be happening in lbrynet as opposed to lbry-app? What if someone is running the daemon to host content without running the app?

tiger5226 commented

2018-05-25 19:18:02 +02:00

(Migrated from github.com)

Good question. I think our target for these rewards is to spread the content out so it is always available. This means users of the app seeing it and downloading it, get a reward for keeping it locally and available. I don't see why someone would run LBRYNet outside of the app, for non-commercial reasons.

In summary I think their are two categories here, users getting rewarded and then network participants that want to be rewarded for seeding content generally. I think the latter should be a different scheme. I was actually looking into building a webapp that can be cloned in a way where people can get paid to host/seed content. So if they want to be a seeder they can deploy the web app. For example, users can choose bandwidth allotment, and pay LBC weekly to keep it up so they don't have to have their computer up and running. I know we do that ourselves free of charge for some content creators but it would be nice if an individual could be able to do this at will, if they pay for it. Options Options Options. From some recent tests, a good number of claims are not downloadable because the owner is not online or there are not enough peers online at the time.

This is just my view and opinion.

Good question. I think our target for these rewards is to spread the content out so it is always available. This means users of the app seeing it and downloading it, get a reward for keeping it locally and available. I don't see why someone would run LBRYNet outside of the app, for non-commercial reasons. In summary I think their are two categories here, users getting rewarded and then network participants that want to be rewarded for seeding content generally. I think the latter should be a different scheme. I was actually looking into building a webapp that can be cloned in a way where people can get paid to host/seed content. So if they want to be a seeder they can deploy the web app. For example, users can choose bandwidth allotment, and pay LBC weekly to keep it up so they don't have to have their computer up and running. I know we do that ourselves free of charge for some content creators but it would be nice if an individual could be able to do this at will, if they pay for it. Options Options Options. From some recent tests, a good number of claims are not downloadable because the owner is not online or there are not enough peers online at the time. This is just my view and opinion.

tiger5226 commented

2018-06-11 04:07:48 +02:00

(Migrated from github.com)

@seanyesmunt Do you think it is an easy thing to pass the node_id to internal_apis? Just getting this information there opens up a lot of possibilities for network participation rewards for our users.

@seanyesmunt Do you think it is an easy thing to pass the `node_id` to internal_apis? Just getting this information there opens up a lot of possibilities for network participation rewards for our users.

tiger5226 commented

2018-07-07 15:30:43 +02:00

(Migrated from github.com)

The node_id is not viable per @lyoshenka due to privacy/security concerns. The storing of this information has been rolled back.

The `node_id` is not viable per @lyoshenka due to privacy/security concerns. The storing of this information has been rolled back.

neb-b commented

2018-07-09 05:36:56 +02:00

(Migrated from github.com)

Any ideas on what we can use instead? What were the concerns?

tiger5226 commented

2018-07-09 06:45:12 +02:00

(Migrated from github.com)

I don't really know the specifics, as I have not had the opportunity to discuss this with @lyoshenka yet.

As far as alternative ids, there is no other generic way of linking a verified user to their participation in LBRYNet. We would have to get the information we need app side and pass it across. Below would be some information:

Available file information such as claimid,outpoint. This is so we can determine GB Hosted, targeted rewardable files.
Uptime ping to iAPIs so we can determine contribution time. We should know how available their files are as part of supporting the network.

This information is available from the app via its connection with the daemon.

I don't really know the specifics, as I have not had the opportunity to discuss this with @lyoshenka yet. As far as alternative ids, there is no other generic way of linking a verified user to their participation in LBRYNet. We would have to get the information we need app side and pass it across. Below would be some information: - Available file information such as claimid,outpoint. This is so we can determine GB Hosted, targeted rewardable files. - Uptime ping to iAPIs so we can determine contribution time. We should know how available their files are as part of supporting the network. This information is available from the app via its connection with the daemon.

lyoshenka commented

2018-09-11 22:46:48 +02:00

(Migrated from github.com)

the real solution to this is data payments from users to hosts

karolyi commented

2021-08-08 15:39:03 +02:00

(Migrated from github.com)

does this issue have another referenced issue (maybe a checklist to be solved in the future) somewhere? I currently host 50GB videos on my 1GB fiberglass connection as a 'reflector' with my lbry desktop client. it would be nice to get some rewards for it, as an incentive.

karolyi commented

2021-08-08 15:41:14 +02:00

(Migrated from github.com)

I also looked into the "Reflectors and Data Markets" part of the spec but it neither seems to be working, nor implemented.

I also looked into the "Reflectors and Data Markets" part of the [spec](https://lbry.tech/spec#metadata) but it neither seems to be working, nor implemented.

Rows
Columns

Network supporter reward #761

The Issue