Topic: [ANN] Rein - Decentralized Freelance Market - page 3. (Read 10549 times)

The project now has a provisional name!

Rein.

(as in free).

http://ReinProject.org redirects to this thread for now.
Twitter: @ReinProject
Sub-reddit: reddit.com/r/Rein
Github.com organization: https://github.com/ReinProject

The Signature Tool is way easier to use now thanks to thelink2012 over at bountify.co. This video shows how simple it is to verify and sign a message like one would do when creating an identity, job, or bid or when reviewing/auditing someone else's signatures.

https://youtu.be/kqHg_07xJ5U


Download the tool then run it locally in your web browser. Offline use is recommended.

The bitcoin signature tool was taken care of at bountify.co. Working on integrating that with the users.py script to see how much of the verification can be automated. My goal so far is to have the output look like:

Processing Database
sha256 root hash: 99d4e8f3b7c285a98398d907098a899798e897f891265

Errors: Review mismatch:
   Users. 1ypoifkdsaifoofkwlfaoifeklvds432

Tasks to be completed:
Reviews (and Audits) to be done:
   Users, 19fofidsapfiokaf904390fudsfsd
   Users, 190439ifuhf3kds98938472095
   Jobs, Be Awesome, 020985349075908275903489432897564379287439827549372095432
   Bids, Be Awesome, 0209853490759082759…., 0202347625832090348….
   
Audits to be done:
   Users, 1498573098729385784393487
   Jobs, Be Awesomer Th…he World,  02026548534907590827590348943289756437928743982754937

I will take a look at the sig tool update job and see what I can do with the program.

Also, is it possible to post for hire requests on that marketplace e.g I want people to hire me to do work.

Posted the job about verifying signatures to https://bountify.co for $50 in BTC. It should show up in an hour or two.

Added:

Applications:

• A decentralized labor market combines human judgement with individual accountability through cryptographic signatures.
• Currency hedging, volatility protection - As long as enough funds are locked up to fulfill the value of the job, the signers can easily return excess funds to the job creator. For example, let’s say a job fee is set at $5k split between a front end dev and back end admin. Guarding against a 20% currency move means putting $6k in Bitcoin in escrow. If the value of escrowed funds drops, the workers would be right to demand more funds be placed in escrow to continue work. No action is required if the opposite happens.
• Milestones - Escrowed funds could be paid out in multiple payments based on reaching milestones in the project. The people in the project have to work together to send the payments and are accountable since their actions are recorded cryptographically.
• Subcontracting. Funds could be broken out and used to create and fund other jobs with completely different mediator/worker/milestone combinations.

Perhaps the greatest opportunity for this protocol isn't for small gigs and medium sized jobs. Maybe we should be thinking about where greater amounts of trust are required between participants. The low budget example here might be hiring a project manager and locking the funds for a project they manage so it is split fairly  between the manager and each of the workers.

A huge feature could be volatility protection. The amount of escrowed bitcoin could be greater than required to handle currency fluctuations with any excess returned to the job creator.

Things like getting some very simple scripts written (kind of stuff that would take someone with the skills only an hour or so). I had to offer a few hundred dollars for these kinds of tasks (many of which I just ended up doing myself instead to save funds).

nice

The way I'm looking at this project is not so much as a way to attract some class of user, but more to empower any user to be able to easily conduct a trade of their labor in a trust-free manner. Some have advised that higher paid workers prefer longer term gigs and would probably prefer a process with milestones rather than one-off jobs. It's too early to worry about any of that though. We still need to get through the first trade and build the process, in the process. I could definitely use your help with any of the things in the OP.

Oh, also what kind of premiums did you offer over what you considered fair in your experience but still get no takers?

To a fair extent I think it very much depends upon the kinds of tasks.

Very talented programmers (which I have tried to target) are simply not possible unless you offer almost ridiculously high prices (it is just too easy for them to get a high paying stable job).

