-
Notifications
You must be signed in to change notification settings - Fork 408
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
Comments
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. |
@anthonyra yes, being able to re-assert a Hotspot's location remotely is useful whether or not GPS fix is required |
I would 100% agree that this step in the process needs a little buff and also allowing 'remote' asserting could be very useful. 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 Concerns:
My proposal: Detailed Proposal:
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:
|
^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? |
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. |
I believe managing multiple hotspots will be made much easier with:
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. |
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:
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: 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. |
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 |
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 |
Support added in app version 3.1.0, released April 21, 2021. |
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.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.The text was updated successfully, but these errors were encountered: