>
> Domain.com domain: sharescription.net
>
>
>

## Inspiration

We all love leaching off other people's Netflix, but hate it when people do it to us. We wanted to solve the age old issue of sharing subscriptions. There's currently no real easy way to split the bills, as you have to rely on someone paying, and everyone else remembering to pay that person back. We aim to change that.

## What it does

People can register via oAuth Facebook, and then add their bills using the simple web interface. They can then decide to share the bill with other people registered on the platform. Once a month, the service automatically splits the bill between everyone and sends an Interac e-Transfer request to everyone who's agreed to pay the bill. It then generates a one-time use virtual debit card number for them to use at the merchant the bill is for.

## How we built it

The project is lots of different pieces all put together. Our APIs are coded in Node.js via Standard Library, we used Flask and Bootstrap to build our website, and bits of PHP to patch up our knowledge gaps. In terms of APIs, we used the Interac e-Transfer API, Marqeta API for generating card numbers.

## Challenges we ran into

>
> We had quite a few issues with API documentation (and the lack of it) and things not running quite as they should be. *-Jack*
>
>
> "I was responsible for the backend of the project and we decided to use Flask with Python to handle the login and authentication. Although all of us have experience with Python but learning how to use Flask for the first time was definitely a struggle for all of us. Secondly I had spent a fair amount of time trying to set up the virtual environment in order to get the project up and running." *-Jerry*
>
>
> "I am not experienced in coding or website building, so I did have to learn and develop my website. At first it was difficult, however, with my team’s constant support I was able to finish the front-end and deploy it in time." *-Sophia*
>
>
> "During the hackathon I found two bugs in Standard Library’s online IDE (case-sensitive usernames not working when sharing code and an error with auto-save overwriting the save files) which took some time away as I sat down with the StdLib sponsors to make sure it was all fixed. There’s a limited supply of documentation on the email parser (SendGrid), and I had to use 3rd party websites to understand how to deploy the app." *-Iyad*
>
>
> Oh my, there was a fair share of challenges, not only did we have to deal with the interact documentation, but even then the website tools rarely ever seemed to work. from there fate decided that the language of choice was going to be one I had not ever used before (node.js) but We still got it working in the end. *-Kevin*
>
>
>

## Accomplishments that we're proud of

>
> I think we've created a really good project, especially considering how many issues with the APIs we ran into during the development of it. *-Jack*
>
>
> "Our project was only 30% done when there was 12 hours left, at that time I didn't expect us to be able to finish the project in time for the demo. However, by some miracles we have managed to pull through and get all of our codes together and to produce this amazing web-app that I am proud to stand behind." *-Jerry*
>
>
> "I came into this hackathon with very little coding knowledge, but I worked hard and was able to create a visually pleasing minimum viable product, which impressed myself and the team. I am proud that I was able to learn the language quickly and make a good product." *-Sophia*
>
>
> "I came in with another team and a different idea. I thought I was set for this hackathon, however, things didn’t go as planned and I had to find a new team during the hackathon. I’m proud that we were able to create a great product during this weekend, with no prior planning, and with half of us meeting for the first time." *-Iyad*
>
>
> To be honest the fact that the proper output is coming out from a range of inputs is a real succes for me. to be honest my initial expectations were low, but as time progress, I found more to be proud of in my work. Something about specifically working with the Interac API and starting off with feelings of hopelessness, but then creating something makes it all the more better.*-Kevin*
>
>
>

## What we learned

>
> I learned all about the weird ways that some payment APIs handle authentication - Marqeta's way of sending data and authenticating yourself was really intuitive, but we got there in the end. I also got to learn about how Flask works, and how to handle authentication using it. *-Jack*
>
>
> "I learned how to use Flask and how to deploy a project on to Google App Engine in the past 36 hours. I'm hoping to carry on this skill into creating my personal website." *-Jerry*
>
>
> "I learnt how to develop my own website using Html and Bootstrap. I was able to learn a new frontend language that expands my skillset." *-Sophia*
>
>
> "I learnt how to integrate three different backend languages into one project. I’m surprised at how seamlessly the codes work together (after hours of debugging). Though not my main focus, I was able to float around the team and help the front end and help out with flask." *-Iyad*
>
>
> No doubt I've learnt much about the interact API and why I probably won't use it again, or with the Standard Library and only now starting to understand what an API is. However what the most important thing I've learnt is to embrace the hackathon spirit, and take on tasks that may not be the easiest, but are cool none the less. *-Kevin*
>
>
>

## What's next for Sharescription

We built the infrastructure for email parsing, but didn't get quite get around to implementing it as a feature. We'd love to make it so people can just forward their bills to the service and have them automatically appear, as this'd make it a lot easier to add new bills.

We'd also like to add support for more subscriptions, and perhaps use machine learning to recognise new services and add them to the platform.

In terms of business, we think partnering with subscription services to show relevant targeted advertising or rewards/discounts to customers using the service would be a really good way to help monetise it.
## Inspiration

Last year we had to go through the hassle of retrieving a physical key from a locked box in a hidden location in order to enter our AirBnB. After seeing the August locks, we thought there must be a more convenient alternative.

We thought of other situations where you would want to grant access to your locks. In many cases where you would want to only grant temporary access, such as AirBnB, escape rooms or visitors or contractors at a business, you would want the end user to sign an agreement before being granted access, so naturally we looked into the DocuSign API.

## What it does

The app has two pieces: a way for home owners to grant temporary access to their clients, and the way for the clients to access the locks.

The property owner fills out a simple form with the phone number of their client as a way to identify them, the address of the property, the end date of their stay, the details needed to access the August lock. Our server then generates a custom DocuSign Click form and waits for the client.

When the client access the server, they first have to agree to the DocuSign form, which is mostly our agreement, but includes details about the time and location of the access granted, and includes a section for the property owners to add their own details. Once they have agreed to the form, they are able to use our website to lock and unlock the August lock they are granted access to via the internet, until the period of access specified by the property owner ends.

## How we built it

We set up a Flask server, and made an outline of what the website would be. Then we worked on figuring out the API calls we would need to make in local python scripts. We developed the DocuSign and August pieces separately. Once the pieces were ready, we began integrating them into the Flask server. Then we worked on debugging and polishing our product.

## Challenges we ran into

Some of the API calls were complex and it was difficult figuring out which pieces of data were needed and how to format them in order to use the APIs properly. The hardest API piece to implement was programatically generating DocuSign documents. Also, debugging was difficult once we were working on the Flask server, but once we figured out how to use Flask debug mode, it became a lot easier.

## Accomplishments that we're proud of

We successfully implemented all the main pieces of our idea, including ensuring users signed via DocuSign, controlling the August lock, rejecting users after their access expires, and including both the property owner and client sides of the project.

We are also proud of the potential security of our system. The renter is given absolute minimal access. They are never given direct access to the lock info, removing potential security vulnerabilities. They login to our website, and both verification that they have permission to use the lock and the API calls to control the lock occur on our server.

## What we learned

We learned a lot about web development including how to use cookies, forms, and URL arguments. We also gained a lot of experience in implementing 3rd party API's.

## What's next for Unlocc

The next steps would be expanding the rudimentary account system with a more polished one, having a lawyer help us draft the legalese in the DocuSign documents, and contacting potential users such as AirBnB property owners or escape room companies.
## Inspiration

We were inspired by the instability and corruption of many developing governments and wanted to provide more transparency for citizens. The immutability and decentralization of IPFS seemed like the perfect tool for this problem. We further developed this idea into a framework for conducting government activities and passing laws in a secure manner through ethereum smart contracts

## What it does

Lex Aeterna provides a service for governments to publish laws and store them on IPFS increasing security and transparency for citizens. We offer a website for viewing these laws and interfacing with our service but anyone can view these laws by looking at them directly on IPFS. We also offer increased security through the use of filecoin nodes to further decentralize the storage of laws and ensure that all laws and documents will **always** stay up. We also offer smart contracts which can be used to vote on proposed laws through ethereum transactions. Our website offers a UI for this functionality which includes secure account login through firebase.

## How we built it

We used the ipfs-http-client in python to upload and download files on IPFS. We set up a firebase database to store countries and associated laws with CIDs and other parameters. We then used flask to create a rest API to connect our database, our front end and IPFS. We coded our front end using react. We coded our voting smart contract using solidity and deployed it to a test net using web3 on python. We then expanded our API so that governments could deploy and use voting smart contracts all through our API. We use firebase tokens to authenticate the use of API functionality.

## Challenges we ran into

With such an ambitious project, we had to cover a lot of ground. Connecting the front end to our API was especially difficult because we didn't have much experience with react. It was difficult to learn on the fly and develop our front end as we went.

## Accomplishments that we're proud of

Although we were very ambitious, we were able to pretty much implement all major functionality that we wanted to. We implemented an entire web application through the entire stack which uses IPFS and blockchain technology. Most of all we pushed through and continued to work even when we felt stuck.

## What we learned

None us had used flask or react before however, we all became proficient enough to implement and API using flask and a front end using react. We also learned more about what it takes to plan and execute an original idea extremely quickly.

## What's next for Lex Aeterna

First we would move to AWS to increase scalability and security. We would spend some time testing the security of our API and log in features. We would also want to expand our smart contracts to further provide more options for governments to utilize the ethereum infrastructure. For example, different types of votes such as super majority or government terms that expire after a period of time and even direct citizen votes for government officials or policies.