Low talented programmers you'll find but are really not even worth bothering with (they'll cause you more trouble than you pay them for).

Graphic designers are perhaps your best bet as those people tend to work for nothing (often trying to chase bounties which only one of them will get). For CIYAM Open I didn't want to do bounties (as I think it is actually unfair to have people working for nothing) but I think for that kind of task they actually seem to work better (apparently those kind of people like to gamble on whether they will get paid at all).

Point taken. Clearly people do gigs online all the time so it sounds like a key focus is going to need to be addressing the reasons why more workers don't get involved. What might those be?

Probably the main project other than the platform itself and the Automated Transactions (AT) project was the Moneychanger project (from the Open Transactions people). Unfortunately they did all their payments "off the record" so the Project tasks listed there show no payments (and were never closed).


I guess the main lesson that I've learned is that people are not yet ready to work this way - even when I offered almost insanely generous payments for tasks there were very few (if any) people willing to take on the work (and that was not due to not trusting me about payment).

Thank you CIYAM. II looked at it and at least know now what your handlestands for. If I have it right, it was a project to build a marketplace based on GPG and focused on using a specific development platform. Were there projects funded outside of that?

I'm calling this a protocol because though we have to start with specific tools, a well-documented and well-designed protocol can be platform agnostic. Maybe it would be best if you wrote up lessons learned on your project and posted a link here.

