Status Hackathon Submission

Type: DApp
Github Repo:
Description:

Team Members:

Status Hackathon Submission

Type: bot + wallet smart contract
Github Repo: https://github.com/21m/status-im-hackathon

Description:
the idea is a wallet that grants access to another party after the primal wallet user doesn't respond (e.g. is deceased) for some time.
this will involve:

wallet smart contract
a normal wallet contract which saves the date of last activity
if last activity reaches a threshold it will grant access to another user (e.g. heir)

chatbot
will help in setting up the wallet
will contact the user if last activity is greater than a few days
every time the user interacts with the chatbot, the last activity in the wallet will get updated

Team Members:
Preferred Name: Basti
Github Handle: @kannix
Slack Username: @kannix

Status Hackathon Submission

Type: DApp

Description:

TBD

Team Members:

Preferred Name: Josh
Github Handle: @joshuabell
Slack Username: @joshua

Gifhive - Decentralized GIF sharing

Type: DApp
Github Repo: https://github.com/iSasFTW/swarm-gif-share
Description:

A small dapp that lets the user post a GIF with a caption, and share it with other users quickly over Swarm. (+ Szabo tipping functionality)

Demo video: https://youtu.be/fl3yzHerfsY

Team Members:

Preferred Name: Saska
Github Handle: @isasftw
Slack username: @isasftw
Twitter handle: @isasftw

Status Hackathon Submission

Type: tbd
Github Repo: tbd
Description: tbd

Team Members:
Preferred Name: Scott
Github Handle: @sprusr
Slack Username: @sprusr
Twitter Handle: @sprusr

Status Hackathon Submission

Type:
Github Repo:
Description:

Interactive pet bowls.

Team Members:

Preferred Name: Blubeast
Github Handle: @BluBeast
Slack Username: @BluBeast

Status Hackathon Submission

Description: A bot (but currently more like a dapp) allowing easy participation and initiation of auctions for ENS domain names.
GitHub repo: https://github.com/Legogris/ensbot/

Video: https://www.youtube.com/watch?v=mUtxNbbs0jU

Team Members:

Preferred name: Jeff
Github handle: @jefflau
Slack Username: @jefflau

Preferred Name: Legogris
Github Handle: @Legogris
Slack Username: @Legogris

Our original ambition was to make a pure, client-side only chatbot. Due to restrictions and snags, we had to add in dapp-components to make it work. Interfacing directly with the ENS contracts on Ropsten.

Currently working:

• Checking status of domain name
• Initiating auctions for unclaimed ENS names
• Placing bids in active auctions
• Revealing bids for placed bids

Challenges faced:

• Unable to use local testrpc for chatbot
• webView and bridgedWebview as doesn't render when used as previews for commands
• No eventloop for bots (so no setTimeout, no AJAX requests)
• sendMessage not working initially
• No localstorage to remember parameters
• Android bridgedWebview doesn't send Accept header, which makes webpackdevserver's historyFallback fallthrough silently, resulting in 404.
• Generally very spotty integration with add/update/watch dapp/bot, as well as webview rendering. Sometimes it works, sometimes it doesn't. Server always seems to receive request, but then it doesn't render.

Status Hackathon Submission

Harmony - Decentralized Events

Type: DApp (mobile)
Github Repo: https://github.com/xharmony/harmony

Description: Harmony is a DApp for managing decentralized events on the Ethereum blockchain. Events such as meetups, music festivals, conferences, demonstrations, etc can be contributed to by anyone making the events more resilient, transparent, efficient, and open. Everything from voting on locations, performers, ticketing, asset management etc will be available.

Team Members:
Andrew Reedy
Github: @andrewreedy
Slack: @andrewreedy
Twitter Handle: @andrewreedy

Status Hackathon Submission

This awesome and useful chat bot definitely deserves 1st place.

Type: perhaps bot

Github Repo: TBD
Description:
First rule of races - do not tell what is your advantage until it is too late.

Team Members:
Mr. @ta20170412
PM me if you want to join.

Status Hackathon Submission

Type: DApp
Github Repo: Babel Repo
URL: Babel
Description:
Babel is a decentralized e-commerce platform that hopes to eliminate redundant and inefficient services fees along with the middleman.

Team Members:
Preferred Name: Bill Hinostroza
Github Handle: @billh93
Slack Username: @Bill
Twitter Handle: @djhiphop23

More Notes:
This project is open source so anyone is welcomed to contribute to the development. Contributors will most likely be compensated for their efforts down the road as Class A contributors or possibly even higher roles depending on contribution.

Status Hackathon Submission

Type: DApp + Bot
Github Repo: https://github.com/BlockchainLabsNZ/Unconf-DApp

Description:
A way to gather a community to plan an Unconference with a few smart contracts providing a lightweight governance model.

Why:

1. Because the Unconference format aligns very well with the decentralized Blockchain philosophy.
2. Because Status.im enables the group chat collaboration and location discovery to bring this DApp to life
3. Because BlockchainLabs.nz and Blockchain.org.nz are planning a Blockchain Unconference later this year ;)

What:
At a minimum someone should be able to create an Unconference event with a location & date for it to be discoverable in Status.im. People should be able to register (free or paid) and be added to a group chat for collaboration. People should be able to suggest topics they would like to share, and then let others upvote the suggestions.

Team Members:

Preferred Name: Paul
Github Handle: @salis
Slack Username: @salis
Twitter Handle: @paulsalis

Preferred Name: Klaus
Github Handle: @Janther
Slack Username: @Janther
Twitter Handle: @KlausHott

Preferred Name: Isaac
Github Handle: @IsaacPayne
Slack Username: @Isaac2

Status Hackathon Submission

Type: DApp / Bot / Commands,
Github Repo: Not created
Description:
placeholder

Team Members:

Preferred Name: DJ
Github Handle: @thedewpoint

Status Hackathon Submission

Type: Bot
Github Repo:
Description:

A super awesome bot ... tbd on what this little bot will do.
Team Members:
For each team member please fill out:
Preferred Name: Richard
Github Handle: @richardxlin
Slack Username: @richardxlin
Twitter Handle: @richardxlin

Status Hackathon Submission

Type: TBA
Github Repo: TBA
Description: TBA

Team Members:

Preferred Name: NPE
Github Handle: @NPException
Slack Username: @NPException
Twitter Handle: @NPException

Status Hackathon Submission

Type: DApp
Github Repo: https://github.com/jacintos/status-hackathon
Short Demo Video: https://www.youtube.com/watch?v=SUp7s5xtZTk
Description:

There are lots of problems around how to pay when you're out with friends. You find out the bar or restaurant is cash only. Bummer! Now you have to leave and find an ATM or convince your friends to move to another spot. Likewise, say a place takes credit, but they set a limit on the number of credit cards your party can pay with. Boo! Split the Tab solves these problems by 1) dividing up the bill and telling everyone how much they owe and 2) settling IOUs on the spot, immediately.

Challenges:

This dapp is based on Truffle Box React and the entire dapp was built during this hackathon. This was my first time working with React and ES6 along with Solidity and Status! I had heard good things about Redux, so I threw that in because, why not? Redux-Saga? Sounded cool.

I met the real challenge on the last day of the hackathon. Until this time I had spent all my time on UI. I started with Firebase as the backend, with the intention of switching it out for a Solidity contract, once the UI was in a good spot. Writing and debugging Solidity in Remix was easy. I spent a lot of time trying to understand how to transact and query with truffle-contract. I had no luck getting truffle-contract to work with Ropsten (though I did not have a fully-synced local RPC, to be fair). When it came time to integrate the dapp with my Solidity contract, I ran into issues running it within Status. Unfortunately, I did not have access to a Status build that allowed Remote Debugging webviews. Debugging with adb logcat was not getting me where I needed to go, so I left Firebase as the backend instead of a Solidity contract, for this submission.

The contract was deployed to Ropsten here: https://ropsten.etherscan.io/address/0x4a0a0853599c083ee0ffff0df938dd363f2a6d5a

Future Ideas and Work:

Sharing the short tab ID among friends is ok, but pointing the phone at a QR code is a better user experience. Status may consider conditionally allowing dapps access to the camera resource to make this possible. Powering the dapp with a Solidity contract is the ultimate goal. For the best user experience, e.g. to minimize transactions, there will need to be some UX workflow changes. Users would want to view a history of their past tabs. Geolocation could be tied in there, providing both user and business utility.

Team Members:

Preferred Name: Jacinto Shy
Github Handle: @Jacintos
Slack Username: @jshy3
Twitter Handle: @morpheism

Status Hackathon Submission

Blockpass - Decentralized Password Management

Type: DApp (mobile)
Github Repo: https://github.com/blockpass/blockpass

Description: Blockpass is a decentralized password manager. Similar to LastPass except the user owns their own the keys and has full control. The first iteration will be a web app and Chrome Plugin.

Team Members:
Andrew Reedy
Github: @andrewreedy
Slack: @andrewreedy
Twitter Handle: @andrewreedy

MeDao

Github Repo: https://github.com/ChicoBitcoinJoe/MeDao

Description: This DApp is a new iteration on an idea I call a MeDao. This MeDao lets the creator sell a limited amount of time shares each week and in return is expected to burn a certain amount of tokens as proof of work being done. Some MeDaos may opt out of the burn function altogether. The end goal of this DApp is to give the MeDao creator a free market price for the value of their time. Uses a MiniMe Token for easy and efficient cloning and upgrading.

Functionality includes: set work hours, place and remove a bid to auction, accept the highest bid at auction, and submit proof of work. Some functionality may require a browser refresh in order to update properly.

Temporary Website: http://medao.azurewebsites.net/#/home

Team Members:

Preferred Name: Joseph
Github Handle: chicobitcoinjoe
Slack Username: @ChicoBitcoinJoe
Reddit Handle optional: chicobitcoinjoe

Type: DApp, PoC of Unity3D and Ethereum, happily married by status.
Github Repo: https://github.com/floAr/Etherenity (Dapp) & https://github.com/floAr/Etherenity_Unity (internal Unity project)
Contract Code: https://ropsten.etherscan.io/address/0x507e049d16c2827ccf603aa2fd882d4a93bec25e
Description:
Unity3D is one of the biggest game devloper platform when it comes to mobile games. We at ThreeEyedGames feel tht is important to keep pushing out boundaries and not only to create great games, but also to shape the tools and the technology we are using.
We feel like Ethereum can provide a huge benefit and novel aspects to the filed of mobile gaming and want to enable developers withing Unity3D to harness the power of Ethereum through Status.

Web Demo: https://floar.github.io/Etherenity/

What has been done
This prototype shows the connection between a Unity 'Game' (Not to much gaming around, due to time constraints) and Ethereum through Status. A simple contract is deployed on Ropsten to allow users to register themself with a nickname.
This is the base foundation to build a strong Unity <-> Ethereum connection with Status and allow developers to take advantages of truly decentralized services.
Some key concepts were a bit harder to implement with Unity service oriented approach. For now unity uses the web3 instance provided by status through the webpage. This means that calls are routed between webpage and unity container. In a current version, which is sadly not yet bug free this is replaced by a Unity internal interface, which can then bind to status' web3 or metamask or any native provider. This allows the interaction with Ethereum from within Unity, enabling a seamless flow for the developer.

Why is this interesting

• Mobile games dominate the game market today.
• Unity allows to easily (most often one-click) deploy a mobile game to web
• Ethereum allows developers to take advantages of middleman-free services like:
  • Matchmaking
  • Trustless Highscore / Rankings
  • Username / Login system
  • Competitions

Challenges faced

• Some minor fate related fuckups: phone broke down, windows 10 is not willing to play nicely with some android emulation and so on
• Unity3D WebGL maturity: While most of the features are there already some minor quirks still exist -> Some data is mocked up now and helper functions are used to skip these steps
• Time constraints: Due to business trip only the weekend was available. This leads to the API, while beeing sketched out on the whiteboard, still beeing a bit hacky implemented and to general feature scarity

What is the roadmap
The aim of this prototype is to mature into a fully fledged solution for Unity developers. Due to Status connection to Ethereum it is possible to allow non-crypto-averse developers to access and harness the power that come with a decentralized approach.
We are currently working on this in our free time, any monetary grant would allow us to spend more time and push this harder.
Possible collaborations with other Ethereum base game services are on our radar and can also greatly benefit from a smotth Unity integration.

Team Members:
Preferred Name: floAr
Github Handle: @floAr
Slack Username: @floAr
Twitter Handle optional: @florianuhde

Come visit us at: http://three-eyed-games.com/

Status Hackathon Submission

Type: Ethereum Chatbot
Github Repo: https://github.com/tcsiwula/status_global_hackathon
Description: A chatbot that will let you place orders to purchase Ethereum through the messenger platform and coinbase api.

Team Members:

Preferred Name: Tim
Github Handle: @tcsiwula
Slack Username: @tcsiwula
Twitter Handle: @tcsiwula

Preferred Name: Josh
Github Handle: @joshuabell
Slack Username: @joshua
Twitter Handle: @__joshuabell

Preferred Name: Zane
Github Handle: @ZaneWithSpoon
Slack Username: @ZaneWithSpoon
Twitter Handle: @ZaneWithSpoon

Status Hackathon Submission

Type: DApp
Github Repo: https://github.com/gjeanmart/hackathon
Description: DTS (Decentralized Tutoring System) or MyTutor is a decentralized app (dapp) that bring teachers/tutors and students closer.

I built this app to help my wife who works as a tutor and always find hard to get new students (she has to work with companies that take huge fees on each course), it's also hard communicate with students, manage the agenda, chase up for the payment, etc.
That's why comes MyTutor

The dapp is sort of assistant that allows teacher to publish an announce, the student can go through the ads and start chatting with a teacher (feature not available), after Q&A and agreeing a date, time and a price, the teacher can setup a course.
The student has to make a payment into the contract before the course.
Once the course is finished, the teacher ca either release the payment to his account or refund (if cancelled for example).
A chabot

This application is built with:

• Truffle
• Angular 2
• Ionic 2

Team Members:

Preferred Name: Greg
Github Handle: @gjeanmart
Slack Username: @gregj
Twitter Handle: @gregjeanmart

Status Hackathon Submission

Type:
Github Repo:
Description:

Team Members:
Name: Morgan
GH, S, T: @morgansliman

Status Hackathon Submission

Type: Dapp - New
Github Repo: https://github.com/vikas1188/WeLottify/blob/master/WeLottify.sol

Issues:
Unfortunately, dapps from remote server (non-localhost) are not able to make transactions on Status. Things are working on MetaMask.

Description:
As blockchain supporters, we want to help push mainstream adoption. The mandatory first step is getting users to create an identity and understand how to manage it. Wallets have been moderately successful in attracting first-time users because it involves money and finance. People learn quickly when there’s money on the table. As an extension of that, people become more social and excited when money is then used to take risks like investment or gambling like Augur and Gnosis. Although we do not condone gambling, we do believe in friendly bets and group lottery. Currently, small groups play lottery together without much of a legal framework. There are plenty of sample paper contracts online that can help groups operate better. However, once someone wins the jackpot, lawsuits are not uncommon. There is a better way to do this using Smart Contracts.

Introducing "Gnosis for Lottery".
WeLottify is a tool that allows anyone to manage a group lottery using the Ethereum blockchain.

Group lottery is not a new concept and neither is lottery using blockchain. Currently, there are sites that claims to use an internal independent algorithm to generate a lottery. There are also services that acts as the authority to buy lottery tickets and then sell seats to players with fiat and bitcoin. It is important to note that WeLottify are different in both ways:

1. by using existing lotteries, more people will understand it and more players will join because of the size of the jackpot from day one
2. by empowering existing groups to operate on their own, the risk is greatly lower as more consumers learn about the blockchain

Here’s how it works:

1. User creates a Pool by entering details like Name, Lottery (Powerball for now), Drawing Date, Number of Players, Service Fees, and select Public/Private
2. User becomes the Leader to buy the lottery tickets
3. Smart Contracts set a few timed conditions like group closed and upload Proofs time limit
4. Each player can join by committing the Ticket + Fee amount via Bitcoin to be held in escrow
5. If the number of players is reached before the closed time, the Fund is released to the Leader
6. Leader has 24 hrs to buy tickets and upload photos of Proofs to the blockchain like receipts, signed ticket front / back, etc.
7. After the drawing date, the Leader has the responsibility to claim the prize money and distribute equally to the group via bitcoin

Initially, we envision that WeLottify will be used in small local circles among family, friends, and co-workers where there’s already a high level of trust. As identity becomes better with more ways to validate them via verifiable claims etc, WeLottify can become a global phenomenon. Anyone in the world can play with peace of mind.

Why this is great for blockchain:

1. This is a great teaching moment for blockchain as more people will share among their networks and educate each other on identity and bitcoin
2. This can increase the market cap of Bitcoin as large winnings are distributed. Imagine a Jackpot of $375 million being converted into BTC.
3. There is an opportunity for wealth redistribution to help those in poverty as anyone can reap the monetary benefits of a first-world lottery. WeLottify wants to shake the world with the first-ever Powerball jackpot won using blockchain.

Looking ahead, there are many ways to make this better. On one hand, WeLottify will continue to improve trust by building user reputation with better identity and proof validations. On the other hand, WeLottify can make the game more fun and persuasive. Here are some ideas:

• expand to more lottery like MegaMillion, EuroMillion, etc
• in addition to Leader, allow Buyer where user / group can hire them to buy tickets and mail it. Powerball allows anyone to play. They just have to have possession of the real ticket.
• create ways for players to pick numbers and play them

Team Members:

Preferred Name: Tom Nguyen
Github Handle: @mrtomnguyen
Slack Username: @tomnguyen
Twitter Handle optional: @mrtomnguyen

Preferred Name: Vikas Singh
Github Handle: @vikas1188
Slack Username: @Vikas

Type:
Github Repo:
Description:

Team Members:

Status Hackathon Submission

Type: Bot+Bot-Infrastructure
Github Repo: https://github.com/ksjogo/status-hackathon
Description: TBD

Team Members:

Status Hackathon Submission

What we should call you when you win? Jeremy
Type: bot "/angryclouds weather today"
Github Repo: https://github.com/spdz/angryclouds.eth
Description:
To provide a decentralized weather chatbot on status.im that responds to /angryclouds or /weather commands

Team Members:

Preferred Name: Jeremy
Github Handle: @Spdz
Slack Username: @Spdz
Twitter Handle optional: @_spdz

RegisterEth ChatBot

Type: Bot
Github Repo: https://github.com/adamdossa/RegisterEthBot
Description: Bot to allow provable and trustless association of social media handles with Ethereum accounts

Team Members:
Preferred Name: Adam
Github Handle: @adamdossa
Slack Username: @adamdossa

Video Demo:
https://youtu.be/ebUiV_DWTNE

NB - this bot needs @rasom latest fixes from:
https://github.com/rasom/status-react/tree/jail-improvements
I have added the relevant .apk that @rasom provided to my submission.

Fixes needed were to allow command / response interactions for better chat mechanics.

I have listed some of my feedback on the Status Hackathon Slack channel.

RegisterEthBot (Status Hackathon)

This bot facilitates communication with a collection of Smart Contracts (deployed on the Ropsten Ethereum blockchain).

This collection of Smart Contracts allows users to associate their Ethereum addresses with a number of different social network handles.

Currently implemented are Registrar contracts for Reddit, Github & Twitter - the framework provides straightforward interfaces to allow other new Registrar contracts to be implemented for additional social networks.

Registration

Registration is a two step process.

Step one generates your proof-of-handle by posting your Ethereum address from your social media network.

Step two is sending a blockchain transaction with that proof-of-handle. The Registry smart contract delegates validation of your proof-of-handle to a Registrar specific to the social media network. Generally this will use oraclize.it to validate your proof-of-handle off-chain.

The proof-of-handle varies depending on the social media network - currently we have implementations for Twitter, Github and Reddit. It is easy to add new registrars for additional social media networks!

1. Post your Ethereum address using your social media handle. For the currently implemented registrars this involves:

• Twitter: tweet out your Ethereum address from your twitter handle.
  Your twitter handle is then your proof-of-handle.

• Reddit: post to /r/ethereumproofs a message containing your Ethereum address.
  The little hash in the URL linked to your post is your proof-of-handle.
  e.g. for:
  https://www.reddit.com/r/ethereumproofs/comments/6gkk1w/0xdaf383e889e15e3615db17d1f86422f2bda539f2/
  your proof-of-handle would be 6gkk1w

• Githib: create a public gist with your Ethereum address in the description.
  The generated gist ID of your gist is your proof-of-handle.
  e.g. for:
  https://gist.github.com/adamdossa/cbcc239a915800bfc96d60f1f8ceeb45
  your proof-of-handle would be cbcc239a915800bfc96d60f1f8ceeb45

2. Send a transaction from your Ethereum address to the Registry contract, along with your proof-of-handle which is used by the relevant Registrar contract to validate your proof.

Architecture of Smart Contracts

There is a single Registry contract (implementing the RegistryI interface). This contract is responsible for holding mappings between Ethereum addresses and social media handles (partitioned by social media network, e.g. Reddit, Twitter).

The Registry contract allows Registrar contracts (implementing the RegistrarI interface) to register with it. A Registrar contract is specific to a given social media network, and is responsible for implementing behaviour necessary to prove that a given social media handle owns an Ethereum address. Usually this is done via an Oracle service (using Oraclize) to check the evidence provided in 1. above.

When a user wishes to register a new social media handle, they would call the Registry contract specifying their proof (used by the Registrar contract to check 1. above).

The Registry contract can then be used to query your handles, and the handles / Ethereum addresses of other users.

Status Bot

It is possible to issue the following commands:

/details - shows the details of how to generate the proof from 1. above for each of the Registrars (currently Reddit, Github & Twitter).

/whoAmI - shows your social media handle (if registered previously).

/latestUpdate - shows the most recent update issued by the Registry contract that relates to your address. Can be used to track the status of your registration request(s). This is done by polling Ethereum events, so takes a couple of seconds.

/register - allows you to register your Ethereum address with any of the provided registrars.

/nameToAddress - shows the Ethereum address associated with a provided social media handle.

/addressToName - shows the social media handle associated with a provided Ethereum address.

Deployment - Smart Contracts

1. We need to deploy our smart contracts - this is done via the truffle framework:

