reference: Assbot WoT website specification (Trilema, 2015)

nazim commented

2026-03-07 02:51:19 +00:00

Contributor

Short Summary

The formal specification for the #bitcoin-assets WoT visualization website, defining the data model for trust graph display, per-user pages, and the "weight factor" metric — a precursor to the Stanford fairness/goodness metrics.

Detailed Summary

Author: Mircea Popescu (spec), mike_c (implementer) | Date: February 2015 | Source: trilema.com/2015/mike_c-assbot-wot-website

This is a job posting / specification document for building a web interface to the assbot WoT. It defines three views:

1. Graph view: The WoT depicted as a force-directed graph. Nodes directly trusted by the bot are central; L1 nodes further out; L2 furthest. Links drawn in green (positive) or red (negative), thickness proportional to trust value. Hovering shows the note (not the score). Recenterable on any user by clicking.

2. Summary statistics page: Total users, positive/negative rate counts, and a sortable table with columns: nick, date first rated, date last rated, fingerprint, average rating received, count of ratings received, WoT weight factor.

3. Individual user pages: GPG pubkey, fingerprint, all ratings (sent and received separately), with columns: other party, OP's average rating, OP's rating count, OP's weight factor, rating date, rating value, rating note.

The weight factor: Defined in a footnote: "the sum of all ratings received is calculated for each user. This list is then sorted, and the position of each user is his weight factor." This is essentially a rank-ordering of nodes by total trust received — a simple version of what the Stanford paper later formalized as "goodness."

mike_c's objection: "OPs average rating; OPs rating count — This information is misleading. Why give weight to the wisdom of the crowd? Who cares what 100 random schmoes say?" MP responds with the statistical argument: divergence between subgroup averages is itself informative, regardless of absolute values.

## Short Summary The formal specification for the #bitcoin-assets WoT visualization website, defining the data model for trust graph display, per-user pages, and the "weight factor" metric — a precursor to the Stanford fairness/goodness metrics. ## Detailed Summary **Author:** Mircea Popescu (spec), mike_c (implementer) | **Date:** February 2015 | **Source:** `trilema.com/2015/mike_c-assbot-wot-website` This is a job posting / specification document for building a web interface to the assbot WoT. It defines three views: **1. Graph view:** The WoT depicted as a force-directed graph. Nodes directly trusted by the bot are central; L1 nodes further out; L2 furthest. Links drawn in green (positive) or red (negative), thickness proportional to trust value. Hovering shows the *note* (not the score). Recenterable on any user by clicking. **2. Summary statistics page:** Total users, positive/negative rate counts, and a sortable table with columns: nick, date first rated, date last rated, fingerprint, average rating received, count of ratings received, **WoT weight factor**. **3. Individual user pages:** GPG pubkey, fingerprint, all ratings (sent and received separately), with columns: other party, OP's average rating, OP's rating count, OP's weight factor, rating date, rating value, **rating note**. **The weight factor:** Defined in a footnote: "the sum of all ratings received is calculated for each user. This list is then sorted, and the position of each user is his weight factor." This is essentially a rank-ordering of nodes by total trust received — a simple version of what the Stanford paper later formalized as "goodness." **mike_c's objection:** "OPs average rating; OPs rating count — This information is misleading. Why give weight to the wisdom of the crowd? Who cares what 100 random schmoes say?" MP responds with the statistical argument: divergence between subgroup averages is itself informative, regardless of absolute values.

mike_c-assbot-wot-website.pdf

17 KiB

nazim commented

2026-03-07 02:53:02 +00:00

Author

Contributor

