I looked at the EIP framework and this seems workable. Perhaps the FOAM team could fork this and the community could submit pull requests as far as making it spatially aware, and it certainly is already a mature framework for supporting the Ethereum blockchain… this could also broaden our technical resources by welcoming contributions in a recognizable framework.
Definitely a great suggestion. It will take some work to set up the repository and framework for contributions. In the interim, suggestions can be collected as issues on: https://github.com/f-o-a-m/public-research
An important point though about EIPs for example is that they are not a request for a change but a technical process for standardizing functions. The proposer of an EIP is expected to lead the implementation and defend the proposal in a rigorous process. We would not want a FOAM Improvement protocol to only be a list of requests and nice to see changes. See this thread for more context:
I think a great place to start is with a workshop call as well as collect all the relevent suggestions from this forum in once place as the agenda to go through and further discuss and better understand sentiment on particular proposals.
@nameloceroom how do I get involved with contributing to official agenda of proposals?
Have a good one that we should discuss.
How to incentivize voter turnout?
Have voter rewards also be timed based. As we see that of points being challenged many are brand new can have higher reward portions going to those that vote first.
The first token holders to vote get a higher reward. Incentives watchers to look for new challenges and evaluate quickly. sometimes voters wait until the end to vote to see how many other voted. If waiting until end had a reward penalty this could be addressed/
Could add a lot of incentivization value, but also sybil risk.
Does anyone have any ideas on how the beginning of the process should work with these improvement proposals?
So far, I’ve just been watching these Discourse threads and adding the suggestions that are proposed to the agendas for discussion during the community calls. I’ve also tried providing online docs like the one above so there is a central starting point document for community members to add their proposals to, but no one has added anything to it.
Does it make sense to just have me continue to scrape Discourse and throw these proposals in the agendas before the call, or is there a better/easier way that this could work?
So I’ve been doing some work on this front for a couple of weeks. Here’s a link to my pull request from @yinzeus’s initial work on a FOAM Improvement Proposal process. Includes specifications for FIPs and a full-cycle process for passing them through the community via vote in Community Workshop Calls. Looking for input.
Ultimately would like to try and pass this through as FIP #0000.
Does anyone else have any input before we try to get this merged to the official FOAM developer repository?
One thing that still needs to be decided is the quorum on a Community Workshop Call to hold an official vote on an FIP (x), and the percentage of votes required in favor of an FIP for it to be accepted (y). Any feedback?
Here’s the spark notes version of the FIP process and spec for people that are interested but don’t feel like digging into the full version on Github. Note that it’s based on the EIP and BIP processes.
FIP stands for FOAM Improvement Proposal. A FIP is a design document providing information to the FOAM community, or describing a change to FOAM implementations or processes.
There are three types of FIPs:
Standard Track- describes any protocol-level change that affects FOAM implementations. Two common types are:
TCR Parameter Adjustment
Smart Contract Upgrade
Informational- describes a design issue, or provides general guidelines or information to the FOAM community, but is not mandatory as it does not necessarily represent FOAM community consensus.
Meta- describes a new process surrounding FOAM, or proposes a change to an existing process. Requires community consensus, and is therefore considered mandatory to follow for users and implementers.
Last Call- finalized version is brought to FOAM Community Call and argued for by the owner. Vote takes place to assess community support for the FIP. If (x) number of people are on the call, and (y) percentage of votes are in favor of the FIP, the FIP is considered Accepted.
Accepted- relevant stakeholders will move forward with making any accommodations to their systems or processes as they relate to the Accepted FIP.
Completed- FIP has been developed into code, tested, and implemented to production.
Active- this is the equivalent of Completed, but for informational or meta FIPs, which are focused more on processes and do not need to be implemented into code.
Components of a Successful FIP:
Preamble- header containing metadata about the FIP, including the FIP number (ex. #0000), a short descriptive title (limited to a maximum of 44 characters), the author name or alias, and other details
Summary- short description of FIP and issue it means to address.
Motivation- problem being addressed by the FIP.
Proposal Specification- functionally describes the change or new feature.
Backwards Compatibility- describes any backwards incompatibilities that the FIP introduces and proposes ways to mitigate or resolve those incompatibilities.
Implementations- (optional) may include technical implementation details like code syntax, or may instead leave this up to developers.
Appendix- (optional) may include research, reports, data, test cases, community discussions or other supporting relevant info.
Copyright Waiver- waives intellectual property rights of the author(s) so FIP exists in public domain.
Again, definitely need community feedback on this part, below. What should (x) and (y) be?
FYI, the core FOAM team has merged @yinzeus’s original pull request to the f-o-a-m/foam.developer Github repository. This means that we now officially have a FIP folder on their Github, with this FIP process and specification as the first FIP (fip-1). Check it out here-
The plan is to hash out the remaining details, like what I’ve been posting about in my last two posts above and to figure out who will be FIP editors. We will then move towards making this the first accepted FIP by moving it through the process and voting.
Please reach out to me or @yinzeus if you’d like to be an FIP editor. FIP editor responsibilities are listed in fip-1 here, but are obviously still up for discussion since this hasn’t passed through yet as accepted.
Thank you @nameloceroom for keeping the focus on this process and assisting with promoting it here on the discourse.
It is key to developing the community that stakeholders step up to assist at this time; I would like to see those who have contributed to the map, and the discourse conversation given a chance to be a FIP editor.
There are going to be some interesting opportunities for FOAM functionality going forward and I would like to see those who will be effected by improvements involved!
After the recent events around malicious votes, I have suggestions for stabilization and healthy growth of the ecosystem.
Challenging and Voting requirements:
100 POIs confirmed needed. With a minimum of 100 characters in the description.
(I do not have 100 but would add them)
Active status with 20-30 POIs per month.
Active status discourse chat - 3Box demonstrably connected to the discourse account(Same Name)
So we can make sure that the decisions on the map are made by people who have already shown that they are honestly interested in the growth of this project.
The growth on the map would be greatly accelerated.
Punishment for malicious actions
Here’s a lot of room I do not want to go into deep.
It absolutely needs a way to punish malicious behavior.
With a temporary ban of Ethereum address, we can create a strong protective function.
Creating a new address is easy, but setting up 100 POIs is another thing.
Temporary ban for challanges and votes for all accounts connected through transactions. Why someone needs 3 different accounts I do not understand. The possibility of manipulation is pre-programmed here.
Thanks @Elvo, it’s great seeing specific suggestions proposed to issues we are all encountering on the map.
My personal initial reaction is that these figures are a little high, but I like what you’re going for. I will add them to the list for discussion during a future Community Workshop Call. Have you seen some of the similar suggestions that have been proposed during previous calls?
These suggestions above from our last Community Workshop Call were proposed as ways to make malicious challenging more difficult. Here’s what we decided:
It sounds like you’d like to propose a similar requirement, not just for challenging but also for voting, which is interesting. If the malicious activity continues, then maybe we should circle back on some of these ideas (like yours) and reconsider them.
I actually like this idea a lot- having a section of discourse just for cartographers that have reached certain levels of achievement on the map, and have shown real commitment to adding quality information. I will also add this to the list of improvement proposals for discussion during the next call.
On this, I would argue that there are already explicit punishments built in to the map for challengers. If they lose, they also lose their challenge stake. If you think it would be worthwhile to add that risk of loss into voting as well for losing voters, that’s something that can be discussed, and I will also add that to the list.
I think there are already implicit punishments at play in the map-game for both challenging and voting, where cartographers that are deemed as acting “maliciously” by the wider community lose reputation and are tracked by their Ethereum accounts on FOAM.Tools and block explorers like Etherscan. When they commit actions to the map, especially repeatedly, like the malicious challenging we used to see, the community responds by taking various actions against them.
I definitely push back on this proposal ideologically, and I also think it’s infeasible technically. Where would the banning function sit? If it sat at the interface level, users could use VPNs or other methods to circumvent the censor, and they’d also still be able to interact directly with the smart contracts. If a censor was enabled at the smart contract level, it would permanently ban certain accounts from interacting with the contracts, but those account owners could simply move their funds to different addresses.
If it was technically feasible, who would be responsible for making the decision around who is banned, and what would be their definition of “malicious”, which is a subjective term? Overall, I think there’s many different issues with this proposal, but I again applaud you for coming up with concrete suggestions, which are sometimes in low supply on this site.
thank you for reading through and the constructive answer.
I would like to emphasize that I have absolutely no idea about the programming and the protocol. I try to contribute my practical thinking here.
Sorry if it sometimes sounds too one-sided I give my best
We can think about the numbers but in my opinion it should be in this area. With 30 POIs per month for the active status, this is 1 POI per day. I can do something like this in 3-5 minutes on the Tablet. Anyone who does not want to participate in these important decisions can continue to create POIs as many as he want and whenever.
In my opinion, waiting for further malicious attacks would be a step backwards.
A voter should also have 100 POIs before he can judge Challanges of those who have already created 100. (when we speak about the 100 POIs mark)
Very roughly described:
Where do we go when the student questions the teacher’s skills on the first day?
That would be a very important mechanism when it comes to malicious action with multiple accounts to avoid.
Yes, I have already read through. I can already say that this will simply be useless when it comes to protect the cartographers from malicious attacks by voters and we have the next problem in a short time.
These suggestions alone protect the removal of tokens from the map and ensure the addition of new POIs. That’s something I really support.
I do not know how difficult it is to solve this technically.
I thought if an address had to fulfill certain requirements when participating in challenges and votes such as 100 POIs, how difficult can it be to temporarily exclude this address from challenges and votes.
If an Ether address which has 100 POIs on the map is required to participate in challenges and votes, the only way to avoid the lock is to create a new address with 100 POIs, not?
Yes, the decision can only be made by the Foam Team itself. Here an intervention is definitely needed.
Apart from the user I uncovered, there are others.
By introducing such a protection mechanism, the attacks would be substantially minimized and the effort would not be particularly great. It could be done.
If we were to find this community now we would have not so much to discuss now.
You have even seen the attempt of manipulation by jazzhands. Unfortunately, only you have really questioned this article. Hundreds of people have read it.
I thak @nameloceroom and @foam_cs for the support which I have always noticed.
From both I could recognize the appreciation of my work and this is much more important to me than anything else this map has to offer.
I do not know if that is feasible what I write. I try to describe a self-contained protective machismo that is consistent with the users’ experience.