6/13 Community Workshop III - Registry & Voting Contract Upgrades


#1

image

Please join us for the third FOAM Map Community Workshop Call, 12 noon EST, Thursday - 13th of June. We will be focusing on Registry & Voting Contract Upgrades (“TCR 2.0” Ideas) and developing a FOAM Improvement Proposal (FIP) framework.

Sign up for call here

The workshop will not be live-streamed, please sign up to attend. We will send a follow up mail with details on how to join closer to the event.

You can find the agenda and talking-points here.

If you have new improvement proposal ideas related to the Registry/Voting Contracts that have not yet been incorporated into the list, feel free to add them to this document here. From there, they will be moved to the official agenda.

Draft FIP Specification (by @yinzeus) here.
Workshop I notes here.
Workshop II notes here.

Please bear with us as we work to consolidate all of this information into one library that makes it easier to find information pertaining to Community Workshops.

Hope to see you on the call!


New Tags: Residential, Education, Transportation, Religion, Government – FOAM Map
Inquiry regarding use of Tags vs. Traditional Map Layers
#2

Bumping thread as reminder of tomorrow’s workshop call.


#3

Hope to see people on the call tomorrow! Links to the sign up form and the meeting agenda/talking points are in my post above.


#4

Thanks to everyone who joined the third Community Workshop Call yesterday. Interesting perspectives were shared on the improvement proposals by many different members of the community. I personally thought it was the best workshop call yet.

There is still lots to discuss, including the rest of the proposals that we didn’t get to, and a FOAM Improvement Proposal framework that will allow us to promote some of these to development and ultimately mainnet. Therefore, we will be announcing another call in the near future.

If you’d like to review what was discussed, here are the meeting minutes (anything not on the list, we didn’t get to)-

(If Dropbox is easier, same notes are here.)

End Goal- Standardization

  1. Proposal- POIs as a NFT
  • Severity: TCR 2.0 contracts

Notes- Assessed as interesting and worth investigating further. The interplay between POI verification/challenging and NFTs is as interesting as it is unknown. Further looking into: How would this impact the map-game, and the quantity and quality of info on the map? How technically complex would it be to do this?

  1. Proposal- Signal metadata should follow OpenSea standards
  • Severity: TCR 2.0 contracts and Signal Migration

Notes- Currently, FOAM MetaData is stored on IPFS, which is not supported by OpenSea. The issues around IPFS + OpenSea are around image hosting, and the speed of retrieving those hosted files. IPFS is currently not fast enough, so many images on OpenSea are hosted on AWS. Found related discussion: https://github.com/ProjectOpenSea/opensea-js/issues/6 . Further questions: Will IPFS and OpenSea become compatible? Will OpenSea eventually move to support IPFS, or will IPFS retrieval become fast enough for OpenSea? Are there other NFT marketplaces that should be considered as well?

End Goal- Fixing POIs (w/o full removal)

  1. Proposal- Editable POIs- allowing POI owner to edit POI metadata before a certain time frame and/or for a small fee
  • Technical Dependency: Production-ready ENS or IPNS
  • Severity: Frontend and backend upgrades

Notes- Strong support for this proposal, but only implementable when ENS or IPNS is fully functional. Open question: Is there backwards compatibility with existing POI data?

  1. Proposal- Soft-challenging only a certain part of a POI
  • Severity: TCR 2.0 contracts

Notes- Unclear how this would work. Adds complexity to current build, and until scalability / gas costs are not solved, does not seem worth further pursuing because of lacking incentives for partial challenges. Solve-able by proposal #3 below.

  1. Proposal- Option to declare new state of POI during challenging, and proposed change occurs automatically if challenge wins. Incentivized through higher voter reward percentage
  • Technical Dependency: IPNS/ENS for editing metadata
  • Severity: TCR 2.0 contracts

