Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HIP12: Remote Location Assert #39

Closed
jamiew opened this issue Aug 26, 2020 · 11 comments
Closed

HIP12: Remote Location Assert #39

jamiew opened this issue Aug 26, 2020 · 11 comments
Labels

Comments

@jamiew
Copy link
Contributor

jamiew commented Aug 26, 2020

Authors: @rawrmaan

Rendered HIP markdown: https://github.com/helium/HIP/blob/master/0012-remote-location-assert.md

Original PR: #30

Description from original PR:

Since the GPS location assertion check will soon be enforced, more than 1500 hotspots will need to be adjusted in some way in order to have a good GPS fix and continue participating in Proof of Coverage (see current hotspot gps_fix_quality states below). For many hotspots, this will require updating the asserted location to accurately reflect the hotspot's latest location, which can currently only be done with physical access to the hotspot.

gps_fix_quality | count 
----------------+-------
good_fix        |  2275
no_fix          |  1090
bad_assert      |   514

This HIP proposes a new transaction, assert_location_v2, which will allow a hotspot's location to be asserted remotely without physical access to the hotspot.

@jamiew jamiew changed the title HIP13: Remote Location Assert HIP13: Remote Location Assert (tracking issue) Aug 26, 2020
@jamiew jamiew changed the title HIP13: Remote Location Assert (tracking issue) HIP13: Remote Location Assert Aug 26, 2020
@jamiew jamiew changed the title HIP13: Remote Location Assert HIP12: Remote Location Assert Aug 26, 2020
@anthonyra
Copy link
Contributor

anthonyra commented Aug 26, 2020

Does this issue as it's currently written still exist or is it even an issue still or required improvement?

I think the overall process associated with geolocation for the network needs work still.

@jamiew
Copy link
Contributor Author

jamiew commented Aug 27, 2020

@anthonyra yes, being able to re-assert a Hotspot's location remotely is useful whether or not GPS fix is required

@anthonyra
Copy link
Contributor

anthonyra commented Aug 27, 2020

I would 100% agree that this step in the process needs a little buff and also allowing 'remote' asserting could be very useful.
I haven't typed up a formal HIP for this but considering it lands within the realms of this one maybe it'll be worthy to merge.

From my understanding, the current system is a hinder to a patron or just individuals trying to acquire hosts. These owners have to set up the assert_location with their account so that the hotspot is linked to their wallet. Please correct me if I'm wrong I have the one hotspot that I had set up over a year ago. I have, however, moved that hotspot from VA to NY.

Concerns:

  1. If you can remote assert this would allow farms to be moved rather easily.
  2. The current version of assert_location already allows for individuals to pin a hotspot in a location that isn't the current location. (This would allow someone to set up hotspots in a building but make the network think those hotspots are placed perfectly around the city)

My proposal:
Split ownership and asset_location into two steps. Allowing the owner of the hotspot to claim ownership over the hotspot. They then can continue the process if they like or select the option that the hotspot will have a host. Once the owner finds a host they ship the hotspot to them. The host creates a helium account/wallet and completes the setup for the hotspot with their device.

Detailed Proposal:

  1. Owner receives hotspot. They would then use the assign_ownership transaction to link the hotspot to their account.
  2. They would ship the hotspot to the host.
  3. The host would then use the helium app to create a wallet and finish the setup process. They would submit an assert_location. This assert_location would have a confidence rating based on the phones geolocation and the hotspot pinned location.
  4. If the hotspot has a GPS then that confidence could be boosted when the hotspot GPS validates the initial phone assert_location. This would be optional but a step that would increase the confidence of that geolocation.

5)This would be the final validation and would require a decent amount of setup on Helium's side. Helium would create a location validation tool that would simply be a modified Tab. Then a new owner, or an owner looking to boost its hotspots confidence, would be shipped with one of these validators. This device would be online during the initial shipment and during return shipment. This device would be optional but would significantly increase the confidence of the hotspot's location. This step alone has a lot to it and will require me to write a really in-depth explanation of how this would be huge for the network.

Limitations:

  1. This would require the host to use the Helium App or have a Helium wallet.

@rmichalo
Copy link

  1. The host would then use the helium app to create a wallet and finish the setup process. They would submit an assert_location. This assert_location would have a confidence rating based on the phones geolocation and the hotspot pinned location.

^This assumes all distributors of hotspots are permitting or instructing their hosts to interact directly with the helium app, which may not necessarily be true.

I do see value in remote location assert of a gateway. The ability to assert location via inputting address instead of dropping a pin would also be of value.

@anthonyra
Copy link
Contributor

  1. The host would then use the helium app to create a wallet and finish the setup process. They would submit an assert_location. This assert_location would have a confidence rating based on the phones geolocation and the hotspot pinned location.

^This assumes all distributors of hotspots are permitting or instructing their hosts to interact directly with the helium app, which may not necessarily be true.

I do see value in remote location assert of a gateway. The ability to assert location via inputting address instead of dropping a pin would also be of value.

I do have that listed as a current limitation. However, this could also be done with a website (web app). Since Helium is already using React for the website and App it would be fairly easy to do also.

Do you think if the host receives the hotspot with a qr code that they wouldn't be able to use a website to finish the setup?

@rmichalo
Copy link

Some gateway distribution groups may not want hosts interacting with helium's app, website, etc., for a number of reasons.

If your goal is WIFI connectivity, this will be possible with future DIY gateways via wifi backhauling, where the host-user can interact with the gateway directly to connect to their wifi network. WIFI connectivity will not be exclusive to using helium's app, as it currently is with helium manufactured hotspots.

@big-s-k-y
Copy link

I believe managing multiple hotspots will be made much easier with:

  1. remote assert
  2. ability to assert via address (and fine tune by dragging the pin)

Recent updates have been made to diminish gaming of the system by hotspots using a false location, and as such, I see no reason why hosts should be required to add an additional layer of location verification. The network should sort this out, and make this easy. Not harder.

Adding any additional layers of friction will not help this network grow.

@PaulVMo
Copy link
Contributor

PaulVMo commented Oct 8, 2020

I generally support the need for remote assertion. I wonder if this could be achieved without modifying the current assert_location_v1 transaction and instead enabling the mobile app / gateway-config bluetooth tools to allow it.

As background, an assert location transactions works as follows:

  1. The miner (which, in the case of official hotspots, is onboard the hotspot) generates an assert_location transaction signed with the miner's key. The mobile app connects to the hotspot via bluetooth to initiate this.
  2. The transaction is signed by the account key (wallet) and submitted to the blockchain.

Today, this is done as part of a single workflow in the mobile app. I suspect it could be split into a two step process. I believe the mobile app today requires that the owner be signed into to the app (via their wallet seed words) in order to connect to the hotspot as a matter of policy / security not a technical reason. If this is changed, it is feasible that the following process is used instead:
A. Non-owner uses a mobile app (maybe the Helium app or a dedicate/slimmed down app) to connect to hotspot over bluetooth and initiate a assert_location transactions.
B. non-owner send the transaction to the owner
C. Owner uses their wallet app to sign and submit the transaction.

The benefit of such an approach maintains the existing assert_location_v1 transaction, limiting the impact to the blockchain. Additionally, to the extent it matters, it keeps both the host and the owner involved in the transaction. The proposed assert_location_v2 transaction removes the hotspot host from the workflow.

The drawbacks of this is the need to allow non-owners to access the hotspot via bluetooth. This may potentially diminish security. However, it could be made to allow only the assert_location transaction for non-owners to limit the impact.

@jamiew
Copy link
Contributor Author

jamiew commented Oct 29, 2020

Rough consensus among the community was discussed and memorialized at the September 2020 community call: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#bookmark=id.sdsw04n7xjcg

@jamiew jamiew added deployed and removed approved labels Apr 22, 2021
@jamiew
Copy link
Contributor Author

jamiew commented Apr 22, 2021

This HIP was completed and deployed in #148

Commandline wallet already has support for submitting these and the Helium mobile app is expected to add support shortly

@cokes518
Copy link
Member

Support added in app version 3.1.0, released April 21, 2021.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants