A Bitcoin-Inspired Version of Google Maps as a Public Good
In an era where our understanding of the world — our surroundings, places across the globe—increasingly comes from digital "second layers" like Google Maps, the information provided by these platforms plays a pivotal role in shaping our decisions in society, security, politics or public health. Just as Bitcoin revolutionized currency by making it a decentralized public good, there's a pressing need for a decentralized and tamper-proof version of this second layer of the world. Such a platform would host critical information about the Earth's surface, serving humanity's best interests.
This project proposes an architecture where the Internet Computer plays a central role. The React app showcased here, developed within the limited time and resource constraints of this hackathon, serves as a preliminary and illustrative implementation of one use case (users interacting with the data layer through smartphones).
The World's Data Layer, as envisioned in this project, presents a framework for collecting, analyzing, and disseminating geospatial data in a public, decentralized way. This is broadly segmented into three main components:
- Part: Reading and Writing
This segment represents the real world.
- Users, through their smartphones or other devices, can retrieve information about specific locations or input data generated by their device sensors into the data layer.
- Agents, such as vehicles experiencing traffic conditions, can send data points during events like accidents or adapt they actions according to such information retrieved from the data layer.
- Sensors, including weather stations or air quality monitors, also contribute data, for instance, to report flooding or hurricanes.
- APIs / Oracles from organizations like the WHO provide crucial data on pandemic desease outbreaks, health risks or environmental disasters, which are regularly fed into the data layer.
- Part: Collection, Filtering, and Writing to the Data Layer
The Internet Computer plays a central role in this part. It is tasked with receiving data from users, agents, and other sources and writing it to the actual data layer / data storage. Employing filter and consensus mechanisms ensures that only relevant and useful information is stored. Additionally, it defines lifetimes for data points, maintaining the timeliness and relevance of data within the data layer. The Internet Computer can also read information from the data layer and serve as a platform for delivering applications to users.
- Part: The Data Layer Itself
This is the core of the architecture. It comprises the actual data layer, the world surface divided into small squares of 500 x 500 metres, akin to concepts like what3words. Each square can be an NFT on the Ethereum blockchain. Only NFTs for Squares are created and retained, where there is relevant data collected in the real world by Part 1 to minimize data and ressource usage. This data object (NFTs on Ethereum) is publicly accessible, enabling widespread analysis and use by anyone. Developers can create their own applications that leverage this data to provide valuable information to users or other participants. It is a publicly accessible data object of the world — a public good. Only the control over collecting, filtering, and writing the data is restricted to the Internet Computer managed and maintained by a large DAO consisting of participants form Part 1 like NGOs, users or even Tesla (as maker of a large group of agents).
The here presented react app is only an example of the use case where users utilize their smartphone to read data about a square and write data. See below a grafic showing the intended architecture of the whole concept and where this app fits in. It lacks the NFT datalayer and the processes on IC to interact with it. The data object is simulated by a data object on the juno datastore. Future versions will utilize the IC capability to interact with Ethereum to create NFTs and append data to them. Lots of data science should be employed to first find the optimal data structure and filtering mechanisms to enhance sustainability and performance of the concept.
Google Slides Link: https://docs.google.com/presentation/d/1CCmkzTppb2zL5DdSr9sPjyvRwRBZbsBAA7WuKWVYa3s/edit?usp=sharing
The React app was developed using the code and platform provided by Juno.
- React code used from Juno: https://github.com/junobuild/workshops/tree/main/react
- Juno Platform: https://juno.build (!) A thank you to David and the Internet Computer (IC) team for this easy to use and convenient platform. Only this enabled me to develop the app prototype in the couple of hours that i had.
Demo video of app: https://www.loom.com/share/55b9ee38af184766bb2a00097a25cc35?sid=fe78208c-bae6-4d9a-bb10-42eab3eb7293
User loads the react web app being in a location of interest. User can now
- click "Show Geo data" to show information about this location or more specifically about the Square (500 x 500 metres) user is in.
- click "Check in" to log user id (hashed) in the data store for this day and location to attest being here. This can be used at e.g. rallies to proof a crowd.
When selecting "Show Geo Data," App.js activates useGeolocation.js to fetch the user's location, and showGeolocation.js for map visualization on Google Maps. Simultaneously, showTable.js reveals a variety of metrics across several sections for the 500 x 500 metres square the client is in, illustrating examples of data that can populate the decentralized data layer:
- Environment: Showcases mock metrics such as Pollution Index, Flooding Probability, and Hurricane Probability, all generated by mockMetrics.js to simulate possible environmental conditions.
- Public Health: Displays simulated data on metrics like the Incidence Rate of Pandemic Diseases, aiming to provide insights into the health landscape of the area.
- Safety and Traffic: Provides a glimpse into safety and traffic scenarios with simulated Crime Rates and Traffic Accident Probabilities.
- Society: This section, enriched by real user interactions, shows the number of users who have checked in at the location today, alongside a comparison to the baseline average of the last 28 days, offering a real-time snapshot of community engagement. For testing purposes the "days" are minutes in the app to simluate better by using the app. There would be more use cases possible like "Alibi indicator" where user would have to authenticate using biometric information like Face ID to log in using the Internet Identitiy and log the hashed user id for a specific square and timestamp. Later one could read this as an indicator that a specific device and a specific person (tied together by biometric auth) where at a certain place at a certain time (this is not implement in the app right now).
When users click "Check in," App.js coordinates login via Auth.js by showing login.js where user sees Login buton and needs to login with Internet Identidy. When already being logged in or after login it it triggers visitors.js module to update the DAU (daily active user, distinct count of hashed user id) count for this geohash, supported by handleWriteFunctions.js. Upon write success to the datastore it refreshes the table.
Geolocation Acquisition: Initially, useGeolocation.js fetches the user's geolocation using the browser's navigator.geolocation API, obtaining latitude and longitude.
Grid Area Calculation: areaGenerator.js then calculates a grid area based on these coordinates, defining a broader area for detailed breakdown referencing the longitudinal and latitudinal lines of the global therefore fixing the area and therefore the geohash squares.
Squares and Geohash Generation: Subsequently, gridGenerator.js divides the broader area into smaller squares of 500 x 500 metres, assigning a unique geohash to each. This process translates geographic squares where the clients are into short alphanumeric identifiers, optimizing spatial data representation and storage. More specifically it makes it possible to tie a clients geolocation to keys and values on the data storage.
Geohash as Storage Key: The visitors.js module utilizes these geohashes as keys for storing and retrieving location-specific data within a decentralized storage system, ensuring accurate geographical categorization.
- Clone the repo
- Create .env file in root folder
- Log in to Google Cloud Console and generate an API Key for Google Maps
- Add REACT_APP_GOOGLE_MAPS_API_KEY=MAPS_API_KEY with your respective API-Key to the .env file
There is only one screen. Users can show geo location and check in as described earlier.
When clicking on Show geo data, the map location and square for the clients location is show on google maps. The information in the data storage for this square is listed in the table below.
When clicking check in user updates the data storage immediatly (when already logged in) or has to login by clicking on login.
After clicking loging and authenticating with Internet Identity the data storages DauId list is updated by the hashed user id of the client (Internet Identity) only if this user did not already check in today. Then the table below is updated reflecting the updated check ins for today and difference to average (comparison of todays check ins to the average of the last 28 days - days are minutes in this test app though).
