On Aera

Aera is the reputation protocol of Urbit. Aera is unbuilt, but it lives. It is nascent, existing under the skin of Urbit, waiting to be drawn out by some group of intrepid hooners. Aera is coming.

You can find out more about Aera at /1/group/~dalten/aera.

Areology of Aera (Aeraeology?)

Aera began as an extension of Gora, the first product produced by Quartus Co.

Gora

Gora is an analogy to POAPs on the Ethereum Network - it allows for individuals to provide “Proof of Something Tokens” to their friends. In contrast to the Ethereum Network, where NFTs are generally (1) re-transmissible, (2) managed by a contract, and (3) stored on-chain + ipfs for details, Gorae (the plural noun) were (1) soul bound, (2) wholly dependent on the issuer for management and allocation, (3) stored only in the state of the agent, shared only with those who need to know.

Meigora

Meigora, then, was an “Aera”-lite extension of Gora. The initial design of Meigora was to be a single application with both input interfaces and visualization interfaces for reputation. It focused on the three elements that made Gora different from POAPs: Urbit Identity Maximalism, User Centralization in Social Graphs, Private State Data.

Urbit Identity

The concept of Identity in human social interactions is unfortunately non-isomorphic to the concepts of Identity in most computing interactions. Wallet Addresses and IP Addresses are insufficiently (1) legible (2) unique and reserved (3) limited to serve as stand-ins for human social interactions.

Urbit proposes a namespace for all decentralized computers on the network that is:

1. Memorable and Legible:

   • For instance, ~rabsef-bicrym instead of 232.17.118.67 or 0x123…e594.

2. Unique and Reserved:

   • Urbit address space nodes are owned as an NFT on the Ethereum network

3. Limited and Costly:

   • While urbit address space is not particularly expensive, there is a cost associated with rotating one’s identity on Urbit (the cost of purchasing another identity).

User Centralization

Meigora let users create directed, acyclic graphs, centered on themselves, where the edges between nodes contain reputation information from the head of the edge to the tail of the edge. Consider this example of a graph owned by the ship ~rabsef:

• ~rabsef has given some reputation to ~dalten, ~sampel and ~marzod;

  • ~rabsef perceives of the graph of reputation in his universe as being based on his first order representation of trust.

  • ~rabsef, when giving positive reputation to some nodes, also subscribes to those nodes for public information they are emitting about their self-centralized graphs

    • This will probably utilize “solid state subscriptions” - the model of the rock and wave in SSS is conducive to a desireable, minimal diff transmission (of reputation changes) between ships in Aera.

  • ~rabsef does not have a first hand opinion about ~dozzod, but ~dalten, ~marzod and ~sampel all know ~dozzod.

• ~sampel, ~marzod and ~dalten maintain their own reputation graphs, centered on their own first order representations.

• Should any of ~rabsef’s first order connections know about ~dozzod, ~rabsef can query that information and accept it as a second order knowledge of ~dozzod’s reputation.

Private State Data v. Canonical Reputation

Meigora conceived of reputation as something that should not be “canonized” for a variety of reasons. Eschewing majority rule, Meigora would instead embrace divergence and disagreement. Returning to ~rabsef’s graph above, if ~marzod thought highly of ~dozzod, but ~sampel thought very poorly of ~dozzod, we thought it better to present that disparity to the user rather than attempting to paper over it with an average, which is an inappropriate measure of the difference of opinions between your two friends about a third party - particularly with a strong positive and a strong negative.

Product or Protocol

Meigora was to be a product, or at least, an application. It was designed to be self-contained, meaning the application (giving reputation to a node) and visualization would happen, both, within the product.

Aera will be a protocol. We expect to provide limited visualization and manual-adjustment functions in the Aera desk, itself, but ultimately Aera expects to gather data from other applications which will use a transformer library (which we will produce) to abstract the natural actions of the other application into reputation points for Aera. More on this, later.

A Reputation System By Any Other Name

美国, (trans-)literally “Beautiful Country”, is also the character diad colloquially given to America in modern Chinese. Meigora was used as a code name for this project to symbolize the beauty we perceived in this application of the Gora mentality to the subject of reputation.

Megaera, the Greek Fury of jealosy and envy, the punisher of criminals and those who break trust, and (co-)star of such media properties as Disney’s Hercules and Supergiant Games’s Hades was a natural word-association as we pivoted away from Meigora.

Aera is the new era of reputation systems, on Urbit.

Aera

Aera will be built across 5 milestones. Its ultimate design will include a protocol-agent that hosts each Urbit’s reputation graph, a transformer library that assists in the gathering of input data for reputational changes between nodes in other applications, and a visualization studio and manual editor for node ranking.

Design

Protocol Agent

Aera will store a fairly complex map (series of maps) which affords separate reputation maps to exist, per dude:gall. The names below are NOT FINAL, and are merely meant to provide human legible names to the other constructions for use in further explanations.