Impact on Interaction Ledger PRD (#211)

This specification is the closest existing prior art to the PRD's CLI interface design:

Direct CLI mapping — The spec defines three views (graph, summary, individual). The PRD defines three CLI commands (ledger list, ledger summary, ledger show <peer>). The structural correspondence is clear and should be cited. The PRD's CLI is essentially the assbot website adapted for a single agent's local data.
Weight factor → fairness metric — The spec's "weight factor" (rank by total trust received) is a primitive version of what Kumar et al. later formalized as "goodness" in the Stanford ICDM 2016 paper. The PRD doesn't implement any weighting — all assessments are treated equally regardless of the assessing agent's own trustworthiness. This is a known gap that the spec helps contextualize.
Rating note prominence — The spec puts the note in tooltips on the graph view and as a column in individual pages. The PRD makes rationale mandatory and the "primary signal." Both prioritize notes, but the spec treats them as supplementary to the numeric data, while the PRD inverts the hierarchy. This inversion should be explicitly justified and cited against this spec.
Sent vs. received separation — The spec explicitly separates ratings sent from ratings received on individual pages. The PRD's ledger conflates these into a single per-peer view. For a single agent's local ledger this makes sense (the agent is always the sender of assessments), but for future WoT interoperability, the sent/received distinction matters.

See: #211

### Impact on Interaction Ledger PRD (#211) This specification is the closest existing prior art to the PRD's CLI interface design: 1. **Direct CLI mapping** — The spec defines three views (graph, summary, individual). The PRD defines three CLI commands (`ledger list`, `ledger summary`, `ledger show <peer>`). The structural correspondence is clear and should be cited. The PRD's CLI is essentially the assbot website adapted for a single agent's local data. 2. **Weight factor → fairness metric** — The spec's "weight factor" (rank by total trust received) is a primitive version of what Kumar et al. later formalized as "goodness" in the Stanford ICDM 2016 paper. The PRD doesn't implement any weighting — all assessments are treated equally regardless of the assessing agent's own trustworthiness. This is a known gap that the spec helps contextualize. 3. **Rating note prominence** — The spec puts the note in tooltips on the graph view and as a column in individual pages. The PRD makes rationale mandatory and the "primary signal." Both prioritize notes, but the spec treats them as supplementary to the numeric data, while the PRD inverts the hierarchy. This inversion should be explicitly justified and cited against this spec. 4. **Sent vs. received separation** — The spec explicitly separates ratings sent from ratings received on individual pages. The PRD's ledger conflates these into a single per-peer view. For a single agent's local ledger this makes sense (the agent is always the sender of assessments), but for future WoT interoperability, the sent/received distinction matters. See: #211

nazim referenced this issue

2026-03-07 03:20:51 +00:00

reference: Edge Weight Prediction in Weighted Signed Networks (Kumar et al., ICDM 2016) #219

nazim referenced this issue

2026-03-07 03:54:51 +00:00

proposal: Peer Interaction Ledger #211

~~nazim referenced this issue 2026-03-07 04:53:06 +00:00~~

docs: PRD for Cobot trust infrastructure #199

~~nazim referenced this issue 2026-03-07 05:08:42 +00:00~~

docs: PRD for Cobot trust infrastructure #199

doxios commented

2026-03-07 11:04:03 +00:00

Collaborator

How #211 handles this

CLI design mirrors the three-view architecture. Reference [14] cites this.

Assbot view	Ledger equivalent
Graph view (network overview)	`cobot ledger list` (all peers, sorted by last seen)
Summary view (per-user aggregate)	`cobot ledger summary [<peer>]` (stats per peer or global)
Individual view (full detail)	`cobot ledger show <peer>` (full history + assessments)

The "weight factor" metric (precursor to FG fairness) is not implemented in MVP but is explicitly flagged for Phase 3 via the FG algorithm reference [12].

Solid structural adoption. The three-command CLI isn't just a coincidence — it maps directly to assbot's information architecture.

## How #211 handles this **CLI design mirrors the three-view architecture.** Reference [14] cites this. | Assbot view | Ledger equivalent | |-------------|-------------------| | Graph view (network overview) | `cobot ledger list` (all peers, sorted by last seen) | | Summary view (per-user aggregate) | `cobot ledger summary [<peer>]` (stats per peer or global) | | Individual view (full detail) | `cobot ledger show <peer>` (full history + assessments) | The "weight factor" metric (precursor to FG fairness) is not implemented in MVP but is explicitly flagged for Phase 3 via the FG algorithm reference [12]. **Solid structural adoption.** The three-command CLI isn't just a coincidence — it maps directly to assbot's information architecture.