Topic: [ANN] Rein - Decentralized Freelance Market (Read 10556 times)

Suggested user experience improvements for Rein:
 - Explanation of bitcoin, somewhere.
 - Making verification of escrow easy (say, generated URLs that the user can click and see if the addresses are funded).
 - Desktop / e-mail notifications.
 - Would love to have more direct access to user wallet createntials - digging in db's is not something the user should ever have to do.
 - Built-in update system, maybe?   
 - Perhaps some sort of profile for users, so that others can see their previous jobs, portfolio links, etc?

Edit: These have been included and prioritized into the above Q2 roadmap

Development Roadmap Q2 2017

Usability / UX (ordered by descending priority)
    Support manual payment amount. This allows for fiat-based pricing
    User lookup - get enrollment from server by SIN, master, or delegate key
    Mediator collect/presign payment
    Email notifications
    Show/hide delegate or payment keys/xprvs for import into other wallets
    Enrollment updates
    Previous jobs, portfolio links (with strong warning) on profile user profile page
    Explanation of Bitcoin, link to FAQ, help docs
    Mediator search

I18n
    Translate web interface

Mobile App
    Android app based on http://imgur.com/a/nDpXW

Client-side encrypted mode
    Chrome extension

Network efficiency
    Client helps share docs between servers

Safety
    Links to discussion forums about trust/ratings issues

Privacy
    Enable bids and later in order flow to be encrypted for decryption only by parties to transaction

I think we're good for now since I have the messages.po file. If you want to take all of the translations and get them into the i18n branch, pm me and I'll send them to you.

hey man, do you want help in translating app to Spanish?

Updated roadmap.

Look very promising and active. Good luck with your project!
If you need any help, just let me know.

Development Roadmap Q1 2017

Mobile App
   Android based on http://imgur.com/a/nDpXW
   iOS app based on http://imgur.com/a/nDpXW - In process  
 
Usability
   BIP32/BIP39 - Done
   Easier final payments - Adding a wallet feature that builds, signs, and sends transactions via choice of third-party API. - Done
   Explore client-side encryption - In process

I18n
   Make app translatable - Done
   Primary languages of Philippines, India, China, Nigeria, Ukraine, Latvia,  and Thailand - In process

Safety
   Begin on reputation system, generate SIN - Done
   Enable user to rate others referenced by job - Done

Network efficiency
   Client helps share docs between servers

Privacy
   Enable bids and later to be encrypted for decryption only by parties to transaction
   Change doc format to json

Bitcoin Freelancing & Dogfooding Rein
https://medium.com/@dsterry/bitcoin-freelancing-dogfooding-rein-ba78937757ba#.qwuuc8k33

Current funding needs
~0.5 BTC for BIP32/39 in setup process
1.5 BTC for mobile app prototype
If you wish to help fund, let us know. Your donation can go directly into a multisig escrow for a specific job.

Timeline
Oct. 2015 - Planning begins
Jan 2016 - Alpha tagged, command-line version
March 2016 - First transaction completed - a digital painting
May 2016 - Tor support
Oct 2016 - Web-based user interface

Still looking for more devs. Also someone with experience in management and growth of free open source software communities. If you know anyone, please stop by #Rein on freenode IRC.

Posted a new job for any of you python devs out there to help improve Rein's document sharing among servers. Budget is 0.1+ BTC.

Released v0.2.0-alpha.

Changelog:

* GUI for identity setup and for job creators (post, offer jobs, accept deliveries, file disputes)

Added nice article with updated pics of some stuff by BetByBitcoin: Review decentralized freelance market – Rein

It looks good perhaps we'll try it

Tor Support
Added Tor support to the Python-rein client. To get it, just 'git pull' and run 'python setup.py install'.

Then enable it with 'rein tor true'.

Finally, it's setup to use the default address and port provided by the Tor browser so from there on it should either work or throw an error that the socket cannot connect.

If anyone wants to review the code that added it, I'd greatly appreciate the extra eyeballs on the code. https://github.com/ReinProject/python-rein/pull/50

Time awareness in Rein using Bitcoin Core powers
In the last weeks, the server and client have both become time and blockchain aware. In short, the server connects to a local copy of Bitcoin Core to start providing latest block hashes and times for clients to include in their contracts. Thusly, the blockchain's time keeping can be used easily to enable expiration and updating of mediator availability, job postings, and bids.

Scheduled a Blab for Thursday March 24th at 8pm PST if anyone has questions or wants help getting setup.

