Are these calls open to anyone?
Yeah the Community Workshop Calls are open. All you have to do is sign up beforehand and we send out a zoom link before the meeting.
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.
I read it through and it looks good.
Thank you @yinzeus for merging my pull request-
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?
The Corrupt Side of the Foam Community
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.
FIP Process Flow:
[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> *VOTE* -> [ ACCEPTED ] -> *IMPLEMENT* -> [ COMPLETED ]
Work in Progress (WIP)- author drafts specification before releasing it to the community
Draft- author releases draft to the community via github.com/f-o-a-m/foam.developer/issues repository pull request. Community reviews and may propose changes to the spec.
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?
8/22 Community Workshop IV - FIPs and Open Forum
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.
I am in favor of these proposals from the community.
I also echo the gratitude and importance of specific proposals to be well articulated. It gives us something solid to work from/with and discuss.
Also, thank you for your work on FIP procedures.
Good work @Elvo.
Thanks for expanding the discussion @nameloceroom Good thread.
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.
I think these suggestions are moving in the precisely the wrong disection. There are currently 3-4 people voting on challenges, and you want to make it more difficult?
The fact that the above posters are all are worried about the “dark side” of Foam instead of the fact that there is virtually no community is bewildering to me. It’s impossible to tell whether the TCR actually needs these changes since virtually no one uses it. Foam improvements should be focusing on growth right now.
To those of you who are flagging my posts in an effort to make them disappear: You ought to be ashamed of yourselves. You’d rather turn to censorship than face some hard truths about this project? Ouch. You might want to ask yourself why you’re even here. Decentralized and permissionless networks may not be for you.
@foam_cs, I presume that you have some kind of targets in mind when it comes to the number of POIs as well as their geographical dispersion? If so, has the map achieved those targets yet?
I can’t agree more with this comment.
I do think you are doing an amazing job guys to put the FIP process in place. However making changes to the map based on the FIP process right now can’t be an “improvement” for the simple reason that the sample size is too small, in fact it is very very very small and doesn’t mean anything relevant that can be analysed quantitatively.
I would recommend anyone to learn what are cognitive biases and more specifically in this case the cognitive bias linked to the law of small numbers. It is an error in judgment to draw conclusion from a small sample size and consider those conclusions relevant for a bigger sample size. Right now you guys and the FOAM team has to understand that very very few people use the map and that no conclusion can be made about this usage and therefore no decisions can be made based on it.
It’s always amazing how humans prefer to not face reality and truth when it hurts to avoid pain and they rather feel good with false data and wrong interpretation of what is going on. I mean would you expect any business to implement changes if 3-5 users give feedback and make recommendations ? If you think so maybe you think your experience is worth more in data than the next hundreds or thousands users then. I just doesn’t make sense.
A lot of efforts have been put in the FIP process and it must be acknowledged but implementing changes right now is not the priority. What matters now is growth. Do you realise that almost no one outside the token sale has added POIs to the map ? I guess thousands of cartographers will come from nowhere with your “improvements” ?
It would have been better to ask this question on the thread about growth. It would be very surprising if FOAM has implemented growth targets since growth doesn’t seem to matter for the team and early adopters.
Perhaps. But perhaps this is also relevant to the ongoing discussion in this thread, assuming growth matters to the FOAM team.
In fact, besides just the growth of POIs, I think growth of cartographers matters too. And what’s happening right now is a downright discouragement to cartographers and would-be cartographers.
I share the same concern as you.
This is why I started this thread on growth :
All the technical stuff are lost on me. But I would say one thing - it’d great to have 100 cartographers each with 100 POIs, but failing that, I’d rather have 100 cartographers each with 1 POI, then 1 cartographer with 100 POIs. That’s the way to mass adoption.
It makes sense that a challenge for minimum stake would attract a small amount of voters due to gas costs outweighing rewards with a number of voters past a certain threshold. Recent challenges with higher stakes attract more voters. The balance of rewards and voter participation is a great topic to discuss in this thread.
I disagree that no conclusions for improvements can be drawn. Prior to the FOAM protocol there were virtually no data points on the performance of token curated registries and only assumptions. Thus far is the most these mechanisms have been tested live and there are areas identified by users and contributors that can be improved upon, either to discourage a kind of behavior or encourage another. These are needed and important discussions that should be held by interested stakeholders. Improvements to the protocol will assist with mechanism design to make the system more robust. You are free to disagree with the prioritization of the FIP process, however this thread is for proposing and evaluating proposals and should stay on topic.