Pay the Developer (PtD) Reward Amount discussion

At the very basic, the network does everything.

My point was that its the users who decide if they give or not. That is not the autonomous network doing it. Yes it physically does the transfer by smart contract or otherwise. Or do you mean that the network creates the conditions for the smart contract and decides the how when and why for the reward?

Anyhow smart contracts require processing and how much load is that going to cause when its done every time people run an APP. I still feel its best to keep it as simple as possible. The mechanism for rewarding the farmers will be built into the network and rewarding for other things would in my opinion use the mechanism but with different parameters. For example the rewards are determined proportionally and then the pool from purchases is divided amongst the rewards proportionally.

Another system suggested was a simple tipping system that users decide whenever they want to. Maybe a UI can be built that can be added to any APP to provide that functionally, or even an APP specifically for tipping and the APP calls the tipping APP with values if the user clicks on TipMe button.

2 Likes

Yes, exactly. The act of the user interacting with the app could be interacting with the smart contract. The question would be is it required that an app is tied to this smart contract? If so, how is that enforced?

I do agree with that and see that as the biggest downside.

2 Likes

Well this seems rather complex since the App is just a file and the PC or browser executed it. The proposed reward system was just to have a payment address associated with the file.

Once you rely on the client to be truthful on its interaction with the file (which happens to be an APP) then you open the door to the client lying about it.

My thought experiment is what is required for the initially proposed method of store the address with each chunk of the APP file. There is kept a tally of GETs on each of those chunks and when its time for the collected payments to be sent out then a proportional amount is sent to each of those addresses and to the farmers. Just divide up the amount and send to the addresses (farmers and App) proportionally.

But a smart contract has to have execution by the elders to do what? To say the chunk was accessed x times. And which section becomes the executioner of that contract for the APP. APP will be spread across at least 3 sections since there is a minimum of 3 chunks in the APP file stored on the network.

Just a overview suggests that a smart contract will be a lot more work for the network without benefits since the task is so basic, that is increment a count for the chunk.

I am just at a loss as to what benefit a smart contract is if it is still the network doing the how, when, & why on the APP dev reward.

I don’t have the technical knowledge to tell you how this could all work but from what I think I grasp, if DBCs had a type field then (if I remember correctly) some kind of Logic could be built around them. I kind of remember the mention of homomorphic encryption too though and maybe that is what the Logic could be built around.

I just spent the last 15 minutes scouring the forum to find the quote from @dirvine but could not find it. David, this could be a fun time to jump back into the technical stuff! :smiley::wink:

So assuming some kind of Logic could be built around DBCs then the app could still have a wallet address tied to it, and so could anyone who uploads data through the app. When a user interacts with the app then maybe that triggers the smart contract, and that client does the work of aggregating the sigs and info from the smart contract to have the Elders sign. Basically the same as how DBCs are handled but with some extra if/then logic.

Maybe at some point too much is being pushed off on clients even? Idk. But to me if what I mention above is at all possible then does it create any more extra work for the network than having it coded into core? I wouldn’t think so otherwise DBCs would have been implemented differently.

Funny we are having a discussion in a topic (PtD) that never received much attention, about something else that could use more attention, smart contracts/NAL.

3 Likes

Yes, a type or reason filed. The idea is that this reason would be things like

  1. A purchase order (so payment fulfils that)
  2. A measurable network event (like assign for storing a chunk/contract)

and so on. @danda and David Rusu have sniffed around that too and quite rightly IMO have concluded that this could be a second layer to not confuse the DBC layer itself. I suspect that is possible to, but for sure I think we can use such a system for farming payments, receipts/purchase orders and much more where proof of payment is required). So start of a smart contract type system.

Sorry that’s a bit wooly (it is) but this will solidify very soon when the ring sigs is completed and tested, which is in motion right now.

10 Likes

A good solid and simple base layer makes sense and add some abstraction and complexity into a second layer. Sounds great. Don’t know how it is achieved until y’all tell us but from there it is easier for the community to get creative and help support the efforts.

Glad you are considering smart contract/NAL already though because it opens up a world of possibilities and if it is good enough for farming and PtD then it should be good for other fun stuff.

I’m not sure your opinion of formal verification or how that could be done with Rust as there are specific languages such as Ocaml but I know the benefits when dealing with money and smart contracts are worth it and considered institutional grade.

Edit: maybe this is of interest for formal verification in Rust?

5 Likes

