That was always the plan. Anyone remember developer pods?
1/3 of the crowdfund was to go there, had it all gone to plan.
5 Likes
This is meant to actually go beyond that where voluntary tipping is also included in this, forums/blogs/etc would benefit and they donāt fit the PTD or PTP since forums are using other peopleās APPs. Also the power is in the hands of the user to tip/pay these people. Also its not limited to any specific purpose. Also it doesnāt go against anything you would have to submit to the authorities as far as I can see since it is voluntary donations/payments.
And its voluntary.
Youtubers have their patreon/paypal links and this would replace that and also they could suggest a tip for their video. It is really a wide ranging feature in my opinion (of course LOL)
Plus it should be real easy to implement since the node code is just storing 2 values in the meta data and returning said values when retrieving the chunks. And the client code has a subroutine that handles paying with of course the hard part of a UI to set parameters and cli command.
Thus you could perhaps implement it after launch, or even put hooks in the code prior so that the flow is there without the code. And maybe someone else can add the code in a PR
But relieves the next year or few for the foundation where it handles a much smaller number (maybe 1% or even 0.01%) of payments to APP devs manually.
Very much agree and that was my suggestion 
And being so simple (relative term LOL) could be used as the first stage to all the payments done by the network but even if that cannot happen this is a powerful addition to not only relieve foundation some/much work but also open up the automatic tipping that many people have wanted
4 Likes
From time to time Iāve thought about a Pt* method that might work in a simple manner, one that doesnāt require ledgers or keeping track of section wallets etc. Instead it relies on the collective action of different roles (nodes and clients) to yield an emergent behavior (@dirvine).
One concept that arose was the situation where every action within the safe network requires a payment of some kind, while that action also receives a reward of some kind. I suppose you could call this a form of āstakingā on a grand scale. A simple example is the following:
A) Content Providers and app devs pay to put, which is given to node operators.
B) Clients pay to get, which is also given to node operators.
C) Node Operators pay to play, which is given back to app devs, content providers, and clients, etc.
Some would-be emergent properties:
-
On average it is āfreeā for Clients to download/view content. Payments to the network for gets would be offset by rewards clients receive to either be net zero or provide a small incentive. Clients could then use any net positive incentive they receive to use for future puts.
-
Content Providers simply pay to put chunks on the network. If these chunks are public and popular, then they may receive a reward in the future. When putting public content, users can opt out of receiving PtP rewards.
-
App developers pay to put their apps like content providers do, but they also receive additional rewards because chunks uploaded or downloaded by an app could have an app signature associated with them.
-
Node operators would receive both āpay on putā (PoP) rewards and āpay on getā (PoG) rewards. Node operators would also need to continually pay rewards to clients (PtC), devs (PtD), and content providers (PtP) to stay on the network, making some attacks more difficult. The net effect would be that node operators receive a net positive income. This also allows node operators to monitor the rate of gets vs puts when determining their put charges or get rewards.
Other thoughts:
-
Rules governing the behavior of nodes would also check to make sure they have correctly sent payments based on the chunks they are serving and the role they are playing.
-
Each new client account created would come with a small amount of SNT so that the client could initiate gets and puts. Clients would need to do a proof of work of some kind when creating a new account to ensure the procedure was not abused.
-
The process of having the Foundation transfer funds to the network is now simplified. All it needs to do is upload vast amounts of public information, pay for the puts, but choose not to receive PtP rewards. From that point on the network would take care of the rest.
TLDR; Everyone gives, everyone receives, everyone safe with a new internet.
8 Likes
Iāve been chewing this over recently also. And similar to what you suggest (I think). It could be entirely possible to bake in some user preference here.
My rough idea so far: We could cache the last X GET addresses at all nodes (we may well be caching popular content anyway), and they could provide a list and a requirement to pay % to some of them before accepting data-payment (ie, instead of or as well as royalty fees). That list could be filtered by users preferences eg too. (Defaulting to some foundation based suggestions perhaps). So a halfway house of PtU/Patreon to some degree.
Itās not super well thought out, but it seems like, assuming a cache exists, itād be very possible.
6 Likes
Do you mean that when uploading, a client gets a list of popular chunks and must pay uploaders of N them before paying the node receiving the uploaded chunk?
If so, it would be good to understand how likely a given chunk is to āreceiveā a reward. I imagine it will be only a small, very popular set of chunks that spend much time in cache, so my make rewards quite concentrated. Question is how concentrated.
Iād always envisaged rewards being very small but very widely spread, so anyone has a chance of earning but getting rich, not so much.
Too concentrated and you reduce the opportunity for all but a few uploaders, and also create an incentive to target and monopolise rewards (eg by getting your own chunks).
What you describe sounds attractive in its simplicity and efficiency. So might be worth trying out, or at least modelling the distribution of rewards.
2 Likes
Would be fun if every web request or download cost 1 nano, itās close to Davidās free
- Nice demo of SAFE payment rails
- Constant requests constant payments
- Content creators no longer have to beg online, add ads or promote companies they
, populair content? receive direct money to create more - No more freeloaders, whining over SAFE content without contributing
- Nudge to start farming some nanos
- Pressure! If you donāt put your content on SAFE first, someone else will and guess who gets paid?
- or instead of 1 nano name your nanos
- Payment as ddos prevention even though we have ddos prevention alreadyā¦
2 Likes
An interesting concept and assuming all* (*most) are well behaved nodes then it would work in theory. Maybe a splitting of payments to the foundation. x% to foundation for its work and distribution to app/core devs and y% split to chunks with payment IDs
I see a couple of cons to it though
- a fair amount of coding in the nodes needed to implement and test.
- Any disagreement of how the split is done will cause delays or resentment.
- work is done by the nodes which loads them down just that bit more.
- real easy to game. Just keep getting your chunks to boost payments. Scale of the gaming is limited by how much the person wants to do it. How profitable would it be large scale depends on the splits decided upon.
- user has no control how their payments are split. At least with paying nodes w% and foundation z% then the user is happy or doesnāt use it. But the user may have downloaded a 15GB high quality movie only to find out it is 15GB of junk (maybe name of new movie and this happens 1000ās of times over) and resents that the scammer will be paid for their scam automatically (this was an issue for old PTP idea too)
My idea was that the client code does the payments of suggested tips/charge according to the users preferences. No need for nodes to keep track of any lists or working out splits and saves the extra work/memory requirements for the nodes and each client does the work. Then the foundation then can handle the manual payments to those doing core development and building apps that donāt suggest a charge which would include those building useful libraries installed in other peopleās Apps.
Only testing is
- that the payment ID & amount is stored and returned correctly. You need to do the payment IDs and retrieval anyhow for your suggestion
- that the client pays according to the users preferences of limits and % of suggested.
- test setting of preferences (UI)
And of course write code in the client to use returned payment ID & suggested amount and to write code to allow the user to set preferences.
By doing it in the client then if people want to mod how its handled in the client then its easy to do since the person is the only one who needs to run the modded client. Whereas if its in the node then it has to go through a review process and be accepted by core devs before any mods can be made to how its handled.
And best of all it opens up an avenue for wide ranging tipping without the user needed to manually doing anything. PtP & PtD are just a subset of this tipping.
Another point is that the provider of the chunks (content/apps/forums/blogs/etc/etc) has the freedom to set the desired payment and the user has the freedom to how much to pay, if anything at all. This means that an App developer who makes a very difficult program that is useful to only a few (eg rocket design) is able to ask for a lot more than the nominal 10% and the handful number of companies using it are likely to be very happy to pay it just so updates continue. Or the provider might only want less than a % since its say a forum that doesnāt require much work. Then again the forum could pay the moderators a token amount for the categories they moderate and this is derived by the payments of chunks read from those categories.
5 Likes
Yeh kind of. You could have client side decisions to widen the spread,so to speak.
Iād imagined nodes flip a % coin to decide if they require one or the other this PUT.
(Also, to reiterate, this is just my thinking atm, we havenāt gotten deep into this topic as a team yet! Itās just one way it could operate).
Cache will be a nice to have anyway. So assuming thatās in place.
- List the current cache on
GetStoreCost - Validate that sufficient of those candidates were paid (instead of network royalty).
Node side itās not a lot of work I think.
Indeed, but thatās an issue for any popular content based issue. The client being able to choose āpay 5 of these 100ā would sort that perhaps? The chances of your content being where folk are PUTting is not that high? Iām not sure, it doesnāt feeel like a blocker (again, going off popular content in general).
It could just be everything at the node, and you can pay any creators there too. Doesnāt ahve to be cache backed, tbhā¦
Thatās what I mean here. I imagine a node says. āPay 5 tokens to any of theseā and sends a big list of keys they can then validate in some fashion. (That validation might be the trickiest part, hmm)
Aye, so in that these are similar. But nodes have to validate a payment went somewhere. That nodes would supply a list of acceptable content comes off the popular content rewards angle. But neednāt. Really itās just about allowing nodes to know what to validate payments against (is this person just paying themselves? )
3 Likes
Yes, as I said that was an issue for original PtP and PtD proposals and yes the client doing all the work and decisions solves that because its the clientās SNT being spend. So gaming is non nonsensical since the user is paying directly and not the nodes deciding allowing gamers to skew the āpopularityā
Using what i suggest then Nodes have nothing to validate since the client is already doing the deciding who they want to pay. It ends up just as normal payments processing.
The nodes have no interest if the clients are paying the right people or paying at all. It solves a lot of angst of people paying rewards to app/content providers by the network decision. Now its up to each client to do the decisions and work generating payments and the node has no responsibility in it other than returning the payment ID and suggested amount in the api return.
Thats why i donāt see them as similar as suggested. Similar in that popular content/app have greater chance of being paid. BUT
- the amount is decided by the provider
- the amount paid is decided by the user (thru client)
- paying themselves in this system means nothing as they can initiate payments to themselves anyhow.
- spamming GETs in my suggestion has no effect at all. Because if a client GETs same chunk multiple times they its them themselves deciding to pay. Its not the network thinking its more popular. Spamming GETs will not achieve more payments unless the one spamming pays it LOL
1 Like
In the end if a provider is not happy with their returns then they can update their APP or content and register with the foundation and try to be paid from the pool the foundation has. OR the automated system built afterwards.
This suggestion goes beyond the 10% app dev and 10% content provider system and in my opinion is sensible to run along side the formal app dev and core dev payments from the foundation pool (automated or not) and is in fact a cool new feature. Also it will reduce the workload of the foundation while it is manually processing payment requests and paying core devs.
If this is to replace a portion of the royalty fees (15%) then they would have to? Iām not following what the aim is and how that aligns with the network fees/rewards as have been suggested before, sorryā¦
That feels like a pretty crucial part here?
If weāre designing automated patreonā¦ Thatās kind of outside the scope of network payments and validations weād be having to carry out?
I was feeling like Iāve missed something in your proposal, then just saw:
Okay. Thatās fair enough, but Iām talking specifically about the content provider system which would require network validations in some fashion if itās to be automatedā¦
My suggestion (in the automated provider style):
- allows clients some discretion in who they pay / what for
- keeps it simple. Nodes decide what content is applicable form what they are holding
- clients can validate (addresses are indeed close to the node)
- nodes can easily validate
- clients do all the transfer
- sits neatly alongside current royalty payment process
1 Like
Not addressing the 5% core dev (5 of the 15%) which I doubt can really be automatic for a long time.
Not trying to completely replace the 10% App rewards (10% of the 15%)
Because this is a new feature to allow providers to directly ask users to donate/pay them it really isnāt a part of Pt* so nodes do not need to be concerned about it. But it has a follow on effect of satisfying providers (not all obviously) without needing to rely on Pt* and so that does affect Pt* but isnāt a part of it as a foundation concern.
It is a new feature idea which has the purpose with follow on relation to App/Content rewards PtD PtP while not replacing it
- provide a way for the power to be in the hands of the providers and the users to negotiate a fair reward for the usefulness of their App or Content
- Does not completely replace PtD & PtP, but does allow some of it to be bypassed if the provider wants too
- provider can suggest a different rate of reimbursement (higher or lower) than 10% of chunks read pricing
- Provider maybe providing (in their opinion or reality) a much more valuable App or content than the number of chunks represent. Or less value too.
- User has the ability to not pay, or reduce pay, or pay asked price, or over pay.
- provides freedom for both provider and user to handle the transaction to their own satisfaction
- provides a much wider feature than what PtD & PtP can provide, but is in the spirit of them.
- provides a no nonsense way for tipping to happen.
The foundation would be unable to realistically handle 10ās of thousands of App developers and 1000ās of thousands of content providers (say after a year) and so this feature would provide a simple way for nodes to do no extra work at all and clients to do all the work.
If an App Dev or content provider is unhappy with their returns then they could opt in to registering with the foundation.
Also the foundation will then have the ability to pay code library developers a decent amount along with the App Devs since there are less App Devs / content providers trying to access the royalty pool.
Basically this is a feature separate to the royalty pool the foundation administers, and in addition reduces in a major way the work load of the foundation as a follow on effect. Also is a no node extra work method.
Yes there are the payments clients will be making but you have that no matter what you do since they have to be paid anyhow. But its not work the node does to decide who is paid or telling clients who to pay or anything like that. The client gets the payID & Amt as part of the meta data and then does all the work to pay others.
1 Like
This will not allow library developers to receive anything significant since their code will be included in the App using it.
It will be gamed as much as people can, which maybe insignificant but still skews the payments.
Good point
There needs to be kept tallies and each chunk the node has to increment a counter till a count is reached OR each access tells the client to pay.
Validate what??? The client Gets a chunk and the Node separately messages the client to pay a payID that will usually not be near the nodeās address but is the providers PayID
This doesnāt seem to be practicable in that the client may only get one chunk from that node for a long time.
So you mentioned before the client would have a choice of a few to pay. But then you are offering the client to pay for other peopleās GETs if the client is typical and only getting one chunk from the node over a period of time?
Basically this method boils down to client GETās one chunk then the node then messages the client to pay the PayID in the meta data and the client pays or not.
And the Node validates what? If the client sends a payment to another PayID then how is the node validating? it could be the client being buggy or just paying someone else. Is the node going to reject it. Also the nodeās address will nearly always be far away from the PayID address and thus will not see the payment anyhow. So what validating can it do?
The vibe i am getting is that my suggested feature would do that work with more features. And the node has nothing to check, validate, etc. Then the foundation is free to handle the exceptions and will be a fairer system all around.
Anyhow its a suggestion, I am just explaining more to help you understand it the way I do.
In the end its up to the devs to decide and for Jim to check it would still fit in the regulations. AFAIK it doesnāt need check with regulations
That would exist in any caching system (what to cache).
That there was a valid payment to developers/creators who should (according to the system) get paid as part of the overall network rewards program (the 15%).
This happens on PUT. This is part of the data storage payment. It could be counted directly towards the royalty payment total (15%) eg.
Which method? The one I am suggesting?
My suggestion is explicitly looking to automatically handle the allocation of funds to creators as part of the 15% royalty on PUT.
Any system not doing that is not comparable as thatās the main aim Iām thinking to achieve here.
Thatās fine, and seems like a fine way of adding on automated patreon-like support. But itās stated aims are not the same as I understand it, so itās not really comparable on that front?
To clarify, Iāve not tried to critique your suggestion above @neo so much as clarify my own (which I appreciate was quite vaguely described in the initial). Your suggestion seems like like a decent way to achieve extra client-supported income in an automated fashion.
1 Like
You missed the point, my bad wording
The point was that the payment to the provider is very unlikely to go through the node that the PUT was done to. The PayID of the provider could be any XOR address and in a non-trivial network it is >99% likely to go through another node.
So how does it validate a payment it will never see.
3 Likes
Ah sorry.
This can happen the same way a node would validate itās been paid, or royalties have been paid for a given data-payment. The Transfer or CashNote in question will be sent to the node for validation alongside the storage dataā¦
Itās this way for data payments in general. The transfer may not actual go to the node storing data at all. So we send it along as supporting info so the node can check and see itās been paid.
Royalties use a similar path, sending an unencrypted transfer so the node can validate the royalty key has been paid.
So here Iād imagine we swap out the royalty-to-network for another royalty-to-local-(to node)-content payment. Which can then be validated by the node.
3 Likes