Not sure if you had ever looked at CIYAM Open but it is a similar (but simpler) concept (http://ciyam.org/open).

Feel free to contact me via PM if you'd like to discuss my experiences with trying to get this kind of thing up and running.

Created a new git repo with a script to begin basic validation on the Users sheet.

https://github.com/weex/dpsmp

This is the script for which I created the signature verification module job above. Ideally this script will check everything to make a reviewer or auditor's job dead simple. Download the sheet, run the script, review or audit any records they can or raise alarm bells on anything that's amiss.

Posted the first two jobs to the new Job Listings sheet. Pasted here as well.

-----BEGIN BITCOIN SIGNED MESSAGE-----
Job Name: Signature Tool Updates
Job Creator’s Public Key: 03FB2CA1B513858CD8461AE875BA7096CB7D585C29E7C6B5294FEF7B6C326389C4
Mediator’s Public Key: 04594f2582c859c4f65084ee7fe8e9ec2d695bb988a3f53db48eaaff6ff3a0282b2be0c79fefca0 1277404d0fdc3a923e8ed02efd6ab96980f3e229a81fbe032e9
Category: Software Development
Job Description: I’m looking for someone to help update the signature tool. Please fork https://github.com/weex/bitcoin-signature-tool and provide me a pull request with the following changes:
1. Make the Verify page the first page a new visitor lands on.
2. Once a user verifies a message, show a button that when clicked copies the verified message over to the Message textarea on the Sign page and changes the view over to the signing page.
3. If a user clicks on the Signed Message field on the Sign page, make the entire cell highlight so it can be easily copied for pasting into a sheet.
4. Change the private key field to display *****s when it’s filled in and create a Show button that toggles the display of the private key.
-----BEGIN SIGNATURE-----
1BbgnPQYeXAt39ifLNUWP1RBktpzGLmRZS
IHgKhIpPFYfSs1Mi19OAZQlTOeqIV4oNdyE/7uVLIM6YtFsWg1VqFZ84+sIXAMk8C88dPuOB9gGGLKAQmxBo2c8=
-----END BITCOIN SIGNED MESSAGE-----

-----BEGIN BITCOIN SIGNED MESSAGE-----
Job Name: Python module for signature verification
Job Creator’s Public Key: 03FB2CA1B513858CD8461AE875BA7096CB7D585C29E7C6B5294FEF7B6C326389C4
Mediator’s Public Key: 04594f2582c859c4f65084ee7fe8e9ec2d695bb988a3f53db48eaaff6ff3a0282b2be0c79fefca0 1277404d0fdc3a923e8ed02efd6ab96980f3e229a81fbe032e9
Category: Software Development
Job Description: The signatures on the Users sheet are signed manually by users before they add their signature as reviewer or auditor. We need the following few python functions that can validate the various signatures on the Users sheet. Please include a script that will test the functions.

validate_enrollment(enrollment_signature_text) - validates the ECDSA signature on the Enrollment signature as valid/invalid. also checks that it was signed by the master signing key within.
Returns an array with:
* true/false bool that signature verifies and uses specified master signing key
* signing key

validate_review(reviewer_text) - checks the outer signature on a review.
Returns an array with:
* true/false on the signature verification
* signing address
* text of message that was signed (everything between ----BEGIN BITCOIN SIGNED MESSAGE----- and ----BEGIN SIGNATURE-----) with the dash-space removed from the beginning of the internal ----- lines. This should enable the message to be verified by validate_enrollment.
 
validate_audit(auditor_text) - checks the outer signature on an audit
Returns an array with:
* true/false on the signature verification
* signing address
* text of message that was signed (everything between ----BEGIN BITCOIN SIGNED MESSAGE---- and ----BEGIN SIGNATURE----) with the dash-space removed from the beginning of the ----- lines for ONLY the outermost signature. This should enable the message to be verified by validate_review.

Please PM weex on bitcointalk.org with any questions.
-----BEGIN SIGNATURE-----
1BbgnPQYeXAt39ifLNUWP1RBktpzGLmRZS
Hz9gbXPhtSpLkNFVacvNADdb7cbiIL3aIzuCNGY6Mx+pekr5o58UVqcsomjGKCjqT3g3htnU87eAp8KrWFy5buE=
-----END BITCOIN SIGNED MESSAGE-----

Had a fair amount of activity due to offering 0.05 btc for people to pre-alpha test in https://bitcointalksearch.org/topic/m.12847456

Lessons learned from today:

1. At this point, we have 5 user records created. Each has been signed as reviewed but none has been signed the third time.

2. We'll need to write out guidelines on when it is ok to sign at the reviewer or auditor stages. Basically specify which fields in the template are required and how we can do some validation on them.

3. We also have a little chicken and egg problem in that if someone's user record must be reviewed and audited before they can act as a reviewer or auditor then we can never get there. So at the beginning, we'll have to relax that requirement. If you have a reviewer signature, you may act as an auditor.

4. The enrollment signature needs to be signed by a user's master signing key. This establishes a single point of authority for an identity.

5. Clearly a lot of validation can be done with a one or a few scripts taking the Users sheet as a CSV input. Getting those written might be the first jobs posted unless someone wants to volunteer. Basically take a CSV download and check all of the user records for consistency, if not the signatures themselves.

Thank you for checking this out!

Clarified and resolved those comments.

1. Reviewers and auditors are simply other users registered in the system at the beginning. Once some users have established a track record or we implement some kind of community multisig bond, we will limit those roles to some threshold trust score.

2. The second address is to pay the mediator for their dispute resolution services. The job creator chooses a mediator when they build their job in order to reduce steps. Mediators should specify their fee in the message they sign to establish or update their user record.

3. One step at a time. By establishing a protocol for how all this works, any number of applications or networks should be able to implement it and eventually we will have a p2p network with tor connectivity.

4. I don't think so but we can at least make it cost something. Either reputation or probably my best idea on this so far is to require an amount of btc to be locked in a multisig address with lots of members (like 10-of-15). Burning coins is another way.

Interesting project, I will follow, and perhaps help out with it if I have time. I can code, but only proficiently in java.

I left a few comments on the procedural outline which I would like you to look at. They are just clarification questions.

Also, I have few other questions:
1. Who are the reviewers and auditors and how are they determined?
2. Why must there be two addresses created and funded for each job?
3. How will this be decentralized?
4. Is there any way to prevent people from pretending to be multiple people at once? E.g. job creator is also the mediator or a reviewer for the same job.