EOSCommunity.org Forums

The Good, Bad, + Ugly of Fractally after Meeting #1

Lately, I’ve become a complainer in the EOS community due to, in my view, fundamentally flawed algorithms and misuse of intrinsic motivation in socioeconomic systems.

To me, a complainer is usually powerless to make change. Powerless I am not, and changes I will make. I hope Fractally team + contributors listens to these concerns and solutions, but I have my doubts. If he doesn’t listen, and continues to lead the community astray with quasi-biomimicry and machine-focused code, I will propose creating a better system, on a better blockchain (that’s Mandel from Day 1, see the end of this post)


I will do my greatest effort to communicate these concerns in a timely manner to be implemented before the Hive code goes live. For now, here’s the skinny skinny, check meta eden for more fleshed out solutions.

Here goes!

We’ll sandwich the good, then the bad (+solutions), then more good

I will focus on core mechanics here + what I learned in the first stand-up meeting. Post edited to remove unneeded energy.

The Good

Group sizes - Well thought out + researched, worked

Zoom - Good because we’re used to it from Eden

Website - looks wonderful, and served the purpose for this meeting

Branding - Looks good, white paper looked good, overall friendly

The Bad

Problem: Lacking key Consensus forming mechanism - There’s no way to make 6-lists-of-6 consensus that’s built in, which is pitched as a feature.

Solution - Ranked voting as described here using time tokens to avoid anyone selling or trading their tokens can also be a funding mechanism with mirrored tokens (like I did with BLUX). Built into UI and used while in meeting. Then, computer generates consensus list, which each member must ratify with an on-chain signature.

To exemplify this issue consider that anyone who doesn’t report consensus won’t get any respect. This means anyone who doesn’t agree with others has a choice to succumb to social pressure or not get paid. With 46,656 rank option for a 6 member group, it’s obtuse to think people will just come to honest consensus within an hour without a smarter system than people talking with no proposed structure.

Problem: Lack of key primitive - Contribution

Solution: JSON object that has information about contribution, at very least, tell us what blog platform you want us to write about what we did.

Problem: Lack of key primitive - Humanness

Solution: Adopt Eden as a prerequisite, or adopt what UX network or Telos are working on. Better, make a JSON object listing stuff we should know like links to their projects.

Problem: Lack of key primitive - Meeting

Solution: A JSON object including a list of each group, who got what respect. This solves the history issue, iterating this object can give any system (or API) the ability to quickly tally total contributions, and display it visually on the platform page.

(Yes, the solution for most things is simply structured data in a public repo anyone can make pull requests to)

Other lacking primitives - a Fractal - a ‘blog post’

Problem: Liquidity linking puts all communities at risk due to presumably over 50% circulating supply exposure.

Solution: Create multiple attractive options for ROI that don’t have the risk of LP pools. This can be single-token staking, or a form of DeFi like wax.defibox.io where the rewarded pools are just EOS / Respect.

Problem: Every saturday for 2 hours you’ll be in a meeting

Solution: Use biomimicry in cycles (Full moon / new moon) to hold meetings where on the new moon you focus on work ahead, and on full moon you say what you did. Everybody gets laid.

There’s more, but if these were fixed, I wouldn’t be complaining, I would be recruiting.

The More good

Inertia - The inertia here is priceless, and if we listen to key community members concerns (not just mine) this inertia can go global.

Cultural Unity - While diversity is best in the long run, right now there isn’t a good chance we would reach consensus with multiple languages and communication styles. Cultural cohesiveness in future groups should be adressed, such as with the concept of geotribes.

Step into my Vision

Here’s how we can run Fractally in a way that honors Dan’s vision, better

New Mandel Blockchain - Fork EOS with contribution proof to get your forked Respect (show up to a meeting, you get the EOS in your account on the new chain) . I’m already working on the branding for this, and it’s cool. I make cool stuff.

Some features would be a one-resource model, perhaps even without staking needed, free accounts, cloud wallet, and all teams are (improved) fractals. Development is paid for by the system, plus most development is open source from the ecosystem, and the rest is closed source but existing already.

Geotribes - Fractally should be fractal on a local level, in some respect. With this geofractal, we can build global governance for anything, any project, any movement. Maybe this is early, but it needs to go into code ASAP. I wrote about this in the Web 4 paper

Projects over People - People should be raking projects, not people, in terms of contribution. These projects should receive funds and split them in a way that THEY form consensus about, just the team should decide who did the most, not random people.