Holochain Forum

GPS Handlers

Microservices/modules focused on GPS data storage, route calculation and route comparison.

I would like to explore the posibilities of what can be done with the gps data that each agent stores for themselves.
First how to store such data.
Then find out if there is a way to compare these routes that agents record daily, in a distributed way, without the need for a central point where the comparisons take place ?

The use case would be to pair people with very simillar routes to enable for example:

  • carpooling of neighbours that share an almost identical route to work but dont know about each other
  • pairing demand from a postal package sender - with other user who is traveling, or planning to travel in the same trajectory as the package should.
  • calculating meeting points of package delivery workers to exchange packages that need to change direction etc…
    or have a look at WE_Share / Shareful

How would handling and encryption of the position data look? …to keep the positions of users private, but still be able to compare routes of all users in a circle of for example 5km?
Zero knowledge proofs come to mind but I am not sure if and how it can be utilised, and how big are the holes that my logic around this has :)) Therefore I need more brains to look here

I hope that my english is understandable.

Team Size: 1

Resources: Basic structure and related ideas documented

Similar app or site: OpenStreet Map

I am at…: Idea phase, could have many use cases if its possible to build.
Also in need of a design session to create schematics and consider options.

Various, not much coding

Commitment: Right now I would commit to a few design sessions to see where interest is at. @ViktorZaunders hope you are not angry that I copied a bit of your happ description here but I really did not know what to write here :smiley: Let me know when you are free to have a call.

What do I need: Talk to technically oriented people well versed in the structure of holochain.

*the topic of working with gps data in Holochain was/is also discussed here OpenStreet Map and here Geolocation


Integration of What3Words would be awesome


Wow thanks for posting, looks like an interesting idea

Hi There

I like this idea and was thinking of some other GPS uses. I have even been thinking of creating new Holo/linux phone/device with GPS but no sim card. I think new phone tech may come out in the next few years related to Skylink that will allow this. I would like to see GPS data tracked but private and secured for say family members or social groups. I do not think this is easily done as far as I know on current networks other than using a VPN. I don’t mind sharing some data with government bodies but not corporations. When I talk on my phone and then get ads related to my conversation I see it as an infringement on my privacy. I know Apps are supposed to ask for permission but it seems it is sometimes missed.

Anyway great idea, I have about 100 app ideas just for GPS alone lol…



@Anton thank you for starting this thread and thank you @bierlingm for sharing what3words.com, I would definitely like to join this discussion group alongside people with strong technical background.

Group can find my non-tech skills offering here, this way helping group move along and focus on the problem we are solving when we hit a road block or go in circles or go down a rabbit hole.

Recently diving into the world of Hierarchical Temporal Memory (HTM) has made me realize how much benefit we have in exploring HTM Encoders in pursuing this exercise.


“Grid Cell” a biological corollary to GPS:

A grid cell is a type of neuron within the entorhinal cortex that fires at regular intervals as an animal navigates an open area, allowing it to understand its position in space by storing and integrating information about location, distance, and direction.

To learn more about Grid Cell in context to world of HTM watch HTM School (Episode 14) Grid Cells.

Warning: Usually for someone jumping in the middle of HTM School playlist can find it daunting (as there are many concepts from neuroscience at root of HTM), my recommendation is to start at the beginning. If you need help please ping me, since I might be able to address some confusions on biological side of things.


@Anton Would you like to open this topic(design, architect and also implementation) in Virtual Hacklong?


Yes I would be happy to do so : )

S7 Foundation - is the organization behind HoloWeb / HoloMap ( @loveisthemedicine )

S7 Foundation Living a Peaceful, Healthy, Free and Superabundant Future… One Holon at a Time… We are living here NOW in Gift Consciousness as a microcosm for the planet to witness, celebrate and cocreate with. Gift consciousness means unconditional sharing; the honoring and empowerment of each other’s unique exquisite being. We are lovers, artists, integral design engineers, technologists, mystics, scientists, and more. We are future cocreators, not predictors. Because the community is fractal and holistic, we are working on initiatives from every walk of life and weaving them together simultaneously.


@Qubeo Jakub recommends reading WhitePaper by Ocean Protocol to understand role of Trusted Third Party organization providing “DataServices” and the value they bring in problems such as “Travel Planning”.

Problem which needs to address following components:

  • Location Data
  • Traffic Data
  • Map Data
  • Routing Data
  • Anonymization

