Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft protocol to compensate couriers #34

Open
gnarea opened this issue Feb 3, 2020 · 1 comment
Open

Draft protocol to compensate couriers #34

gnarea opened this issue Feb 3, 2020 · 1 comment
Labels
enhancement New feature or request feedback wanted

Comments

@gnarea
Copy link
Member

gnarea commented Feb 3, 2020

I see this as a blocker to get Relaynet deployed on a large scale as I don't think it'd be realistic (or fair) to rely on unpaid volunteers and charities to act as Relaynet couriers for an entire region/country. And whilst I've been thinking about this from the very beginning, I decided to keep it outside the scope of the initial version of the protocol suite for three reasons:

  • The early drafts of the protocol (called "postage") were getting pretty complex, to the point it felt like a project in its own right.
  • I realised that the time wasn't right and I should defer it until we've run at least a few pilots. Otherwise, there would be far too many design assumptions that would most likely be far too detached from reality.
  • I didn't (and still don't) have access to someone with the legal expertise required to take this forward. I'm particularly concerned about taxation, AML compliance and US sanctions.

I won't be actively working on this in the short term but I want to create this issue collate my thoughts and those of others. Here are some high-level parameters:

  • We should to invite CSOs like Access Now to join this process, and we should invite them as soon as we start working on this.
  • It's OK if version 1 of the protocol is a steppingstone as opposed to the endgame. I prefer something acceptable that works sooner over something theoretically perfect that will take longer to design/build.
  • Consequently, I don't mind using centralised payment systems as long as couriers (just about) anywhere can get paid. In other words, cryptocurrency would be ideal but not required.
  • This is goes without saying but I'll say it because it might throw a spanner in the works: The solution has to be legal. So:
    • Anyone involved with its design, implementation and/or deployment (e.g., Relaycorp) can't violate US sanctions. So we have to seek legal counsel early on.
    • We can't enable couriers to do tax evasion. But how can we do that without disclosing to the repressive regime they live in that they are Relaynet couriers? Maybe we can help them pay tax in a different jurisdiction.
  • Where's the money coming from? Options are: People may pay for the delivery of each cargo (like postage), they may pay a flat fee, people/organisations abroad may contribute towards an "Internet blackout fund", etc.
    • If users have the option to pay the courier directly, there must be a mechanism in place to prevent people who can't afford to pay from being left out. It's OK for people to pay the courier for more capacity or a expedited delivery, but everybody should be able to have their cargo relayed. I think this is where an "Internet blackout fund" can help.
  • If feasible, part of the proceeds should go to legally challenge the blackout and future ones.
  • Incentivising couriers might be a double-edge sword: A small minority may be tempted to disrupt the Internet service so they can be compensated. How do we penalise that?
  • Couriers should not be allowed to put vulnerable people (e.g., children) or animals at risk. This may require partnerships with local charities so they can audit the methods employed by couriers -- at least the largest networks of couriers.
  • Couriers should also be compensated for periodic drills. This is very important to make sure they're actually prepared for a blackout.

To be clear: Relaycorp will not be taking a cut on these funds. If anything, we'll contribute to the Internet Blackout Fund once we start generating a profit from other sources.

@gnarea gnarea added enhancement New feature or request feedback wanted labels Feb 3, 2020
@gnarea gnarea assigned gnarea and unassigned gnarea Feb 3, 2020
@gnarea gnarea pinned this issue Feb 16, 2020
@gnarea gnarea changed the title Draft protocol to compensate couriers for their services Draft protocol to compensate couriers for their work Feb 17, 2020
@gnarea gnarea changed the title Draft protocol to compensate couriers for their work Draft protocol to compensate couriers Mar 2, 2020
@gnarea
Copy link
Member Author

gnarea commented Apr 29, 2021

I can't believe I'm about to say this, but the more I think about it, the more I lean towards a blockchain-based solution. I'd always been reluctant to throw blockchain in the mix, but the non-blockchain-based solutions I've considered require too much effort, funds and red tape in order to satisfy legal and my self-imposed transparency+privacy+safety+security+inclusion requirements.

Generally speaking, I'm leaning towards one or more smart contracts to achieve the following:

  • Create a utility token to pay couriers. Ideally pegged to a stablecoin like DAI or USDC to avoid speculation (and therefore volatility). Couriers would optionally form syndicates (see Implement an app to route cargo at a "transport hub" relaycorp/relayverse#12) and set their profit distribution upfront.
  • Tokens could be purchased (e.g., by relatives abroad) or airdropped (e.g., by charities). Each would be valid for 12 months and be valid in a specific country/region.
  • Each token could be shared with up to N private gateways, where 5 < N < 10. Any given private gateway can have zero or one token at any time.
  • At each user/courier synchronisation, the user would certify the sync. This cert will include the number of cargoes sent/received, an approximate time (e.g., "week 11 of 2021") and the address of the private gateway (requires fixing Make private gateways use a different identity key pair when communicating via couriers #71).
  • At each sync between a courier and a public gateway, the public gateway will validate (counter-sign) the certificate issued by the private gateway if all the data looks correct.
  • The courier will then share the validated certificate on the blockchain (through an oracle, unless the courier themself is an oracle).
  • At the end of the week, couriers (or courier networks) are rewarded in proportion to how many relays they did.
  • One or more oracles (ideally CSOs) would determine the period during which tokens from a given region can be redeemed. For example, "week 11 of 2021 in X country". This would be used during drills too.
  • To incentivise couriers in the middle of a blackout, anyone could donate additional tokens to increase the financial rewards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feedback wanted
Projects
None yet
Development

No branches or pull requests

1 participant