+$ doot  $@(@sd (map term @sd))
+$ coup  (mip ship ship doot)
+$ kudo  (map dude:gall coup)

`kudo`

At the top level, a kudo allows each application (or dude, in Urbit speak) to store their own map of reputation. The map of reputation itself, per dude is called a coup.

`doot`

At the bottom of the stack are doots.

The trivial case of a doot is some signed integer. It represents the claim of reputation (positive or negative) between two Urbit ships. The claim is always unidirectional - bidirectionality can be derrived using the information in a coup while avoiding the need to represent and update it at the bottom level.

A complex doot simply is a map of terms to trivial doots. Using a complex doot, an application dude can record reputation in subcategories to further refine the reputation being aggregated from using the dude

`coup`

The meat of Aera is the coup, a map of maps.

• The exterior key ship is an Urbit identity that represents some reputation facts about other Urbit ships.

• The interior key ships are those Urbit identities that have some reputation claim, per the exterior key ship, e.g. ~rabsef -> ~dalten = [coup].

• The most-interior value is a coup, always - whether complex or trivial.

• Each coup in a kudo in your version of Aera would have, at minimum, a top level key ship of your ship, to contain any first order claims of reputation you make about others.

Transformer Library

We want the experience of integrating with Aera to be trivial, even for pre-existing applications. To that end, we will produce a transformer library that will wrap an application and bolt on the additional functionality required to integrate. The library’s design specification will likely change, but the rough draft is as follows:

Aera’s transformer library will likely require a (unit @ud) to specify how many actions to keep in the record (a null unit would be the default of, say, 25), and a gate (or function) as an argument when calling it (the agent) into existence around your agent.

Suppose we have an application with the following actions, natively:

+$  actions

  $%  [%love ~]  ::  +2

      [%like ~]  ::  +1

      [%less ~]  ::  -1

      [%lame ~]  ::  -2

  ==

To integrate with aera, assuming no tags, and to keep 10 nouns in history for our user to review (to know what recent changes have affected reputation), we might instatiate with:

%-  %+  agent:aera-lib

      [~ 10]

    |=  n=noun

    ^-  $@(@sd (pair term @sd))

    =+  act=;;(actions n)

    ?-  -.act

      %love   -2

      %like   -1

      %less  --1

      %lame  --2

    ==

<my agent>

The transformer library will store a:

+$  state  (map ship (list noun))

The (list noun) will be a list of the n most recently inputted nouns that are of the type used as user actions in the application in relation to the ship to which that user action applies. Obviously, there will be times where user actions cannot be related to a specific, separate ship, as a reputational behavior - these can just be ignored. However, when a user’s action can be interpreted as suggesting a reputational change, that fact can be emitted to the library on the path /~/aera as a (pair ship noun).

Operational Loop

Upon receiving a (pair ship noun) on the /~/aera path, the transformer library will use the gate supplied in calling it into existence to interpret the noun into a change to coup for the ship in question, from your perspective. The resulting change of (pair ship $@(@sd (pair term @sd))) will be emitted to Aera for accounting purposes.

Further, Aera will be designed with scry paths that allow you to specify a ship and area of reputation you wish to query, potentially with a scry like:

.^(output %gx /=aera=/reputation/desk/ship/<maybe-term>/noun)

If the expected coup is not subdivided into a (map term @sd), you wouldn’t include the <maybe-term>. You’d get back something to the effect of the first, second, …, nth order reputation for that person.

 [ first=-10

    second={-8 -2 --1 -5}

    ...

    nth={}

  ]

The above output would signify a scenario where you’ve personally given 10 reputation points to the queried ship, at the second order (i.e. first order of the people you first order trust) you have friends who score mostly positive with one negative outlyer (–1), and at the later orders you have no addtional information. The decoherence of opinion at this second order deserves some examination and we are interested in pursuing mathematical models for signal decoherence as structures we could utilize in these types of scenarios.

Milestones

1. Initial Research and Modelling

   • Analyze existing theory for edge cases, limits, additional scenarios that impact our use.

   • Identify models for presenting information (Lombardi Graphs?);

   • Identify models for presenting divergent sheaves of information (when B and C disagree about D, from A’s perspective, where A knows nothing about D but reputes positively B and C, themselves);

   • Produce a white paper.

2. Protocol Agent and Library Workshopping and Design

   • Develop Agent and Library designs to “commentable” state;

   • Solicit feedback from Aera group insiders;

   • Potentially release Minaera test agent.

3. Protocol Agent and Library Release Candidates

   • Produce RCs for Developer Feedback.

4. General Release - Limited GUI

   • Protocol Agent will function to aggregate data, serve it on scry paths for use in other applications.

   • Transformer Library will function to interpret application data into coup-changes and pass the resulting facts to Aera.

5. Full Release with End-User GUI

   • Aera has its own presentation layer where users can view the reality of their reputation fabric, visually, and interact with it manually to override reputation values as they see fit.