Keep in mind that anything that differentiates one DBC from another makes each unit less fungible. So a type field would divide the anonymity set by the number of possible types. This is a reason why coins such as Monero do not attempt to do smart contract stuff on layer 1.

Likewise, our present thinking is that DBCs are electronic cash. period. If we think about the real world, there is cash and there are contracts. Separate things. Contracts can be payable in cash. But it’s a little weird to write a contract on a dollar bill. So our focus is to make the best electronic cash that we can, and then invoices, receipts, contracts, etc can be built around that. But we separate concerns.

Back to type field: I believe it would be possible to add a type field without harming fungibility if the entire coin were blinded, perhaps using a ZK proof, ZCash style. But we aren’t presently going down that route.

13 Likes

Excellent point Danda. So could there be a second layer DBC, maybe that even charges fees that could specifically be for altcoins and smart contracts?

3 Likes

yes, we are envisioning a payments layer for:

  • Invoice
  • Payment
  • PaidInvoice
  • A public “Bulletin Board” where a PaidInvoice can optionally be posted, as public proof-of-payment.

See: feat: payments infrastructure. · Issue #112 · maidsafe/sn_dbc · GitHub

It should/may be possible to generalize the above into a broader notion of “Contract”.

6 Likes

Curious, would proof of payments require permission for that proof from both parties or would they be default for each transaction?

Ok, so here’s the basic data structures we have brainstormed thus far:

struct Invoice {
    amount: Amount
    payto: PublicKey,
    seller_signature: Signature,
}

// A payment looks like
pub struct Payment {
    dbc_packets: Vec<DbcPacket>,
    memo: Vec<u8>,    // should be fixed size?
}

// buyer pays it.
struct PaidInvoice {
    invoice: Invoice,
    payment: Payment,
}

note: a DbcPacket is just a Dbc with some extra metadata useful for one-time owner keys.

So the process is:

  1. Seller presents an Invoice for the desired amount to Buyer.
  2. Buyer reissues Dbc(s) with Seller’s publickey as owner.
  3. Buyer creates a Payment consisting of Dbcs plus optional memo.
  4. Buyer creates a PaidInvoice consisting of original Invoice plus Payment.
  5. Buyer sends PaidInvoice to Seller.
  6. Seller sends goods to Buyer.

So long as everyone is happy, this is the end of the matter.

However, perhaps Seller claims that Buyer never paid them. In this case, Buyer can present/publish the PaidInvoice for anyone to examine.

Note that it is possible for Buyer to create a PaidInvoice without actually sending it to Sender. In this case, the act of publishing to a known-public-location is both the proof-of-payment and the Payment itself. Because the seller can retrieve the Payment from the known-public-location. (and only Seller can reissue the Dbc(s)).

It could also be revealed in a more private manner, such as during arbitration proceedings, via an attorney, in a courtroom, etc.

The point is that all this data is private to the Buyer and Seller unless/until either party decides to reveal it, and in what manner.

Note that there is no date/time anywhere. It would be the act of sending the PaidInvoice to Seller or the act of revealing/publishing the PaidInvoice (proof-of-payment) that establishes a date/time and other metadata. But any such timestamp are created outside of the payment system, at least in the present conception.

8 Likes

This is beautifully simple and straightforward.

3 Likes

A common piece of “paperwork” is the receipt. I know sending the PaidInvoice could be considered a receipt, but is not in a conventional sense for accountancy purposes.

Can I suggest there is a 7. Receipt

The receipt shows the date from the supplier’s system, that the supplier did not go bust and has taken on the responsibility to do said task and did not return the “money”. Basically when the Supplier acknowledges receipt of “money” and commits to supply. The committing to supply is a very important aspect in the transaction and the receipt is a part of it.

The returning of the money for some reason (one would be seller went bust inbetween invoice and payment) negates the PaidInvoice since the person actually got their money back. Also in that case the buyer could pretend to others that they were robbed while the seller is not aware of the claim.

Even if optional.

But before returning the money, the seller would request an invoice from the buyer showing that they requested the money back. Same process takes place again where the seller can prove they returned the money. No need for a step 7.

I agree that Receipt is good to have. If you look at the link I posted above, you’ll find:

struct PaymentReceipt {
     payment: Payment
     signature: Signature
}

Initially (before we had Invoice, PaidInvoice) I had suggested PaymentReceipt for proof-of-payment. But it was pointed out to me that there is a chicken/egg problem of who goes first. Buyer faces the risk that s/he makes payment and Seller never replies with a receipt. So this is a situation where some kind of atomic swap protocol would be needed. And those tend to be quite complicated.

