Inspiration
Searching for a parking spot in a crowed 21st-century city has become a real hassle. Further, it's nearly impossible to evaluate all options yourself and there’s high opportunity costs to driving around blindly searching. At the moment you have to download multiple apps and search various city, private and parking garage operators to get an overview of parking options. Alternatively, you might just drive in circles until you find an open spot. This is super inefficient. Even if you find an open spot, when you enter a parking lot a lot can go wrong. The parking garage might overcharge you, you might buy a ticket to enter the garage and find that all the spots are full. This often leads to disputes, which then need to be settled in costly manual processes.
What it should do
In our ideal world, an agent, either in your smartphone or in even in your car, will check all parking alternatives available and negotiate the best offer for you. Hereby, different factors, like distance and degree of capacity utilization, will be considered. After you found the perfect parking spot, you can just drive in and out without worrying about getting, losing or waiting for paying your parking ticket at an automate since the payment will be settled automatically.
If however you arrive to find out that the parking lot is full because the parking lot operator overbooked the lot and you drove ten minutes extra to get to the lot, a fetch.ai based Autonomous Economic Agent(AEA) will initiates a conversation channel between the involved parties and attempts to settle the dispute with an economic payment. This might be fully automated - imagine that you drive up to a (now full) parking garage that you’d selected and with a couple of seconds your car tells you that it has negotiated for compensation on your behalf with the agent of the parking garage. Since you went out of your way to get to the garage and the offer you selected couldn’t be delivered, you received a microtransaction to compensate you for the inconvenience. The AEA also took a cut of the payment and the parking garage operator is happy because she was able to operate at maximum capacity and compensate efficiently for the problem of “no-shows”. Additionally, if no settlement is possible a channel to a human arbitrator might be opened.
What we have:
We’re building on top of an existing prototype created in a collaboration with some of our industry partners. We have specific information about the protocols used in that prototype and the way to connect to it (protocols, apis, data structures, PoC architecture).
In the existing prototype, your car has a Decentralized Identifier (DID) based on the w3c standard. The parking garage also has a public DID which is written to an ethereum ledger (rinkeby testnet) in the existing PoC. Additionally, there is a discovery agent which is essentially an ethereum crawler which calls up all the ledger transactions repeatedly looking for DIDs of parking garages with the appropriate DID document content (compliant a specific schema for Parking Facilities). Once found the discovery agent makes contact over HTTP(FIPA) with your car or phone to communicate open garages and spots near you. With the DID of the parking garages you might want to park in your car / phone then makes peer to peer contact with the garage service endpoint. At this point then there is a handshake between your car and the entry gate of the garage over HTTP(FIPA). A pricing offer is made and accepted via smart contract and a microcontroller in the parking gate infrastructure is triggered to grant you access to the parking facility. Your car gets a ticket issued in a specific data format that is used upon your exit from the facility to determine how long you parked and how much you should be charged with automatic payment via smart contract.
What we want to build:
At this point there is no “post-settlement” functionality in the system. That means that if anything goes wrong due to unexpected user behaviour, there’s no way to fix it. We anticipate that this system will enable dynamic pricing models for parking which will increase the efficiency of resource utilisation resulting in optimally utilised (but not completely full parking garages). With dynamic pricing comes a risk that parking garages will overbook. At this hackathon we want to build an add-on functionality to address the issue of overbooking on fetch.ai.
Tools we are going to use
Existing Tech stack:
Go, Geth, Ethereum
Intended tech for hackathon:
fetch.ai, python, C++
Standards: HTTP Decentralized Identifiers (DIDs) from W3C FIPA schema.org (ticket, invoice, parking facility)
We’re looking for a crack python developer for this weekend. We have an experienced full stack ethereum dev (front & backend), and some really good business brains for the presentation parts. If you’ve got python skills and want to help please get in touch. C++ experience would be a plus.
Please send our FET to the following address: 0xf2807f9ff08f69986cc0f2bca8380663404f47e3
Log in or sign up for Devpost to join the conversation.