1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in


From pangaia

Revision as of 01:24, 15 April 2012 by Average (Talk | contribs)
Jump to: navigation, search

Note: This page's contents has mostly been moved to Google Docs and now just holds extra notes See also the prototype page and screenshot.



This is a Game.

A Game consists of a set of Rules played over time. In this Game, some Rules are hidden, but anyone can play and everyone starts equal.

The Opening Window is called the Apeiron, between it and the World itself is where the Game is played.

Inside this space, one can place People and Ideas. Ideas can accumulate into Projects, and People into Collectives. Together, these are the main "pieces" of the Game.

The Object of the Game is to maximize value-generation through crowd-sourced collaboration and dialog.

By creating a Node for your name and posting it in the Aperion, you automatically become a Player. Earn a credit. (see Initialization below.)

The Aperion is a "blank slate" -- orientation in this space is not meant to confer a preferred axis or ordering.

Putting a non-Player Person's name other than your own is considered an Invite. If they accept the Invite, the Person becomes a Player. See Interaction.

Items can accumulate Votes. Putting your Name on an Idea allows you to collect Votes on that Item.

Votes can be +/-1. Alternatively you can link to an item (this is like >>1 and <<1 in the voting model. The latter counts for as much credit as the Player has accumulated on their Player sheet.

Voting is the most basic means of Dialog in the Game and counts as an Interaction. Ultimately, Success is evaluated by Vote-counts.

The act of Voting is considered Work and earns Credit. For every vote you put on an item (- or +), tally a mark on the back of your Name piece. >> and << votes double your earned credit. Ideally, every vote should have a Vote-Item History. See TO-DO list.

Votes can be exchanged into Tokens. Tokens are quasi-physical objects with a fixed size and act like Energy in a physical system. Do note, that this Game (like all Games ultimately) depends on honest play and diligence on your part.


Players and Projects can expose Needs (i.e. Requests) and Offers (i.e. Invites). These are vectors, of negative and positive force, respectively. A Need (Pull) is denoted with an open Box, an Offer (Push) with a closed Dot.

A number next to this symbol specifies the amount being exposed or offered. Other users can add to that offer to show support. When a Need is fulfilled, the amount that was offered is given to the one who fulfilled it, plus. it gets filled, and the in as a credit, a transfer between giver(s) and receiver(s) takes place equal to each user's contribution.

Needs and Offers can present a Reward indicated by a number next to the Need/Offer receptor. The Reward cannot be more than the amount of Credit stored on the back of their Name. Tokens should be tacked behind the Player name and cannot be counted by Others, but may be inferred by size .

A Player can convert any amount of Votes into Tokens through the act of Transfer.

Achieving a Need or Offer earns the Reward presented (or as negotiated when there is contention). If no credit is shown, assume 1 credit.


A Group is a collection of one or more Items with a Name.

People can be collected into a Group and Tagged with a description. To Group without a Tag will cost one credit. Ideas can be organized into Projects. This costs one Credit (redeemable when the project is closed). A Project must have a Name.

The creator of the Group is the Head.

A Project with a Team is Alive and has a Crown node where it can receive.

A Group co-shares the amount of Credits of each participating Member (Note: a Member can potentially be an individual Player or another Group) unless a Member has chosen to limit the amount of Investment. This limit is always expressed as a percentage. When the percentage result is not an integer, choose randomly on the integer boundary for each transaction.

The Head can act on behalf of Group utilizing whatever Votes are available from each Member. A Group can collect its own store of value. Earned Income should be distributed in like way as Investment. The Head has to decide (in collaboration with members) how to distribute earned Income.

Individuals and Groups accumulate Votes separately, but you co-share the amount you have Invested in a Group.


To seed this process, this Game initializes with these Motivators:

  • The simple act of posting a item earns 1 credit (Token); this includes the creation and posting of your own Player/Name item.
  • Removing an Item also earns 1 credit -- IF it was there long enough to have observed or Interacted with by another.
  • Items removed from the board should be placed in a History File accessible by all.

TO-DO list:

(Note: These items can be viewed as work offers and earn credit.)

  • Each Vote should have a Credit-Player relationship
    • Different color pens for each person would work.
    • Take a snapshot of the items to relate, upload it to EverNote, tag as a group or a link, auto-create a graph.

[Old Version]: The user when starting Pangaia, after registering their username is presented with an empty black window. The application frame represents an implicit (user) node within the network. From here the fractal graph grows and is added to.


First a few notes: The Garden is an abstract space for unobstructed activity. However as an Application, it exists within the Universe we call "Reality". As such there are two descriptions of this project which are wholly orthogonal to each other: the description from within the Garden -- as an abstraction, and the description from the User's View (where they are working from a computer). As will be shown, this boundary is quite exotic and is akin to Maxwell's Demon -- where information and energy are interchanged. This is where this project skirts the fundamental completion between subject and object and unifies physics with information science.

Description from the User's View:

A Node is defined as a container with a Label. (Nodes without labels we'll just call "dirt" and can be freely used.) A Node that contains other nodes is called a Group.

A User starts, registers their Name, and is presented with a view in their "node". (Window title named with their Name) Initially the container is empty, so their view is an empty black window to an abstract space in which to do things. A variable count keeps track of how much Energy it has.)

This is a STUB.
The first node from a given user's point of view is the creation of their own node (made when they start the application and register a Name for themselves in the system). A Node with a non-zero count is considered Interesting and is visible to the Global Group (the Social Garden).

The dynamic action of clicking a node up or down is a special event: it is both registered as Energy (from the pov of the node clicked to) and Information (from the point of view of the window which tabulates the vote)

From a given frame (which should be conceptualized as a fractal node *up*), that node/frame keeps track of how much energy/clicks it has. A new user starts at count=0 (as all new nodes do), the title of his/her window is the name of the node (the user's Name). From this initial empty (black) window, a user can:

  1. Create a new (atomic) node, (a new project, a person they want to set relations to, a data item, etc.).
  2. Create a new grouping (or collection).
  3. Split a node (to form a question or to group independent tasks).
  4. Vote a node up or down +/-1 to set a trajectory which will trend a re-organization of the current view, the top voted node gets center.
  5. Push-to-top, push-to-bottom, which sticks those nodes at the top or the bottom of their current view window
  6. Enter a node, which creates an "inner-shell" within their current window from which their votes will "click-(i.e. pass-)through"
  7. Leave a node, which steps back to a larger-scale view.

The logical procedure (I *think*) is to put the name of the node (in this case the user's name) in the title of the window. It is not expected that the user will open any other windows except as (possibly) child-processes within their main user-view.

As the user clicks (votes) other nodes within their view up or down, each click puts cash-energy *into* the system (regardless of whether the valence of that click was up or down, +/-) and is tracked locally (in their window and on their machine) as #-of-votes (information). This is the key boundary where energy and information get traded/exchanged and is where the trends of information-science and physics merge. When a user clicks to "ascend-to-top", it makes a link from as many vote-counts as it has accumulated. So at the very beginning, ascend-to-top and vote up is the same because the user hasn't a"mass"ed any tokens/vote-counts (and the system hasn't accumulated any information on their interests). As they vote, they give energy on one side and information on the other. The *boundary* is the node itself.

The actual (computer) window frame of the data-view is one outward (or meta) -step away and is considered the current working/present node. The view it sees is a factor of what items it has pushed-to-top'd

Node creation necessitates node labeling. Labels on the outside acts as names and anchors, on the inside they are filters. As a node gets labeled, other related nodes may appear to offer the user a chance to determine whether the node really needs created. A label can act as an anchor, can be set sticky to the user's view.

Besides creating new nodes ex nihilo, nodes can be Split and they can be Grouped -- two opposite directions in the fractal graph data structure. Both compose a vertical axis -- the hierarchical part of the model.

All nodes are equal and behave the same, regardless of where they're at. However as nodes get labeled and used, various node-types emerge because the grouping operation will place them together; a node that is a person, for example, gets placed in the node-group called "People". This will seem like a lot of minutia at the beginning since the system starts as an empty slate, but useful grouping's will tend to get voted up until they eventually settle as obvious. This is a scale-free system, however from a given set of anchors, various node sizes will emerge.

For example the grouping called "Santa Fe Complex" might have the anchors: People, Projects

Node size The more nodes within a given grouping the bigger the node gets displayed, so

It's probably better to start with the wiki/square/article metaphor, than the atomic/spherical/ideal -- let it start rough and go to the ideal like cunningham made with the wiki. The voting conceptualization is simpler. There are two main axis

Example want: catalog all the books in the sf_x library Node idealization: point photon, and tick phonons. these are perpendicular to each other on constitute electric and magnetic forces. Node vocalizations: phonons When a transformation occurs between sound to light, the stars become a node, a label is needed,.

inner vs. outer relationship to phonon/photon A user can create a wanted item or an offer item, on the node they appear as divets and bumps -- in aggregate they will appear as motions/search, wounds and fruits

In the ultimately ideal, there is no label because the node itself is its name. Ultimately they go to the One Infinite Sphere Electric resonances connects complexity to similar complexities. geometrical (size, shape), textual, relational/directional; practical and ideal

(However, one could imagine populating the graph with Wikipedia, del.icio.us and such.)

A user clicks a node up or down and adds *energy* into the system but the *information* is stored at the user's node as number-of-votes. As I mentioned, "send-to-top" and "thumbs-up" are equal at the beginning (since the user's "purse" starts at zero), but as the user contributes vote-points on nodes, send-to-top starts to have *weight*, putting meaning into the system.

It's important to distinguish between send-to-top given from the user towards himself vs. toward the outward groupings.

From the perspective of the user "send-to-top" is seen as 100% vote (a sort of sticky within his/her node), but from the perspective of the larger whole, it only notches it up in relation to the total # of votes within the system. When there's only one user, this is equivalent, but as more users contribute, different interests start separating out various groupings and eventually whole galaxies and constellations within the graph start to emerge. (It's a significant feature of the unified model that no numbers are arbitrary in the system and every bit gets accounted for; iow, there are no "magic" numbers that get pulled from nowhere.)

To visualization this, nodes that are voted up or down are in disequilibrium until they find an order higher up the chain. The one's voted up have gravitational attraction toward the next-up node, those voted down, repel. If two nodes with the same name coalesce into the same position, they merge, otherwise there is a minimal repulsion to prevent collapse. This is the view from within; however, from the view of that next higher node-groupingthey show up in the flat view of the next higher node.

Here's where the organizational operation of the complex can start to be imagined.

Pauli's exclusion principal if two nodes that are dfi nodes with the same name have a merge operation, those of different names have a boundary repulsion; that is, they can make only the slightest contact at the surface. However, repulsion can be present as a function of number of down-votes made by the user, in comparison to upvotes at various levels of scaling.

Split Grouped, from user to other this former is a question, from user to self, it is a refinement. For the latter (grouped), from user to self, this is called "resolution or closure", from the point of user to other, this is collating,

Creating a node costs a point, Labeling it gives a point (this could probably be reduced to a no-op if the labeling is a mandatory act of node creation.)

In general every force has an equal and opposite counter-part, these opposites must be kept separate. Both >>/<< (energy charge) and +/-1 up or down must retain a boundary between the recipient and the voter. For +/-1 this is done by hiding the credit side behind the name piece; for charge, by the boundary of the node itself. The node repulsion barrier radius is a function of the number of down votes cast by that user.

Every node must be labeled. A rule of thumb when a node can be split is when there's a label for each (new) sub-node.

Personal tools