The Invoice/PaidInvoice model sidesteps that because the seller’s signature is already on the Invoice. So buyer need only prove that she has paid the seller’s signed invoice.

The receipt shows the date from the supplier’s system

yeah, so already we have a little issue here because the SafeNetwork has no notion of time. So, as you say, this is data from the seller’s system, and not something that the network can verify or enforce in some way.

So what I am thinking is that Receipts are a good/useful thing for accounting as you point out. Businesses will continue to use them, especially for B2C commerce. But if we think about what happens today when we shop online or at a physical store… the merchant themselves generate the receipt and provide it to the customer by email, browser, or physical paper. It is generally not the payment system (cash, visa, mastercard) etc that generates and transmits the receipt.

Stated differently: nothing in this scheme prevents merchants from providing receipts, and I’m confident they would continue to do so.

It might make sense for the payment system to provide some APIs for generating some kind of standard receipts and perhaps we end up with that eventually. I haven’t really thought through it. But my gut feeling is that it should probably stay entirely in the merchant’s domain/control.

7 Likes

Simple
quote/invoice for service/item/whatever
paidInvoice
receipt.

The quote/invoice is the seller telling the buyer how much
the paidinvoice is the proof the buyer sent the money
the receipt is the proof that the seller has committed to the deal

If buyer does not send the money (paidinvoice) then seller has no responsibility to do anything.
Any questions requires the buyer to show proof (paidinvoice)

If buyer sends the money (paidinvoice) then seller accepts (sends receipts), rejects (returns money) be an arse and do nothing.
questions

  • buyer can prove sending money, means seller got it (if seller does nothing/disputes)
  • seller can show receipt OR show return of money

Seller sends receipt or returns money (maybe buyer sent too much, not enough, seller went bust, whatever)
questions

  • seller shows receipt or returned money

Yep, exactly what happens in the real world. We live with that and works well. It does not change the order of proceedings which is the important part. Date is more for accountant to balance and help perform “bank” reconciliation.

In the end the receipts is the last step in the handshake protocol of payment transaction. Just like many data protocols.

Next step is items/service sent (job completed) and buyer can optionally acknowledge. But that is not really a network sort of action is it. The payment protocols is a long accepted system and honed from experience.

This is basically where I was coming from. Can be optional but good business practice.

3 Likes

I’m worried about metrics proposed here for PtD / PtP. Paying for data size is terrible, being it app or content. What about 10 hours of Nyan Cat vs. a haiku? Also, time spent or attention is terrible for apps, as we already know:

“Put simply, humane technology aims to create socially-responsible options that don’t exploit the user. It needs to respect their time, their attention, and their personal data.”

Otherwise we end up with apps competing for human attention turning them into zombie-scrollers and binge-watchers.

What about a simple content-upload app with stupid jokes and funny videos vs. some complicated life-saving app, that is used only by people in danger? Which one should get more funding?

I much more like the idea of a tipping / rating system, which then distributes accumulated PtD payments to individual apps. Perhaps the same for content? It’d important to reward quality, not quantity.

Safe Network role is to establish a safe and globally available network for everyone.
Sure there will be apps that focus on clickbait, social media engagement, etc but there will be plenty of apps that focus on the better parts and this is also their trademark. People can make the choice themselves and then decide what they ultimately need, we are just providers with various ideologies and means to accomplish those goals.

5 Likes

I respect your desire to create humane apps, I share that desire and I think if an app can provide some sort of benefit/value/joy but not be a burden on someone’s well being then it’s a decent design.

But whether it’s a rating system or just paid by use it’s basically still down to popularity/use, imo. Those attention stealing zombie scroll apps will always exist now and some people will willingly choose them to get the continuous drips of dopamine.

Hopefully we can just offer something additive but not too distracting that enhances the human experience or takes a load off peoples shoulders so they can live with less stress.

The reason I like PtD is it gives app developers to the opportunity to produce apps that are free without making people and their data the product. I think PtP is interesting because you can incentivize participants to upload data that provides value to not just themselves but also others, offloading more effort for app devs so they can focus on delivering FOSS.

8 Likes

Those are fair points but don’t prevent people producing humane apps, a tipping scheme or any other reward model.

No automatic system will be fair, so what is the benefit of such a system?

I support the idea because it gives literally everyone a trivial, built in way to monetize their work with zero effort on their part and no intermediary. That doesn’t exist anywhere yet so I think it is worth trying. Universality is also a humane technology goal of course.

6 Likes