Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

switch to web of trust for open group pachinko #901

Closed
chadwhitacre opened this issue May 1, 2013 · 2 comments
Closed

switch to web of trust for open group pachinko #901

chadwhitacre opened this issue May 1, 2013 · 2 comments

Comments

@chadwhitacre
Copy link
Contributor

Right now open groups on Gittip are such that anyone who has moved money in/out of Gittip can vote on how the money is split. We need to move instead to a web of trust model where the open group participant is the root. Anyone they vote for can also vote, and on out.

This is hot because @jmathai is asking for Trovebox to be an open group:

https://twitter.com/jmathai/status/329319612468588544

@chadwhitacre
Copy link
Contributor Author

Also hot because of this use case (via Twitter):

I'd love to set up a corporate parent account then give some engineers the ability to direct funds.

The way pachinko would work for this use case is:

  • Select "We're here as a patron, and politely decline to receive gifts."
  • Add a credit card.
  • Fund the account each week for a predefined amount (that'd be a new feature).
  • Add engineers as root-level in the web of trust (and maybe there is no web?).

@andyweissman mentioned something very similar on a Skype call we had a while back.

@chadwhitacre
Copy link
Contributor Author

I want to get this done. This is, to me, the last big feature that Gittip needs under "make it run." After this, we turn to "make it right." What do we need in order to open this up to others?

First, we're going to call this feature "Teams." Teams can have up to 149 members. A member of a team is an individual participant (not a company, nor another team) that is allowed to vote on how to split the money given to that team.

Here's what we need:

  • rename identifications to team_identifications (etc.) won't implement
  • teams need to be able to record entries in team_identifications for themselves
  • rename allowed_to_answer to allowed_to_vote_on
  • update allowed_to_vote_on:
    • should take an argument, the team in question
    • anyone immediately identified by a team participant as being in the team is allowed to vote
    • anyone with three(?) votes for them is also allowed to vote
    • ORDER BY (nvotes, ts_first_allowed) LIMIT 149 Reticketed as implement 149 limit on open group membership #959.
    • anyone over the limit still gets UI to vote, but their vote won't be counted in compute_split and therefore won't count during payday ("waiting list"?)
  • we need to record country and EIN for the team participant—this is the legal entity that is considered the contracting party in the relationship with those receiving funds. We're going to have to accept U.S. only companies to start with. However, I can't see us launching this without allowing for non-U.S. contractors. Gittip itself has people outside the U.S. that we need to deal in from the start. See Publication 515 (2013), Withholding of Tax on Nonresident Aliens and Foreign Entities. It sounds like the short story is that non-resident aliens will need to get an ITIN (like an SSN; form W-7) and then will be taxed 30%(!) unless there's a treaty with their country (which there probably is? no idea, really). This begs the question: what about money we're moving right now? It puts rather a damper on Gittip to have to withhold 30% of everything paid out outside the U.S. Also a damper to have to require ITINs, etc. Hmm ... Reticketed as sort out tax reporting for Teams #960.
  • need to require opt-in plus paperwork to receive money from a team
    • storing SSNs/ITINs ... what does that do to our hosting situation? Do we need to get into PCI compliance here?
    • again, begging the question of what this would then mean for our existing setup—would the IRS have us withhold 30% from all payouts?
  • bring over numpy-backed pachinko from @carsomyr's branch Reticketed as bring over numpy-backed pachinko from @carsomyr's branch #961.

chadwhitacre added a commit that referenced this issue May 16, 2013
It now takes an argument, the team in question. It is otherwise
unchanged as yet, however.
chadwhitacre added a commit that referenced this issue May 16, 2013
The constraint we were using to locate the ctime to use was too loose
relative to the distinct clause in the current_identifications view.
chadwhitacre added a commit that referenced this issue May 16, 2013
Early and often. This is the barest conversion of pachinko for open
groups to a web of trust model instead of a more open voting model.
corytheboyd pushed a commit to bountysource/www.gittip.com that referenced this issue May 16, 2013
It now takes an argument, the team in question. It is otherwise
unchanged as yet, however.
corytheboyd pushed a commit to bountysource/www.gittip.com that referenced this issue May 16, 2013
The constraint we were using to locate the ctime to use was too loose
relative to the distinct clause in the current_identifications view.
corytheboyd pushed a commit to bountysource/www.gittip.com that referenced this issue May 16, 2013
Early and often. This is the barest conversion of pachinko for open
groups to a web of trust model instead of a more open voting model.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant