## Inspiration

In a way, contracts form the backbone of modern society: every exchange of good or services rendered, every transaction where we seek the work and products of others is governed and regulated by these agreements. Without the ability to agree to contracts, we lose the ability to acquire services that may be vital for our well-being.

But we all know that contracts are often tedious and opaque, even for accustomed individuals. What about those groups which find this very hard?

The elderly are a large group affected by this. They have many transactions that require contracts: from medical care, to insurance policies, to financial management, and more. This is a group that tends to have trouble following long and complicated contracts. It is also a group that often has difficulty operating technology -- which can be perilous as contracts are increasingly paperless and online.

That's why we created *AgreeAble*, a contracts platform that is simple and universally welcoming to everyone. We wanted to make a platform that demystifies contracts for those who have trouble with them, making reading and signing as easy as possible.

## What it does

*AgreeAble* works as follows:

1) A family member or caretaker helps the user set up an account, storing a special "Visual Key" as their login instead of a password. This Visual Key makes it easy to verify the user's identity, without having to remember complicated logins.

2) The contract issuer enters a new contract for the individual to sign into the AgreeAble system.

3) The user gets a simple email notification that invites them to sign the contract on the AgreeAble website.

4) The user goes to the website where they can see the terms, validate using their Visual Key, and sign the contract.

The Visual Key is an important part of making the process easy. Current contract services like DocuSign require logins, which may be difficult for the elderly to remember. We wanted to make the login process as easy as "showing" the website something that proves your identity. So, that's what we made the Visual Key: to authenticate, the user just shows the website their favorite, physical object that only they have. (Facial recognition would work just as well, although that IBM service was under maintenance at the time of this hackathon.)

We wanted signing to be very easy too. That's why we chose DocuSign's Click API, which lets users sign an agreement in a single click. **We chose Click over the eSignature API because, by design, the Click API is optimized for as little interaction from the user as possible,** which is perfect for our audience. That being said, a future expansion could include integrating autofill into the form, which would be enabled by the eSignature API.

## How we built it

We built the website in python using the Django web framework. The server uses IBM Visual Recognition to process users' Visual Key, using the data return to generate a unique fingerprint for that key. We then use DocuSign's Clickwrap interface to display simple clickable contracts, retrieving the correct contract from the stored value in our Django database.

The Visual Key uses a fingerprint distance for validation; For an object to be considered a valid key, it must look sufficiently close to this fingerprint. Otherwise, it is rejected. This is an interesting use of data because we built this rather accurate fingerprint using standard vision models, without needing specific domain training.

## Challenges we ran into

Unfortunately, some services that we had wanted to use were not available at the time of this hackathon. We had wanted to use IBM Visual Recognition's Facial Recognition feature, but it was under maintenance at the time. So, we had to improvise, which is how we came up with our Visual Key technique...which arguably is even easier (and fun!) for an audience like the elderly.

## Accomplishments that we're proud of

We've successfully made a very simple and beautiful proof-of-concept for a platform that makes contracts easy for everyone!
## Inspiration

With the excitement of blockchain and the ever growing concerns regarding privacy, we wanted to disrupt one of the largest technology standards yet: Email. Email accounts are mostly centralized and contain highly valuable data, making one small breach, or corrupt act can serious jeopardize millions of people. The solution, lies with the blockchain. Providing encryption and anonymity, with no chance of anyone but you reading your email.

Our technology is named after Soteria, the goddess of safety and salvation, deliverance, and preservation from harm, which we believe perfectly represents our goals and aspirations with this project.

## What it does

First off, is the blockchain and message protocol. Similar to PGP protocol it offers \_ security \_, and \_ anonymity \_, while also **ensuring that messages can never be lost**. On top of that, we built a messenger application loaded with security features, such as our facial recognition access option. The only way to communicate with others is by sharing your 'address' with each other through a convenient QRCode system. This prevents anyone from obtaining a way to contact you without your **full discretion**, goodbye spam/scam email.

## How we built it

First, we built the block chain with a simple Python Flask API interface. The overall protocol is simple and can be built upon by many applications. Next, and all the remained was making an application to take advantage of the block chain. To do so, we built a React-Native mobile messenger app, with quick testing though Expo. The app features key and address generation, which then can be shared through QR codes so we implemented a scan and be scanned flow for engaging in communications, a fully consensual agreement, so that not anyone can message anyone. We then added an extra layer of security by harnessing Microsoft Azures Face API cognitive services with facial recognition. So every time the user opens the app they must scan their face for access, ensuring only the owner can view his messages, if they so desire.

## Challenges we ran into

Our biggest challenge came from the encryption/decryption process that we had to integrate into our mobile application. Since our platform was react native, running testing instances through Expo, we ran into many specific libraries which were not yet supported by the combination of Expo and React. Learning about cryptography and standard practices also played a major role and challenge as total security is hard to find.

## Accomplishments that we're proud of

We are really proud of our blockchain for its simplicity, while taking on a huge challenge. We also really like all the features we managed to pack into our app. None of us had too much React experience but we think we managed to accomplish a lot given the time. We also all came out as good friends still, which is a big plus when we all really like to be right :)

## What we learned

Some of us learned our appreciation for React Native, while some learned the opposite. On top of that we learned so much about security, and cryptography, and furthered our beliefs in the power of decentralization.

## What's next for The Soteria Network

Once we have our main application built we plan to start working on the tokens and distribution. With a bit more work and adoption we will find ourselves in a very possible position to pursue an ICO. This would then enable us to further develop and enhance our protocol and messaging app. We see lots of potential in our creation and believe privacy and consensual communication is an essential factor in our ever increasingly social networking world.
## Inspiration

Jessica here - I came up with the idea for BusPal out of expectation that the skill has already existed. With my Amazon Echo Dot, I was already doing everything from checking the weather to turning off and on my lights with Amazon skills and routines. The fact that she could not check when my bus to school was going to arrive was surprising at first - until I realized that Amazon and Google are one of the biggest rivalries there is between 2 tech giants. However, I realized that the combination of Alexa's genuine personality and the powerful location ability of Google Maps would fill a need that I'm sure many people have. That was when the idea for BusPal was born: to be a convenient Alexa skill that will improve my morning routine - and everyone else's.

## What it does

This skill enables Amazon Alexa users to ask Alexa when their bus to a specified location is going to arrive and to text the directions to a phone number - all hands-free.

## How we built it

Through the Amazon Alexa builder, Google API, and AWS.

## Challenges we ran into

We originally wanted to use stdlib, however with a lack of documentation for the new Alexa technology, the team made an executive decision to migrate to AWS roughly halfway into the hackathon.

## Accomplishments that we're proud of

Completing Phase 1 of the project - giving Alexa the ability to take in a destination, and deliver a bus time, route, and stop to leave for.

## What we learned

We learned how to use AWS, work with Node.js, and how to use Google APIs.

## What's next for Bus Pal

Improve the text ability of the skill, and enable calendar integration.