Notes- Strong support for proposal. This is deemed the most interesting proposal, in both categories- “Fixing POIs (w/o full removal) and “Requiring challengers to create (not only remove) POIs”. Envisioned as an option when challenging to execute full removal, or edit. Potential effects: 1) points are improved over time (quality of POIs increases) 2) less points are removed (quantity of POIs remains high).Question as to why challengers would be inclined to edit rather than full remove, since this is more work for them. Answer: Will be solved by voters. Voters will evaluate if “full removal” or “edit” was used correctly. Question as to how this impacts the existing map tools and interfaces.

End Goal- Challenging- Requiring Challengers to Create (Not Only Remove) POIs

  1. Requiring certain percentage of challenge rewards to be used in POI creation before being unlocked
  • Severity: TCR 2.0 contracts
  1. Requiring certain number of POIs to be placed with challenge rewards before being unlocked
  • Severity: TCR 2.0 contracts
  1. Requiring certain ratio of POI creation to challenging in order to challenge (either by number of POIs or tokens staked). Ex. 1-1: Only able to challenge up to the amount of tokens one has staked in the map in POIs
  • Severity: TCR 2.0 contracts

The first two have attack possibilities that are currently unsolved- staking POIs, and then immediately removing. All three of these add extra barriers to challengers and could disrupt current incentives for challenges, which are currently seen as balanced. Point 3 in previous section also solves this problem in a more elegant way.

It also feels like these three proposals are the result of previous issues with a contagious challenger, this was solved by community action and has since stabilized.

Challenging- Defender’s Advantage For Verified POIs

  1. Increasing proportion of tokens required for challenging vs staking when POI has already been verified. Each successive challenge requires double the previous challenge
  • Severity: TCR 2.0 contracts
  1. Increasing the VOTE_QUORUM required to remove verified POIs (ex. to 2/3 supporting challenge)
  • Technical Dependency: Live governance module
  • Severity: TCR 2.0 contracts

Discussion around whether it makes sense to 1) retain current features of application period, 2) enhance features by providing additional defensive advantages to verified POIs, 3) remove the application period altogether from smart contract layer, and make new point visibility an interface developer option for specific use cases. Strong support for removing altogether from smart contract layer, to simplify map-game for new users and experienced users alike.

Challenging- Defender’s Advantage For All POIs

  1. Increasing proportion of tokens required for challenging vs POI staking- perhaps creation of new TCR parameter (wouldn’t be game-able by whales)
  • Severity: TCR 2.0 contracts
  1. *Increasing the VOTE_QUORUM required to remove any POIs (ex. to 2/3 supporting challenge)
  • Technical Dependency: Live governance module
  • Severity: VOTE_QUORUM vote

These proposals came at a time when the map was dealing with different activity, that has since been overcome by the community. Deemed to not be high priority anymore. Also, seen as being resolved by editing (#3) proposal above.

Re-adding Valid But Removed POIs

  1. Allow re-adding valid but removed POIs (ex. Zollverein Coal Mining Complex)
  • Severity: Frontend and backend upgrades
  1. Allow re-adding w/ additional features, like only if cartographer re-stakes for double the stake of the previous stake or challenge

    • Severity: TCR 2.0 contracts

Unclear what this adds other than slight comfort when re-adding a subset of removed points. Question as to whether this could be solved by the editing (#3) proposal above, by essentially editing state of POI “back to life”?

Increasing Voter Participation

  1. UI- Reduce MetaMask default gas limit for FOAM transactions to value closer to actual gas used

  2. Severity: Low (Web3 fix w/ MetaMask)

Support exists for this proposal, as it lowers barrier to entry for new users, and seems like a quick fix.


FOAM Location Update and Demo Documentation
FOAM Improvement Proposals
FOAM Improvement Proposals
The Corrupt Side of the Foam Community
UNSW Village Green Oval
Inquiry regarding use of Tags vs. Traditional Map Layers
#5

For those who missed it, here is the recording of the call:

FOAM Map Improvement Workshop III - Smart Contract Improvements :ballot_box::chains: