Respect tree is a primitive that can be used by a fractal with non-transferrable Respect to:
All of this using a single smart contract that implements a simple tree data structure, where nodes are weighted by Respect votes.
Each node has the following attributes:
The root node has a total weight equal to the current supply of Respect of a fractal (Respect is assumed to be non-transferrable). The balance table of the root node is the balance table of Respect.
Anyone can create a child node for any node.
Any account with non-zero Respect can vote on the child node. They can choose the amount of Respect to vote with. They can vote for multiple child nodes. The total Respect distributed by an account to the child nodes must not be more than the balance of that account in the parent node.
The account balance in the child node is equal to the Respect votes for that node by that account.
https://drive.google.com/file/d/1LXOjoQXjEkIdp9MZmXmgwTjvtdst6qn8/view?usp=sharing
Contributors can deploy smart contracts which collect tokens that can be released on condition: "if node X in respect tree received certain threshold of Respect then, allow the owner of the contract take the funds out. Else if a deadline passes without X receiving the threshold, then allow the sender of funds to claim them back". When node X is a project that is a solution to an issue/task in a respect tree then fractal acts as a validator of solutions in a bounty system.
The difference from a typical bounty system is that the validator and creator of issues is not necessarily the same as the funding source and that validation of a solution to a bounty is controlled by respected members of a democratic process.
A graph is a more general structure, where nodes can contain multiple parents, instead of just one like in a tree here. Total weight of a node could be sum of votes coming from its parents.
Overall, intuitively it seems to me that tree structure is simpler and might put constraints which can actually be useful for organization. Bellow is some of my reasoning, justifying a choice of a tree.
Let's take concrete examples.
Same project could solve multiple issues. This makes it seem that 'project' node should have multiple parents. However aren't we losing useful information this way? People who come to vote on a project node through one issue might see that project only as means to solve that one issue they care about. They might not care about other issues that the project claims to be solving. But if votes coming from different parents are summed, this information is not preserved - it is not clear which motivation (parent issue) is stronger. And this motivation coming from the parent issue is important - it should influence the priorities within the project.
A better solution might be for nodes to contain links to other nodes. Project node could be placed somewhere higher up the tree and link nodes could be put under some of the issues it addresses, but they would not add weight to the project node (except by people following the link and redistributing their respect manually).
The parent node in this case would define context for the question and answer. The same question statement might require different answers depending on context and parent nodes define context.
So same question node under multiple parents could be misleading… It could lead people to accepting answers to questions even though they only address one context out of multiple they should be addressing.
Original post in Notion: https://adaptable-oxygen-176.notion.site/Respect-tree-1d34a791bc3f4538a44171707ce77d79?pvs=4