https://blab.im/david-r-sterry-decentralized-freelancing-with-rein-ask-questions-get-setup-chat

The tech talk last night was a ton of fun and thank you for everyone that logged on for it.

Thinking about hosting a blab.im session sometime this week to talk about Rein and help anyone who wants to get setup. Anyone interested?

Oh, I like Spectacle! Thank you!

I'm trying to install Rein the Debian way; I'd have a question: why have you chosen Python 2.7, instead of Python 3? If I'm not wrong all dependencies are available in a Python 3 version, and packaging Python 2 applications could be problematic very soon.

[EDIT]
https://github.com/ReinProject/python-rein/issues/40
[/EDIT]

Ciao!

A little update. Rein has now seen it's first job posting for a web template by a new user of the protocol.

This can be seen at the simple job listings at http://rein1-sfo.reinproject.org:5000/jobs

Also, that same user Flamcake has bid to tackle the Rein theme song and that bid has been accepted!

weex, Mike Christ and bitspill: congratulations, you made history!

The first transaction is 100% complete: 0.2 btc for this graphic by mickmarona, mediated by bitspill https://i.imgur.com/84Px8y3.png

Even got a writeup by Bitcoinist! http://bitcoinist.net/the-rein-project-completes-first-freelance-contract/

Today is a great day. Digital artist Mike Christ has bid and his bid accepted for a digital painting for Rein Project itself! The job is for 0.2 BTC and 0.002 BTC will go to mediator bitspill at conclusion of the job.

Here is the offer which when funded made for Rein's first official in-process job!

Brave New Coin did a pretty thorough story. Great to see the freelancing market stats in it. http://bravenewcoin.com/news/bitcoin-only-decentralized-marketplace-rein-targets-growing-freelance-industry

Since Bitcointalk user bitspill signed up to be the first mediator, the first job has been posted.


Though it's not shown, bitspill's fee is 1% which the job creator pays on top of an accepted bid amount.

Added new setup guide:  How To Setup Rein to Start Earning Bitcoin

Python-rein Data Model

https://github.com/ReinProject/python-rein/blob/master/README.md is probably the best written document on this right now. Otherwise, the second video in this playlist goes from git clone through to setting up an account. Note, there's no GUI so you should be comfortable with CLI if you want to get going at this stage.

An installation guide would be much appreciated.

Just posted these four videos that take you through Rein and the commands available in the alpha.

The first alpha release has been tagged. To get setup, see https://github.com/ReinProject/python-rein/blob/master/README.md

Posted a new README at Python-rein as I'll probably be tagging the first alpha tomorrow.

https://github.com/ReinProject/python-rein/blob/master/README.md

It's been a great couple of weeks. Most of the basic commands have been built out on both client and server side. Just in the last 24 hours, I've got some redeem script checking and building in with some testing so there may not be any need to use external tools beyond the Bitcoin-signature-tool at alpha release. I want to get a version out with a walkthrough video so interested folks can test it out this month.

Updated OP to show the two main python software repos in development.

Software (pre-alpha development)
Python-rein client - Creates an identity, requests microhosting, sync's data to local Causeway server
Causeway Rein server - Grants microhosting space, ECDSA signature auth, stores and returns key/value pairs

To help test or develop, download both of the above and run the server on port 5000. Run 'rein setup' and use the address/key pairs on this sheet for testing. Then run 'rein request localhost:5000' and 'rein sync' to try to store the enrollment message you signed on your Causeway server. (last updated Jan 2nd, 2016)

Sure. I really like DropZone's launch as a command line tool so the past couple weeks I've been focusing on a command line interface that sets the user up with a new account and requests free microhosting from a test server. That much is working now. Next is to store a single record to said storage, then to each of a set of servers. You can follow my progress or join in if you have python skills at https://github.com/ReinProject/python-rein

Any updates?

Some mockups of an app in locally-saved-webpage form: http://imgur.com/a/eGT5r

Any JS/Front-end wizards want to take this on? PM me.

A quick update, a backend prototype is coming together in the form of a key/value server that uses the 21 wallet for authentication and payment for microhosting. That software can be found at https://github.com/jgarzik/playground21/causeway

There is a $100-150 bounty to implement a microhosting server at https://bountify.co/create-a-bitcoin-enabled-key-value-storage-server You've got 3 days to deliver something decent or that cash goes to charity.

