WhoPays - Easily keep track of group expenses

[Nielsvdiermen]

Status Hackathon Submission

Type: DApp / Bot Github Repo: https://github.com/Nielsvdiermen/WhoPays Video: https://vimeo.com/221149759

Description: WhoPays is a bot made for the status Hackathon. It is an Ethereum blockchain decentralized payment solution for managing and solving expenses for groups of people. If you are on holiday, planning a project or living together you can make a list with everyone and add expenses. When you want to calculate the balance of everyone, the contract will do that for you. It will inform who still has to pay and who receives money. After everyone has paid, the contract will pay out to the people still owing money and the list will be closed.

A video of how it works can be found here: https://vimeo.com/221149759

Starting Design Description: A contract-based bot to create groups in which users can keep track of their payments for a group through commands with a new chatbot.

Use cases:

• When people go on vacation with a group of people and everybody pays some parts of the vacation (dinner, going out, events)
• A group of people living together where individuals buy groceries for the whole group
• You’re planning an event (lets say bachelor party!) and the friends who you’re organizing it with have multiple different expenses e.g. gas usage, food, drinks.

In essence it is a simple way for friends to keep track of who paid what during a trip, holiday or other period of time.

Users can add and resolve payments through status commands which get send to a contract on the blockchain. At the end of a duration when the contract needs to be resolved the creator can use a command to close the contract. The contract will calculate how much each user has to pay or receive. The contract will let the Status app know how much each user has to pay and can create Ether requests for this. When everyone has added their payments to the contract, the contract will send Ether to the users who still have to receive some. After that the contract is resolved.

What we would like to improve: Working with Status was difficult at times because the app is still quite new and is still being developed on multiple fronts. One of the biggest things we would like to improve in our project to really reach its full potential is the ability to simply add users to a list by selecting them in the address book. Right now we have to manually input Ether addresses and this is very user-unfriendly. What also is needed is the ability to automatically send messages to people in the list that they have joined the list. Right now users have to copy the contract hash to the other members of the list and manually join the list with the /join command and the hash.

While we really like Status and how it gives many new possibilities in the world of blockchain applications we feel that for this technology to grow there needs to a better link between cryptocurrency and “real” money. For WhoPays everything is Ether based so the user has to calculate how much Ether he/she has paid. A way to calculate between the currencies and automatically calculate it into the current Ether amount would be very welcome.

We would have loved to make the bot available in a group chat, so that every user can see who paid for what and there would be less traffic. The way this could work is to create a group with the people you want in the list and add the bot to the group. The bot would then create the list by commands and everyone can see what is being paid and what the current expense balance is.

Team Members: Preferred Name: Timon Github Handle: @nomitpi Slack Username: @pixel

Preferred Name: Niels Github Handle: @nielsvdiermen Slack Username: @nielsv

[ghost]

I'll be keeping an updated list below of what we did per day and how the Status API worked for us.

[ghost]

03 June - Saturday

@Nielsvdiermen Put his time in looking into the contract, we're creating it with the Truffle framework. It was basically coming up with the functionality we need in the contract and playing around a bit with it.

@nomitpi Put my time in setting up the dev environment. I had quite some difficulties because I didn't have the latest version of status-dev-cli, and the docs sometimes seemed to miss some parts (e.g. if you want to add the chatbot, you have to look at the status-dev-cli docs instead of the status docs). After that I started with creating the first command. This is the "get-started" command which shows the user how the bot will actually work. We think such a command is required to make it as easy and as user-friendly as possible for users.

Status API / Docs Feedback

• In the section My First Chatbot (http://docs.status.im/#my-first-1-1-chatbot) it says cd ~/truffle-box-status/public/ && mkdir bot/. I was unable to get this to work, and actually had to put my bot into the build folder. Might be a problem on my side, I haven't heard anyone else about this one (I have the latest status-dev-cli)
• In the section My First Chatbot (http://docs.status.im/#my-first-1-1-chatbot) there is no actual "status-dev-cli" add command, which I actually had to do before I could see my app.
• In the section My First Chatbot, users actually have to truffle serve their bot file and adb reverse their 8080 ports so the bot.js file actually gets served.

All of this is based on our knowledge of development, it might be that I'm just doing stuff wrong sometimes. :)

[andytudhope]

"In the section My First Chatbot (http://docs.status.im/#my-first-1-1-chatbot) there is no actual "status-dev-cli" add command, which I actually had to do before I could see my app" - incorrect. There is a status-dev-cli watch $PWD command at the end of that truffle tutorial. This will watch for changes and so load the js that tutorial tells you to put in the public directory. If you followed it closely (and look at the start script lines 43-44) you'll see why we recommend the public folder and try to encourage people not to mess around in build or with adding the bot themselves - that should all be done by the start script. Come and ask in the slack if you have further issues - we are always there to help and the tutorials have all been thoroughly tested.

[ghost]

Thanks @andytudhope . I'll be sure to check it out. Seems like I missed that. :)

[ghost]

I'm a bit behind with the updates, but here goes.

04 June - Sunday & 05 June Monday

@Nielsvdiermen Layed out the structure for the contract and started testing all the functions for flexibility and errors. Truffle gave some trouble in the beginning but I managed to overcome the issues. status-dev-cli posed problems with installing on Windows. But this is really a problem of node-gyp (https://github.com/nodejs/node-gyp/issues/629) which seemed solved, but I couldn't get it to work with the proposed solutions yet.

On Monday I finalized the contract for testing on Status. The contract functions for the alpha version of Whopays and can be extended with additional functionality after further testing. The trick tomorrow will be to properly setup Status to deploy contracts and handle the input!

@nomitpi I played around a lot with the ScrollView for the get-started function. Made some icons so we can easily explain what people can do with Whopays. After that I looked into the /create function, which users will need to create a list. I'm making quite some progress. Users can now type /create and it will create a list with a name which will store it in the localStorage (thanks to the latest version of Status in which it got added! :) ).

I made a list of all the commands we need.

• [x] /get-started (Show an overview of what the bot can actually do.)
• [x] /create Create a list with a name, this is just a command, save it in localStorage.
• [x] /add-user Select the list name (suggestions), add user (copy address), save to localStorage, return list name + users added in chat
• [x] /remove Removes a list with its users
• [x] /view Shows suggestions where you can select a list, on clicking it opens a ScrollView with information
• [x] /activate Activates the list, sends messages to the users that they’re tagged in a list
• [x] /add-expense Adds expense to the list, updates the user how much he has added
• [x] /remove-expense Remove expense from the list, updates the user how much he has now
• [x] /close Closes the list, sends messages to the users that the list is closed and how much they have to pay

Status API / Docs Feedback

• I tried saving stuff with web3.db.putString unfortunately, this command did not exist. Thankfully I read in Slack that localStorage got added, so I just had to download the latest version and I had some storage.
• I'm having a weird bug where sometimes when I put debug On, and after that do status-dev-cli list --ip 192.168.2.3 it hangs. I still have to file an issue for this.

Other TODO's

• Think of a way how to close the list automatically once everyone has paid. The contract can close, but the users also need to be updated someway, how?
• File an issue for the hanging of status-dev-cli

[ghost]

06 June Tuesday

@Nielsvdiermen Contract testing and finalizing has finished today. The goal today was to get the contract working in status where users can create their own contracts through chat commands. So far we have ran into a couple issues but we are close to succeeding.

@nomitpi I spend my time on the /create, /add-user, /remove commands. I save everything in localStorage temporarily. It seems to work fine. /add-user uses sequentialParams, which is a really nice feature to guide the user. I'm currently gonna focus on the /view and help @Nielsvdiermen a bit with getting the contract working in Status. Let's hope everything goes as planned!

Status API / Docs Feedback Debugging proves difficult with logging not working correctly. This is currently only supported on a return.

@Nielsvdiermen Also I work on windows and when I make a change in the app I have to close down the app on my phone and open it up again before I see the change. very time-consuming. Documentation states some web3 commands to get a contract running in the app but these are directly copied from the web3 documentation and are confusing. For example the require("fs") in contract creation.

[ghost]

08 June - Wednesday

@Nielsvdiermen worked on implementing the contract into Status and getting the deployment properly working. We had to compile the abi and bytecode outside of status because status does not seem to support the functions needed to process compiling.

Furthermore I upgraded the contract to support actual ether payments to close a contract. Now that we have the contract fully working in Status we have to update our commands to fit the contract functions and we are close to being done.

@nomitpi I spend my time on creating the commands we need to interact with the contract. I changed my localStorage stuff to actually contain JSON instead of strings, which keeps it more maintainable and I got rid of a few bugs that way. I also focused on deploying the contract on Status. We finally got it working in the end and we're now onto calling the contract functions and making sure everything works nicely!

Status API / Docs Feedback

@Nielsvdiermen Status will not properly update for me when I make changes, I don't know whether it is because I use Windows but we have to process everything through @nomitpi 's phone. Also when you make an error in the code the bot simply stops working, it would be nice to get some kind of error message back. Now it can be hard to find the problems.

@nomitpi I struggled alot with getting the contractHash once a contract was deployed. This was mainly because the callback didn't trigger twice. Also setTimeout, web3.eth.filter.watch or setInterval didn't work within Otto VM. Would be cool if that gets added!

[ghost]

09 June - Thursday

@Nielsvdiermen @nomitpi Today most of our work was in sync as we combined our status bot functions with our contract functions. We got everything working as we wanted and were able to test out our bots full workflow.

We also cleaned up all the messaging and logs that get displayed to the user and adapted the contract a little bit to support some new functionality. All in all we're very happy that our bot fully works and now on to preparing to deliver the final result.

Status API / Docs Feedback It seems the nightly of Status works better on my phone, I was able to test much easier. I still have to close the app and start back up to see the changes however. Not being able to select or send messages automatically (with web3.ssh) to other users seems to be part of the core functionality of Status and I thought it was available for this hackathon. We can improve our usability by alot if we implement that, but we worked around it for now. :)