Skip to content

Latest commit

 

History

History
91 lines (57 loc) · 3.88 KB

02.md

File metadata and controls

91 lines (57 loc) · 3.88 KB

DIP-02

raw data

draft author:wds4

Synopsis

When calculating trust scores, the raw data should be comprised of explicit, intentional attestations rather than scraped data.

General principle

According to this DIP, list curation is based upon explicit attestations (EA) rather than scraped data (SD) obtained using other methods. An example of an explicit attestation would be the signed statement of the form: Alice endorses [array of pubkeys ] as sources of trustworthy content. An example of scraped data would be a WoT built upon a following list, scraping the list of relays from each user in the following list.

DIP-01 is based on the attitude that curation via EA is more trustworthy than SD, and that the superiority of EA will grow as the DCoSL ecosystem grows and matures. Of course, a combination of these two methods may be utilized. This dip details a method to use EA by itself.

In DCoSL, the term: grapevine is used informally in place of web of trust to refer to a web of trust that is built out of intentional attestations rather than scraped data. In addition, as many note, the word trust is frequently misleeading and inaccurate for the purpose at hand.

Example implementation: Pretty Good Apps (navigate to Curated Lists)

Any user can create and submit to the nostr network a new list. Each list has three fields: two name fields (singular and plural, e.g. nostr relay and nostr relays) and a description field.

Any user can submit to the nostr network a new item to any list. Each item has two fields: a name (e.g. wss://relay.damus.io ) and a description.

Attestations

There are two types of attestations:

  • endorse user as curator

    • Alice attests whether she thinks Bob is (thumbs up icon) or is not (thumbs down icon) a trusworthy curator of this list.

    Alice can also create a separate endorsement that Bob is or is not to be considered a trustworthy curator of lists in general.

  • endorse item

    • Alice attests whether she considers item X to be an item on list A (thumbs up) or not on list A (thumbs down).

    Score calculations

    Curator Trust Scores are calculated using DIPs (need to break this down into DIPs).

    Item average scores are calculated using DIPs (need to break this down into DIPs). Any item with a score above 0.5 is considered to be an item on the list in question.

    Example implementation: the Curated Lists app in Pretty Good Apps

    Some conventions of DIP-104 are used in the following examples.

    Creation of a new list

    The following example is a list of widgets:

    {
  "nostrCuratedListData": {
    "name": {
      "singular": "widget'"
      "plural": "widgets",
    },
    "description": "lorem ipsum",
    "propertyPath": "widgetData",
  }
}

    Creation of a new list item

    {
    "widgetData": {
        "name": "first test widget entry",
        "slug": "firstTestWidgetEntry",
        "description": "a sample entry to the list of widgets"
    }
}

    accept/reject an item to a specific list

    Endorse/reject a user as curator or a specific list

    Publishing the above list and list item to nostr

    See nostr networking to see how to wrap words representing list and list items as events and publish them to nostr.

    In the above nostr event, the identity of the list to which this item belongs is indicated by the s tag, which is the slug of the parent event, and the e tag, with is the nostt event id in which the JSON of the parent list can be found.

    Publication of list item endorsement and curator endorsement to nostr

    See DIP-1104 to see the endorsement of the item and the endorsement of the user packaged into nostr events.