Speaking of the server. I got my 21 Bitcoin Computer and have been spending this weekend developing the above microhosting server on their platform. Only some basics work like verifying the signature on a request for a deposit address, requests for pricing and status. Since it's using the two1 library, support for offchain transactions via 402 payment required messages will be working shortly.

One could buy a year's worth of hosting suitable for ones own records for Rein with a few days of mining. After all, the storage requirements for the dozen text files most Rein users would need are minimal.

On the front end, I am looking to introduce more of a workflow around the bitcoin signature tool. While signing with master addresses should be done offline, there's no reason the initial setup (an intake form, choosing microhosting servers, and getting unspent outputs) can't be done online. Then that that information can be package so the signature tool can do the rest offline (e.g. create transactions for payment and signed enrollments).

I'm working now to improve the availability and resiliency of state for the protocol. That is, shaping the incentives so people can post jobs or listings for themselves and pay to keep that data available in a professional yet decentralized manner.

Today, I've been working on a sort of microhosting where as a user is first setup, they are provided with a list of servers that are willing to host their records (user, bids, offers, disputes) for a year for a very small price (like $0.25). So the signup process (done offline via a javascript tool) would build a transaction paying N of these providers. The tool would then make it easy to sign and upload the current action (update of their user record, placing of a bid) to each of these servers.

Here's a draft spec on this: https://github.com/ReinProject/causeway/blob/master/spec.md

Coinb.in now has pull request that will support our Mediator payment transactions.

For each job, a Mediator holds a third key to the 2-of-3 multisig escrow address. In order to get the Mediator paid, we also create a second address with a little bit different construction. For that address, the Mediator must sign the redeem script to move the funds; a signature from the buyer or seller is also required. This way the buyer and seller can't cut the Mediator out of their payment, which could be substantial in cases where Mediation requires more than just dispute resolution. For example if a Mediator is functioning like an oracle / supplying material information to the transaction / or must do some testing for their part. The pull request that extends Coinb.in with these Mandatory Multisig transactions is here: https://github.com/OutCast3k/coinbin/pull/30

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.

Offering 0.05 BTC for help with this today. https://bitcointalksearch.org/topic/m.12847456

Added a couple of sheets demonstrating what the signature chains look like.

Spreadsheets (please see the detailed walkthrough for context):

Signatures Demo
Users

Rein is designed to help you conduct freelancing transactions safely and easily. Clients can post jobs to Rein's decentralized network and freelancers can submit bids on available jobs.

As of now, the best use of Rein is to build, fund and manage multisig escrows to ensure each party gets what they want in a job. Along with the escrows, job descriptions, bid amounts, and timing are cryptographically signed by participants to a job. That way, if anything goes wrong the mediator can pay out or return funds as necessary.

The Mission:
Create a decentralized market to enable people to work and have work done in exchange for bitcoin. Learn more...


Setup Guide
HOWTO: Setup Rein


Development Roadmap
We have a few tasks on our development roadmap for which we're looking for developers. Since we want to help grow the Bitcoin development community and many devs are interested to grow their skills, we've been able to do a ton with not a lot of funds.

If you can help with funding, PM me. Your donations can go directly to escrow for specific features.

Timeline
Oct. 2015 - Planning begins
Jan 2016 - Alpha tagged, command-line version
March 2016 - First transaction completed - a digital painting
May 2016 - Tor support
Oct 2016 - Web-based user interface
Nov 2016 - Rein is used for several jobs to improve Rein per the development roadmap
Feb 2017 - v0.3.0 Beta released with bip32 setup, transaction sign&send, ratings


Press
Bitcoin.com: Bitcoin Freelance Marketplace Rein Launches in Beta
Bitcoinist: The Rein Project Completes First Freelance Contract
Brave New Coin: Bitcoin-only decentralized marketplace, Rein, targets growing freelance industry
BTCManager.com: Rein’s Experiment in Decentralized Labor: An Interview with David Sterry
BetByBitcoin: Review decentralized freelance market – Rein


Software
Latest release: v0.3.0-beta
Python-rein client - Client for Rein.
Causeway server - Run a server and get paid for providing microhosting. Grants microhosting space, ECDSA signature auth, stores and returns key/value pairs. Also responds to queries for specific types of documents like job postings, bids, deliveries, or all documents by job ID.

To get setup see the README for python-rein: https://github.com/ReinProject/python-rein/blob/master/doc/HOWTO-setup-rein.md

For more info, see: https://reinproject.org