• truffle compile - this will check our smart contracts compile and generate associated .json files.
• truffle migrate - this will deploy our contracts onto whichever Ethereum network is configured in truffle.js
• truffle test - this will execute tests against the contracts. Note - this needs to be run on testrpc.

NB - for the purpose of the Status Hackathon, we need to deploy our contracts to the Ropsten network as bots can only communicate with contracts on this network (i.e. they can't use testrpc).

Deployment - RegisterEthBot

This assumes you are using an Genymotion as your Android emulator:

1. Start Genymotion and Android emulator (following instructions as per Status documentation).
2. Open the Status app (if you've downloaded the latest nightly build .apk file, this can be dragged onto the Android emulator within Genymotion).
3. Log in / create a new user within Status, and in the Console app (in Status) execute /debug On.
4. In a terminal run status-dev-cli scan. You should see a couple of IP addresses - ignore the one which has "56" in it, and use the other below in place of .
5. In a terminal run status-dev-cli add --ip <IPADDRESS> to add your bot to your Status app running in the Genymotion emulator.

Contract Addresses

Registry: 0x195647cca7be636e03eee0af20b21745d06d7d12

RedditRegistrarComputation: 0x4237b97cf9a566d67b6ac254e2fc9cd645109e75

GithubRegistrarComputation: 0x86fb059a34fc326130a2a4ac274447559837dfa0

TwitterRegistrarComputation: 0x147cdec28faa359fcea7b83cae75e13d7996e93f

Status Hackathon Submission

Project Name:
Type:
Github Repo:
Description:

Team Members:

Status Hackathon Submission

Type: DApp

Github Repo:

Description:

Worldwide land speculation and land grab issues
There has been growing concern about so-called land grabs, when foreign governments, real-estate developers or multinational companies, buy large areas of land for farming or speculation. In 2012 the United Nations urged nations to adopt stronger guidelines to secure access to land, fisheries and forests for millions of poor people who have historically used the land. It is estimated that in recent years, about 200 million unregistered hectars, or 8 times the size of Britain, has been bought or leased, primarily in Asia and Africa.

In Tamil Nadu, the most southern state of India. We see how government struggles to fight growing speculation of agricultural land for illegal real estate use. Although having a land registry, government fraud and a lack of transparency, leads to farmers being driven from their ancestial lands for ridiculous low prices. Land that is then illegally sold as 'panchayat-approved', or planning permission given, to the highest bidder.

Experts claim that the best ways to fight land-grab and illegal speculation is to create so called Communal Land Associations (CLA). An instrument that empowers farmers by unionizing and creating legal frameworks; If land use is continouosly recorded formally, it is easier to appeal to court, and easier to verify ownership and permits for future buyers.

Chitta; blockchain and DAOs for collaborative support and impermeable records
We took up the challenge of creating an impermeable land ledger, but unlike other initiatives such as Bitland, we decided to use a community approach. Instead of transfering an existing – often tampered – government registry to the blockchain, we introduce a Dapp that allows everybody to claim a land token, but only commission a token after thorough verification using both factual knowledge – a question about the land, legal proof (if applicable) – a ID and registeration number match, and a social proof – other CLA members to vowe ownership.

If a token is issued, the holder will automatically become member of a regional Communal Land Association. The CLA is a smart contract DAO that organizes voting, solves disputes, verifies ownership, reclaims lost passphrases and allows support between members. We predict many disputable “e.g. double” – claims will need to be solved first within the CLA, but over time a secure, inclusive ledger will form with invaluable information.

The incentive for consensus-making is that tokens cannot be transferred, if a full or partially double claim is active on the underlying land. Tokenholders therefore need to request a voting of the other members of a regional association.

At the same time, Chitta hopes to connect with decentral supply chain ledgers, who can use CLA's to stimulate farmer communities to scan the output / input of what they produce. A CLA is able to offer collective purchasing discounts.

Team Members:

Preferred Name: Carst Abma
Github Handle: @CarstA
Slack Username: @carst

Preferred Name: Anandan P
Github Handle: @anandsemtech
Slack Username: @anand.seed

Preferred Name: Leo Anbarasan M
Github Handle: @mleoanbarasan
Slack Username: @leoanbarasanm
Twitter Handle: @AnbarasanLeo

Preferred Name: Vivek E
Github Handle: @vivekebics
Slack Username: @vivek
Twitter Handle: @vivekebics

Status Hackathon Submission

Type: Existing DApp
Github Repo: https://github.com/etherisc/flightDelay
Description: Chatbot interface for Flight Delay DApp to insure flights against delays or cancellations. See https://fdd.etherisc.com for the DApp with a web-based interface working on Ropsten Testnet. We are looking for developers who want to work with us on this, if you are interested please ping us on slack or leave a comment here. EDIT: We have now created a gitter channel for the team, join us on https://gitter.im/etherisc/dev-chatbot

Demo video: https://youtu.be/NYCGlLEtaXM

Team Members:
Preferred Name: Joris
GitHub Handle: @jorisbontje
Slack Username: jorisbontje

Preferred Name: Juriaan
GitHub Handle: @sunfeld
Slack Username: jurrr

Preferred Name: Freek
GitHub handle: @freekp
Slack Username: freek

Preferred Name: Will
Github Handle: @wsaults
Slack Username: @wsaults

Preferred Name: Christoph
Github Handle: @christoph2806
Slack Username: christoph2806

Preferred Name: Stephan
Github Handle: @kpii
Slack Username: stephan
Twitter Handle: @kpi

Status Hackathon Submission

Type: /crypthmetic
Github Repo:
Description:
Do math on cryptocurreny to find your next pick
Team Members:
Kevin: @kivo360

Status Hackathon Submission

Type:
Github Repo:
Description:

Team Members:
Preferred Name: Dom
Github Handle: @netpro2k
Slack Username: @netpro2k
Twitter Handle optional: @netpro2k

Status Hackathon Submission

Type: Bot with web view interface.
Github Repo: Coming soon.
Description:

Mask is a decentralized mixer for Ethereum using ring signatures to hide the flow of money. It is an opt-in service that allows an individual address to disrupt the tracking of their identity. Being that one of the main ways people acquire cryptocurrency is through centralized services such as GDAX and Coinbase which require a user's real identity, a way to "mask" ether is needed to protect the privacy and purchasing power of individuals.

The implementation being submitted as my entry to the hackathon is a proof of concept mobile client that makes it easy for anyone in the world to make, join and withdraw ether from a mixing contract. The code is heavily influenced and forked from the open source project by Andrew Lakar named "Laundromat" with my main contribution being a UX overhaul that makes the service integrated into Status.im for people without access to PCs.

It works by TODO

Team Members:

Preferred Name: Myles
Github Handle: @mylesx
Slack Username: @mylesx

Status Hackathon Submission

Type: TBD
Github Repo:
Description: TBD

Team Members:
Preferred Name: Theo
Github Handle: @theophoric
Slack Username: @
Twitter Handle optional:

Status Hackathon Submission

Type: DApp
Github Repo: https://github.com/andrewrd/given-dApp
Description:
Given is a very simple charity contribution DApp allowing charities to host their own fundraisers with Ethereum. The premise is very simple, charities deploy the app and contract and users can send funds seeing them update live on the site. Initially the project was meant to contain a voting capabilities in which users vote with their contribution to allocate the pool to the most voted for charity, however I opted for a very simple implementation in the end as I found the voting aspect to be quite complex to implement at this stage.

The main point of this project is it helped me a great deal in getting used to solidity development and learning more about the status.im platform and Ethereum. The main challenges I faced in completing this project was getting used to the solidity language and overall stack(truffle, geth, testnet's in ethereum, web3 and connecting to status.im), so overall I gained a lot of value in participating in the hackathon overall as it provided me a good introduction to continue in dApp development.

In future, I'll be expanding this app to have voting capabilities and also have chatbot integration into the status.im platform and revamping the UI to be more user friendly and original.

Team Members:

Preferred Name: Andrew
Github Handle: @andrewrd
Slack Username: @andrewrd
Twitter Handle optional: @andrewrd10

Screenshot of the application:

Status Hackathon Submission

Type: Bot, utilising an existing open-source Smart Contract
Github Repo: https://github.com/morelazers/SaveWithStatus
YouTube Video: https://youtu.be/QymFdyXMUv0 (apologies for length, watch it on 1.25x speed 😉 )
Description: We will be creating a peer-to-peer savings chatbot, utilising the existing ROSCA smart contract which has been developed by WeTrust, the repo is here: WeTrustPlatform/rosca-contracts.

We hope to create a groupchat bot, which can update participants on the status of the savings fund, and prompt them to contribute when it is time. If a groupchat bot isn't possible, we will attempt to do the same but in one-to-one chatbot contexts. Saving with your friends just got a whole lot more Ethereum 😄

Team Members:
Preferred Name: Tom
Github Handle: @morelazers
Slack Username: @ tomnash

Preferred Name: Shine
Github Handle: @shine2lay

Preferred Name: Zaw Mai
Github Handle: @zawmai

Status Hackathon Submission

Type:
Github Repo:
Description:

Team Members:

Status Hackathon Submission

Type:
Github Repo:
Description:

Team Members:

Status Hackathon Submission

Type: DApp
Github Repo: https://github.com/Alonski/CoinPanion
Description:
CoinPanion is the ultimate blockchain subscription solution. The idea is that any user can go to CoinPanion, then they can choose to subscribe to any other CoinPanion user's Ethereum Address with a payment of X ETH per Y days/weeks/months.

CoinPanion users will have rich profiles which will tell potential coiners about themselves and what they create, work on, or are interested in. Coiners can "coin" friends, family members, or content creators whose work they want to support. With category-based discovery features, search, and a user dashboard CoinPanion is the best and easiest to use blockchain subscription service.

Team Members:

Preferred Name: Alon
Github Handle: @Alonski
Slack Username: @alon

Preferred Name: Rahul
Github Handle: @rhlsthrm
Slack Username: @rahul

Prefered Name: Tim
Github Handle: @imbaniac
Slack Username: @treznich

Prefered Name: Joseph
Github Handle: @Josephrp
Slack Username: @JosephP

Youtube Video: https://www.youtube.com/watch?v=LBntnzvhDmM

Troubles we ran into:

1. Deployment:

• Deploying was tough both deploying the DApp itself to the internet as well as deploying the Smart Contracts to Ropsten. From what I understood Ropsten isn't the best test network to be using today and there are other better ones?

2. Getting the DApp running in Status

• Getting up and running on Windows is tough. Even after being able to get everything running some members of the team weren't able to view their DApp running in Status locally.

3. Figuring out how Status injects the web3 object and figuring out how to make sure that it is injected in your DApp.

• I think that the Truffle Status Box should have a working example of using the injected web3 object instead of creating a brand new one.

More from README:

Description

CoinPanion is the ultimate blockchain subscription solution. The idea is that any user can go to CoinPanion, then they can choose to subscribe to any other CoinPanion user's Ethereum Address with a payment of X ETH per Y days/weeks/months.

CoinPanion users will have rich profiles which will tell potential coiners about themselves and what they create, work on, or are interested in. Coiners can "coin" friends, family members, or content creators whose work they want to support. With category-based discovery features, search, and a user dashboard CoinPanion is the best and easiest to use blockchain subscription service.

Forward

This project was started as a submission to the Status.IM Hackathon.
#20

How it works

Simple put: Any CoinPanion can subscribe to any other CoinPanion.

Use Case 1 - Creators

Rahul is a program. He creates Open Source DApps for free for a better blockchain tomorrow.
Rahul however has a family to feed and a home to pay for. He needs a monthly income to be able to continue writing great DApps.
He goes to CoinPanion, for the first time, and is presented with his dashboard.
His Ethereum Address is already filled in as Rahul is using Status to browse the DApp.
He decides to personalize his profile by uploading a profile picture and setting his name, email and profile description.
He writes a meaningful description and mentions some of his current projects.
This will later be used when his supporters go to visit his profile.

Alon loves DApps and the whole crypto community.
He recently started using one of the Open Source DApps that Rahul made.
He decides that he wants to support Rahul with 1 ETH a month.

Alon visits CoinVault . His CoinVault is currently empty.
He clicks on Add to CoinVault and sends 2.1 ETH to the CoinVault, a smart contract which handles subscriptions for Alon.
The reason for the extra .1 ETH is for Gas fees.
This funding will allow Alon to support Rahul for two months.

The he clicks on the button Coin Someone.
A modal pops up where Alon enters the ETH address of Rahul.
He enters 1 ETH per month and clicks Send.
1 ETH is instantly sent from the CoinVault to Rahul.
The CoinVault also schedules to send another 1 ETH in a month.
Every time the CoinVault sends a subscription payment, it also schedules the next one.

When the CoinVault starts to get low on currency, will be empty before next payment, it sends an email notification to Alon.

When a CoinVault is empty it stops sending out coins until it is replenished.

Rahul gets an email that he has a new CoinPanion!
He visits his CoinPanion Dashboard and sees his new subscriber Alon.

For more Use Cases look at USECASES.md

Getting up and running instructions

1. Clone this repo
2. Run TestRPC local node or similar.
3. Download and install truffle and its dependencies
4. Compile CoinPanion with truffle compile
5. Install CoinPanion on the blockchain with truffle migrate
6. Run Yarn start or npm run start
7. Visit: http://localhost:3000 to checkout the Dapp

How To Coin Someone

1. Visit CoinPanion in Status.IM or similar
2. Search for the person you want to Coin
3. Visit their Profile Page
4. Click Coin User
5. Select an amount and a time interval
6. Press Send

How to accept payments

1. Visit CoinPanion in Status.IM or similar
2. Visit your dashboard to view your available payments
3. If the time interval has passed for a specific payment an Accept Payment button will appear.
4. Accept Payments by pressing Accept

Technical Description:

First Time + Loading Vault

1. Alon visits his Dashboard
2. Firebase returns that Alon doesn't have a Vault Contract Saved in DB
3. Alon has a button: Initialize Vault
4. This fires off vault..deployed(userAddress, userAddress, 0, 0, userAddress, 0)
5. The vaultAddress is saved into the DB so that next time that Alon visits his Dashboard his vault is loaded again.
6. Now Alon can Load his Vault, Coin Someone etc

Coining Someone:

1. Alon visits the Profile Page of Tim
2. Alon Clicks Coin Tim
3. Alon inputs 5 ETH per Month
4. Alons VaultInstance is called using vaultInstance.authorizePayment

vaultInstance.authorizePayment( 'alon', coinSomeoneAddress, Number(coinSomeoneValue), Number(subscriptionDelay), { from: userAddress,gas: 500000 })

5. This function returns a paymentId. This needs to be saved into the DB of Tim along with the vaultAddress of Alon, payoutTimestamp (Timestamp when Tim can get Payment)

Receiving Payment:

1. Tim enters his dashboard
2. He sees that he has a payment with paymentId xyz.
3. If the payoutTimestamp has passed. Tim can click on Accept to receive his Ether.
4. If the payoutTimestamp hasn't passed. Tim can see how long until he can receive his Ether.

Receiving Ether is done with: alonVaultInstance.collectAuthorizedPayment(xyz, {from: timAddress})

Dependencies

• Truffle
• React
• WebPack
• Blockchain - TestRPC or Ropsten

File Structure

• Src - contains the front-end's source code
• Config - configuration and install scripts
• The rest of the folders connect us to the Ethereum universe via
• Web3 with Truffle through the Status.Im platform

Contact Us

Join us on the Status.IM Slack channel to chat with us!

TLAP

Type: TBD
Github Repo: TBD
Description: TBD

Team Members:

Preferred Name: Thomas
Github Handle: @TomLisankie
Slack Username: thomas
Twitter Handle: @TomLisankie

Preferred Name: Andrew
Github Handle: @InsidiousMind
Slack Username: insidious

Description:
Dapp with Metamask for making digital contract and store them using ipfs

Team Members:
nounahon Jean-Mickael
For each team member please fill out:
nounahon Jean-mickael : [email protected]

-->

Status Hackathon Submission

Type:
Github Repo:
Description:

Team Members:

Status Hackathon Submission

DLOG - Decentralized Blog

Type: DApp
Github Repo:
Description: A Decentralized Blogging Ecosystem

Team Members:

Preferred Name: Vijay Soni
Github Handle: @vs4vijay
Slack Username: @vs4vijay
Twitter Handle optional: @vs4vijay

Status Hackathon Submission

Type: DApp
Github Repo: Not created yet
Description: A distributed app that allows electricity consumers and small / micro electricity producers to connect and trade electricity.

Team Members:
Preferred Name: Chris
Github Handle: @cyberhiker
Slack Username: @cyberhiker
Twitter Handle optional: @cyberhiker

Status Hackathon Submission

Type: DApp and/or Bot (If I have time)
https://github.com/bpeters/blockparty-web
https://github.com/bpeters/blockparty-api
Description: A dApp that let's you listen with strangers and let strangers listen with you at the exact same time.

Team Members:
Brennen
@bpeters - github
@brennen - slack

Hunter
@hunteredwards - github

Status Hackathon Submission

Type: DApp
Github Repo: https://github.com/thunder-network/thunder-network.github.io
DApp URL: https://thunder-network.github.io
README: https://github.com/thunder-network/thunder-network.github.io/blob/master/README.md
Short Description: Thunder is a payment channel for Ethereum to make millions of micro transactions almost instantly without paying for gas each time. You can settle and write the final ledger on the blockchain whenever you want.

Team Members:

Preferred Name: Harsh Vakharia
Github Handle: @harshjv
Slack Username: @harshjv
Twitter Handle: @harshjv

Preferred Name: Hrishikesh Huilgolkar
Github Handle: @hrishikeshio
Slack Username: @hrishikeshio
Twitter Handle: @hrishikeshio

Description: Somehow combine mifosX (mifos.org -Mifos X is an extended platform for delivering the complete range of financial services needed for an effective financial inclusion solution.) and status.

Links:

• https://github.com/openMF/community-app
• https://github.com/openMF/incubator-fineract
• https://github.com/openMF/android-client
• https://github.com/mifosio

Team Members:

1. Yalu @yalu '(Github, Slack, Twitter)

Status Hackathon Submission

Type: don't know yet.
Github Repo: https://github.com/mkobar/DappMetrics
Description: A metrics collector API to push to ELK

Team Members:
MKobar/@mkobar

Status Hackathon Submission

Type: Bot & Dapp
Github Repo: http://github.com/makoto/gtt

Result

-Demo video
-Dapp URL = There is a known issue to be able to view in status.im browser for deployed environment (works on local as shown in the video). To live test, please use Metamask pointing network to Ropsten.

Description:

Genesis token tracker(GTT) allows you to keep track of the token allocation of Status Genesis Token (symbol: SGT), an ERC20 token, which will be redeemable for Status Network Tokens (‘SNT’ — also an ERC20 token) when the Network is fully launched.

Why GTT?

From Encoding the Status ‘Genesis Block’

The value that lies within this Network isn’t money, but in thought and actions of the wonderful people of the Ethereum community, those who have shaped not only Status but who I am as well. They are the ones who truly believe in trustless, permissionless and decentralized systems, and what gives web3 meaning. They’ve done so with lengthy discussions, feedback and critiques, contributing to our development and the development of Ethereum, and even by doing community outreach — all these actions have value. But quantifying it is hard, so we intend to do this with our own subjectivity, and establish a web-of-trust.

SGT tokens are awarded to community members and all its transaction history are recorded into Ethereum mainnet

The immutable contribution history gives a fair and open competition among would be community members. I really like the idea of Genesis token and hope this sets a great standard which other ICO will follow the same path.

What's missing is a handy app to make their activities more visual and transparent, this is where GTT comes in.

With GTT, users can

• see the leaderboard of high token earning people.
• see where user stands in terms of token balance relative to other people via histogram.
• peek through the transaction history of token earnings as well as how they spend/earn eth.

GTT is probably the only dapp&bott on this competition which gives you the real production data despite the fact that status.im is currently running under testnet. This is thanks to Status.im team taking the mirrior of the same transaction history on testnet (hope they continue doing so).

FAQ

Why rendering is so slow?

Because it goes through the contract event every time each user hits. I could add caching layer easily but won't do it during this competition.

Why rendering eth transaction history is so much quicker than token history

Because I am cheating by hitting etherscan api. Going through block transaction was too slow to be useful.

Will your dapp work without bot?

Yes.

Why Bot and Dapp approach?

I initially tried to do everything via bot but quickly figured many of the features (access to contract events, the avility to write messages asnync using sendEvent, persist local variables, etc) were not available by the time I was implementing the feature (some of them were fixed during the competition). Rather than trying to spend the whole week debugging, I decided to take the pragmatic approach of building the core feature (charting functions) via Dapp and use Bot to help users navigate the Dapp.

Team Members:

For each team member please fill out:
Preferred Name: Makoto
Github Handle: @makoto
Slack Username: @makoto
Twitter Handle optional: @makoto_inoue

Status Hackathon Submission

Type: Dapp
Github Repo: https://github.com/JasoonS/Status-Hackathon
video: https://youtu.be/t5j_8EEOjoU
Description:
Bet bot is a decentralised betting app. Where users can create groups with friends and then use this in order to bet on 'trivial' things. The token system we are using is 0 sum, so some people have a negative balance of tokens and some have a positive. when all tokens in the system are added up the amount of tokens is 0. After a bet is settled I could have -5 tokens (the token type can be changed with each group by the user) and my friend could have 5. We could have decided to call our tokens beer tokens, and then someone with negative tokens can give someone with positive tokens -1 tokens and buy them a beer. thus I would have -4 tokens and my friend would have 4. This allows for a friendly way to manage your debts and all your previous bets. It also allows for additional functionallity, with the use case as if I go to a pub and forget my wallet. my friend could buy me some beers and I could give him 1 beer token for each beer he buys me. thus my balance would go to -2 and his would be 2. this would allow easy tracking of debts. All these use cases can be extended to any size group as long.

Team Members:
Preferred Name: Jason
Github Handle: @JasoonS
Slack Username: @jaybae

Preferred name: BrutishGuy
Github handle: @BrutishGuy
Slack username: @BrutishGuy

Preferred Name: Yepster
Github Handle: @yepster1
Slack Username: @Carysmall2295

Preferred Name: Roy
Github Handle: @RoyEyono
Slack Username: @RoyEyono

Status Hackathon Submission

Type:
Github Repo:
Description:

Team Members: