Here is a behind the scenes look of the LoRa Radios in action: 🧐
For more progress on things in development, tune in to the Bi-Weekly Community Call ! ☎️
Ask any questions you have and sign up for the community call this Thursday (12PM EST) here :
You can also add the event to your calendar by signing up here :
Our next community call is coming up this Thur. 2/21 at 12PM est.
We'll be talking about Dynamic Proof of Location and The GeoPickle - a testing rig consisting of Raspberry Pis and servers that acts as the first real world simulation of zone anchors.
Join us to learn why this is big step forward for DPOL:
My friend is having an issue with the challenge that he's worried about - https://discourse.foam.space/t/incorrect-street-numbers-in-barcelona-slowmov-challenge/575
Are you storing addresses in the IPFS/blockchain? Or you are storing geohash and then getting it from mapbox?
If I understand correctly you search for the correct address, but it autofills the card with the wrong address? If so, that is a newly discovered issue that we have not come across before. It is a Mapbox issue and seems that their street address and geocoding systems are not perfectly aligned.
Ultimately, it is the responsibility of the Cartographer to verify all information before hitting submit – in this case by doing so the FOAM Map data would be more accurate than what is coming from the Mapbox base map. I will bring this to developer team to see how it can be addressed. One way may be to make more explicit in the card to review the address field.
Given the documentation around how this occurred, I think it is a good opportunity for token holders to weigh in and vote on the point. If it survives the challenge you could manually remove and re-add – in any case thanks for bringing this up for discussion and attention to the issue!
could foam use something like a zk-rollup for on chain data? they seem incredibly powerful constructions.
TLDR, SNARK based merkle root onchain avoids data availability prob of Plasma