Building Ethos Out of Logos

The Ethosphere, in addition to preserving the privacy of the personae within it, should also be responsible for maintaining a sort of interaction history for them. Over time, this interaction history comes to represent the character or ethos of the individual persona. Ethos is one of the three elements of Aristotle's theory of rhetoric, and it means appealing to a speaker's character or reputation. This is where Ethosphere gets its name. Aristotle's other two elements, logos and pathos, refer to appeals to logic and emotion, respectively.

Lacking any connection with the real world credentials of a persona's owner, its ethos becomes an important factor in almost every interaction with other personae. Any trust relationships that evolve over the lifetime of a persona will be based on the persona's ethos. Whether or not @uncle_albert can find work as a financial advisor as well as how much he is able to charge for his advice all depend on how successful and honest he has been in past financial transactions with other persona. In many ways, a persona's ethos embodies and denotes its identity more so than its alias. As in RL, one can imagine a persona changing its name to something completely different and yet still being recognizable solely by its ethos.

Importantly, a persona's ethos, or rep as we've previously called it, is not directly manipulable by the persona, but rather it is maintained by Ethosphere based upon the persona's history of constructive interaction within a teamspace. "Constructive interaction" can mean all sorts of things, but here's a brief set of examples that hopefully help clarify the specifics of what I mean.

Rep Transactions

These example transactions may influence an alias's rep within a teamspace. A rep is a single floating point number that represents a member's ethos within a given teamspace. I will use the term rep share or simply share to mean a single point, 1.0, of rep for a member.

Note that any transaction where one or a few members can cause another's rep to be bumped or busted always comes at a cost to the members initiating the transaction. This is called a share transfer and it's implemented this way to guard against members colluding to artificially inflate or deflate the reps of others. Transactions that result from consensus of all the members of a teamspace do not have a cost associated for the voting members, but rather result in some number of new rep shares being created. These are called share grants and they will generally result in dilution of every member's rep share, just like issuing shares of corporate stock or additional currency.

Any member can put up a prop. There is no cost or reward associated with doing so. Likewise, any member can write a comment on a prop being considered for ratification. Rep shares are earned only when others in the teamspace recognize a positive contribution to the team. In rare cases, rep may also be lost when others reprimand a negative or destructive activity.

Teamspace Creation (+20 share grant)

When a teamspace is initially created, its founders receive an initial grant equivalent to the "founders' shares" of stock commonly issued in private corporations. This has the effect of bootstrapping the rep system within a teamspace since, as you may have noticed, nothing can happen in an Ethosphere teamspace unless there is at least one reputable member to vote and Like other other members' work. If there are multiple founders of the teamspace, the founders' rep shares will be divided equally among them.

Prop Acceptance (+5 share transfer)

Once a prop has been published by any member, there is a relatively short period of time during which other members can choose to accept the prop for consideration by the larger membership. Acceptance of a prop does not imply it has been adopted by the teamspace, but rather that some reputable member has declared it worth the effort to read and evaluate. There is no penalty involved if a member puts up a prop that is not accepted. It costs 5 rep shares to accept a prop. These shares can come from one or several members. If there are several, the cost of acceptance is shared amongst them. Upon acceptance, the sponsor of the prop receives 5 rep shares in recognition of his/their work. If there are several sponsors, the 5 shares are divided evenly among them. A member cannot vote to accept a prop unless it has a non-zero rep share. A member may choose to accept its own prop, thereby essentially paying for consideration of the prop. However, if any member who votes for acceptance is also a sponsor of the prop, then no sponsor receives any rep share benefit from the acceptance; only the cost is incurred.

Comment Like (+1 share transfer)

A member can "like" another member's comment on an accepted prop. One rep share is transferred from a reputable "liker" to the "commenter." Although the potential reward for sponsoring a prop may seem much higher than for writing a comment, one would expect commenting to be the most important mechanism for building reputation within most teamspaces. That's because a single well-thought out and well-phrased comment can be "liked" by many members, costing each of them only one share but accumulating perhaps significant rep for the commenter.

Comment Dislike (-1 share transfer)

A member may also "dislike" a comment written by another member if they disagree with the comment or feel it is unfair in some way. As with the comment "like", the member who expresses its dislike of another's comment is charged one rep share, but here the commenter is also charged one share.

Comment Censor (-1 share transfer)

A censor works just as a dislike, but in addition a vote is cast to remove the comment altogether and replace it with a short statement to the effect that the comment was deemed unsuitable. If there are a sufficient number of such votes (say, 5), the comment is censored and removed by the teamspace.

Prop Ratification (+20 share grant)

If a prop is ratified by the team, as many as 20 new rep shares may be granted to the sponsor(s) of the prop. There is no penalty if a prop is not ratified within the allotted time period. If there are multiple co-sponsors, the granted shares will be divided equally among them. The actual number of rep shares granted depends on the outcome of the ratification vote. If the prop was ratified unanimously, the sponsor(s) will receive the full 20 rep shares. If it was ratified with only a 51% majority of the total teamspace rep, the sponsor(s) will only receive 51% of the 20 shares, or 10.2 rep shares.

This simple framework could result in a robust reputational economy within active teamspaces, with reputation being transferred from older, more established members to newbies, and new reputation being created as fresh members begin to collaborate and write new props. It may also be desirable to allow reps to decay over time in order to ensure current participation and reduce the impact of highly reputable members who disappear unexpectedly, perhaps because of a RL calamity of some sort.

Dictators and Ruling Parties

Initially, the founder of a new teamspace is the only member with rep shares. He is therefore a dictator, and nothing can happen within the teamspace without his vote and approval. One could imagine someone deliberately hogging all the power by never Liking anyone else's work and never voting to ratify anyone else's Props. Although this is possible within the Ethosphere, it doesn't seem very likely to happen because such a teamspace would be singularly boring for pretty much everybody. All the dictator's "subjects" would simply leave and go join a more vibrant, balanced teamspace someplace else and the dictator would be left with, essentially, an over-complicated personal blog.

Similarly, you can envision a sub-group of members who agree to form a ruling clique, Liking only each other's work and ratifying only each other's Props. Again, this would be pretty uninteresting for those members who are not in the ruling party, and they would just leave unless there were some external reward, like receiving a paycheck, for their continued contribution to the teamspace.

As undemocratic and dysfunctional as these unbalanced power structures may seem at first, there are many RL organizations in which such lopsided teams are common, and highly functional. For example, open source software projects often have "benevolent dictators," high-rep individuals who have disproportionate influence in approving designs and code contributions contributed by other members. The bylaws of commercial corporations typically create a hierarchy of ruling classes, the board of directors, the compensation committee, the executive team, etc., within those teamspaces.