I would love to expand the discussion about how GPS modules could look and work and which varieties are needed for which kinds of applications.

If some of you are interested in this topic please pm me and lets talk further or organise a public call to brainstorm in a larger group.

1 Like

Yes I’m very much interested bro as I said in a hackathon and dev camp we were both on… :blush: This is something I have been thinking a lot about for my project Our World because the smartphone version phase 1 is a crowd sourced decentralized distributed replacement for Google Maps, Google Earth etc…


There will be routing information and geo location to find places like google maps. It will also have quests that appear in local parks and nature places to encourage people to get back into nature and also encourage creativity, team work, planning skills etc… I want to get kids out of their bedrooms and back into nature…

How far have you come with this yet? Is there any zomes etc that I can play around with? :blush: thanks.

You going to dev camp 7? I just signed up… :heart::blush::blue_heart::sunglasses:

Looking forward to seeing you all again… :sunglasses:

1 Like

Yes I know these guys (S7) well and have been working with them for a couple years… their tech will be deeply integrated into Our World one day… :sunglasses:

1 Like

Hello everyone,

I’m Alex (they/them). I’ve participated in two previous DevCamps and am excited to be building things with Holochain! I am currently working on an app that requires geolocation services, and have decided upon a particular approach that I dub ‘s2-wasm’.

I am attempting to compile Google’s S2Geometry library to WASI using Wasmer. This can be used as an anchor generator mixin for Holochain. S2 is a library of C++ classes that divide the globe into trees of cells using a geometric curve wrapped around a sphere. The library isn’t quite suitable for handling exact position or coordinates. Instead, cells are used to approximate regions. S2 depends on OpenSSL for generating 64-bit identifiers for each cell.

You can learn more about the library in this blog post. To visualize how S2 approximates regions, you can also play around with S2’s RegionCoverer class using this tool.

Notably, this library is used for geospacial indexing for apps such as Pokémon GO and Tinder. Tinder’s engineering team wrote an interesting series of articles detailing how S2 helps them manage distributed data storage. (Though Holochain functions independently of geolocation, so the objectives here are different.) [Part 1 | Part 2 | Part 3]

Here’s an overview of how I’m planning to use the lib:

  1. When the service initiates, the front-end client gets the device’s coordinates (this doesn’t have to be GPS; it may use WiFi triangulation, etc.) This is passed to the module along with the “discoverability/query” radius.

  2. S2 RegionCoverer returns a vector of 64-bit identifiers for the cells in that region. To limit how many cells are generated, the min and max cell level should be set to the same value. (Lower level = bigger cells, higher level = smaller cells) The blockiness of the region isn’t so much a concern as the mitigation of hotspots on the DHT, which can come from having many links to one thing.

  3. The user’s profile is anchored to each of the slices in the vector.

  4. When a user needs to query an area, they simply get the cells in their region and randomly query them as anchors.

Alice only needs to locate one link to Bob’s profile, as it is known to them after that point.

As a user’s discoverability radius increases, an issue arises where many more cells (and anchors) are created, resulting in hotspots. To resolve this, I propose:

  1. Setting upper and lower bounds for a valid radius, and

  2. Set bounds for the cell levels, by stepping up their size as the radius increases.

As an example, looking at the University of Toronto campus with the RegionCoverer tool:

Level 14 cells appear to be appropriate for this radius.

Expanding out, though, level 14 is creating more anchors than we’d like…

Level 12 seems much better:

A user’s profile is anchored to cells at the level based on their preference. When querying, the entire tree of valid cells should be passed back. The client first queries cells on their own level, then moves to other levels. An added benefit of this approach is that the users with similar travel preferences are more likely to find each other first.

Even if the cell level is progressively stepped down, hotspots might still become an issue if many users are linking to a single large anchor. To solve this, a procedural naming convention can be used to produce multiple “dimensions” of cells. If the number of links reaches a certain limit, a new dimension is generated. During a query, nodes should step up dimensions until no further links are returned. This could also be useful for ‘first n people to check in at x location’-type validation.

What about privacy and security?

I’m intending to set user profiles to private by default. When a user gets a link to another person’s profile, they additionally request a temporary access token for that profile. This way, each user can be given granular control over the visibility of their own profile (e.g. only grant up to n tokens within 24 hours, only make my profile visible to n people of this gender within 24 hours, unlink from all cells, revoke all tokens, view granted tokens, etc.)

I’ve been considering how to mitigate the possibility of nodes spamming queries, as well as anchoring and querying areas that they are not located in. I was thinking that each node can maintain a public ledger of their anchor and query history. The anchors or queries themselves wouldn’t need to be revealed, only a header with a timestamp. Before Alice’s node grants an access token to Bob, they first perform lazy validation on Bob’s ledger. I’ve imagined the possibility of using AI to handle this. MindSpore Wasm strikes me as particularly interesting, as its distributed deep learning model seems to fit Holochain’s paradigm surprisingly well. I see it as potentially useful for a few other things, such as client-side moderation. This is definitely its own module, however :wink:

Why this approach?

  • Code reuse: instead of writing a ton of new code to handle geolocation, we can rely on existing libraries that are well-supported. The module can be run with Holochain-wasmer, for example. Maybe even OpenSSL can be replaced, perhaps by Rustls or linking in Holochain’s own TLS lib (?) I do intend to publish s2-wasm to the WebAssembly Package Manager for wider access.

  • Versatility: a bare bones, generalized approach enables maximum relevance for other Holochain devs. S2 is a very comprehensive lib by itself, enabling all sorts of geometric operations on the sphere.

  • Maintain Holochain’s unenclosability: needless to say, privacy of geolocation data is a huge area of concern. This method keeps things private, as the coordinates are handled only on the device at the edge. Holo hosts would only be able to track things pseudonymously. Additionally, this method could work over different transport protocols during a natural disaster or other network interruption.

  • Further, this aligns with Holochain’s virtue of consent-driven technology. Giving each person granular control of access tokens guarantees maximum agency for everyone.

  • Performance: C++/Rust compiled to Wasm is fast.

  • S2Geometry and OpenSSL both use the Apache 2.0 license, which, to my knowledge, would permit s2-wasm to be given the Cryptographic Autonomy License.

Right now, I’m troubleshooting the build script for OpenSSL on WAPM. I tweaked the script to pull and unzip the latest version, but am having issues building it, and figuring out how to properly link to S2. I’d love to get any feedback and see if others are interested!


Hi Alex, great to hear from you, been a while… :wink:

Are you going to the new dev camp next week? I’ll be there again for my 3rd sitting, be great to see you all again… :slight_smile:

I remember you talking about this idea previously and was really excited by it and wanted to talk to you more, because as I said I will be using GPS a lot in my geolocation game…

I really LOVE your approach and is something I have been working out how to solve the privacy issues yet still make it accurate and usable… and it looks like your approach is a good solution with this…

How far have you got now?

I would love to plug your Zome/Lib into Our World and collaborate with you on this…

I am currently working with WASM too, in getting .NET to compile to WASM for the .NET HDK I am currently working on… very exciting times! :slight_smile:

I feel this year and next will be a BIG year for Holochain and the long wait will definitely be worth it! :slight_smile:


1 Like

Hello Anton and others,

Developing location-aware apps is getting only more interesting with the rapid development of IoT. I’m currently working on my location-aware app, so I would like to share my experience.

You can check this article, it contains information about almost every aspect of using geodata in your app.

I would be happy to receive any questions regarding this process, feel free to DM me.

Best Regards,

Hi all,

First, I’m totally new to Holochain and this hApps system (found out about it yesterday) but I’m eager to learn more about it.
This project based on GPS data is interesting as everything is becoming location-based and the distributed nature of hApps is inline with this.

So, I see many answers considering the location, how to obtain it and how to position on a map.

Thinking about the usage, I sat back and gave it a thought :

  • what do we need to know?
  • what information do we need to share?
  • how can we avoid dispatching people’s location?

I thought of a simple example of postal service just to illustrate.
The parcel is the object of interest (not it’s content) and it has origin and destination information. Each time an agent picks up the parcel, he registers it with his app and, as long as this parcel is registered, it gets the location information of the agent.
As soon as another agent registers the parcel, it’s removed from the previous agent (moves from hand to hand).
The only object I can query on is the parcel which will give me it’s current position, origin and destination. No way for me to know who is holding it.

For route matching, maybe just sharing OVD (origin, via, destination) along with a one time ID could be the way to go. It maintains information privacy until the 2 users agree (handshake process).

I hope to have shed some light on the matter, feel free to get back to me on this interesting subject.