openbazaar / obips Goto Github PK

OBIP-0004: Posts

Proposal: https://github.com/OpenBazaar/obips/blob/master/obip-0004.md
Author: @drwasho

  OBIP: 4
  Title: Posts
  Author: Dr Washington Y. Sanchez
  Status: Draft
  Type: Standards Track
  Created: 2017-08-27

Abstract

• This OBIP describes the addition of a new type of content that can be published and shared on the network by users: posts
• Posts enable a user to publish written content that can be viewed by other users visiting their store or via third party search
• Posts can be used for market-related activities such as: advertising listings, announce store updates, publish a new coupon for a special offer etc
• Moreover, posts can also be used for non-market activities and serve as a platform for censorship-resistant expression on the network, encouraging non-vendors to regularly use the network

Motivation

OpenBazaar has limited tools for Vendors to engage with potential customers. Engagement can be in the form of advertising a listing, announcing a store update, brand-building, announcing special offers or coupons for a sale to name a few. Users in general can also benefit from these tools by blogging interesting items they have seen on the network, and driving sales for Vendors (i.e. OB influencers).

Aside from side-channels (i.e. off the OpenBazaar network), Vendors can only communicate to potential buyers via the About section of their profile, or via direct message. The About section is limited in form and function, and its history is not traversable. Direct message is excellent for one-on-one communication, but it can only be initiated by a user visiting the store.

What is required is a means for Vendors to publish a blog-style post that users can view when visiting their store.

Requirements

Posts allow a Vendor to upload a message or image in a dedicate space in their store. Posts have traversable history, designed for one-way communication from the Vendor to users. The purpose of posts is to inform visitors of any content they feel necessary to drive sales and/or engage with users (i.e. announcements, brand building, promotions, coupons etc).

User Stories

Role: Publisher

A 'publisher' is a vendor or user that is publishing a post on their node for other users to consume.

1. As a Publisher, I can post a message {text, image} that is displayed in my store.
2. As a Publisher, I can edit a message that is displayed in my store.
3. As a Publisher, I can delete a message this is displayed in my store.
4. As a Publisher, I can traverse a history of messages in my store.

Role: User

1. As a user, I can read a message {text and/or image} posted by a Publisher.
2. As a user, I can traverse a history of messages {text and/or image} posted by a Publisher.

Specification

A post should allow the publisher to include:

1. A short title (max. 280 characters)
   • The title field can be used as a title for a long-form post, or as a microblog post in itself (i.e. tweet-style).
2. A long-form post (max. 50,000 characters)
   • This field is used for blog-style posts
3. Images
   • An array of up to 30 images can be attached to the post
4. Tags
   • An array of up to 40 tags
5. A timestamp

All posts need to be digitally signed to establish authenticity, and will include a slug for IPNS resolution so the publisher can edit their post.

Protobuf

The protobuf spec:

syntax = "proto3";
option go_package = "pb";


import "google/protobuf/timestamp.proto";
import "contracts.proto";

message Post {
    string slug                         = 1;
    ID vendorID                         = 2;
    string title                        = 3;
    string longForm                     = 4;
    repeated Image images               = 5;
    repeated string tags                = 6;
    google.protobuf.Timestamp timestamp = 7;

    message Image {
        string filename = 1;
        string original = 2;
        string large    = 3;
        string medium   = 4;
        string small    = 5;
        string tiny     = 6;
    }
}

message SignedPost {
    Post post           = 1;
    string hash         = 2;
    bytes signature     = 3;
}

API

We propose that OpenBazaar server-node implementations support the following endpoints:

1. GET /ob/posts
2. GET /ob/post
3. POST /ob/post
4. PUT /ob/post
5. DELETE /ob/post

GET ob/posts

Returns an array of posts from the user or a peer (i.e. /ob/posts/:peerId):

[
    {
        "hash": "zb2rhdrJUgp17bvjnEW98s9C2eToZHep1eh5i7SBp9jhBpREA",
        "images": [
            {
                "medium": "zb2rhaFhqziCWk1zo5tMRxQEUchfvJFaGG4DY1anEoR4GnYrN",
                "small": "zb2rhbDCeEiTTunugWPaRRKFCfNKUaB7aCR53nrPnMa9usZXY",
                "tiny": "zb2rhgqJDbshwAgPjs7X2h4mDm3V3BpLbp4tFGqkg1LNkg9yV"
            },
            {
                "medium": "zb2rhY4sqZehNgKD7ehxHiG7z3wnpKZEeNccWxrfx1GmAckxy",
                "small": "zb2rhhMRWCb5ozMdez8JePnZnh9WRxyTCJVNk7CfLNVVaUmhz",
                "tiny": "zb2rhmxApBVCHh426vnYSJGSDH4KpKpqKyvY2CAWmaiuHd8tZ"
            }
        ],
        "slug": "multiimagetest",
        "tags": [
            "zb2rhXoKEJtXxB5pcxhmcLu1aCCY3MRHR1Vc4tSJMyzPy8KJv",
            "#freeWynona"
        ],
        "timestamp": "2017-10-05T00:13:53.892275067Z",
        "title": "multiimagetest"
    }
]

GET ob/post

Returns an individual post from the user or a peer (i.e. /ob/post/:peerId/:slug_or_hash):

{
    "post": {
        "slug": "multiimagetest",
        "vendorID": {
            "peerID": "QmVdst57mJuW8Tr9owADqWmirY5Gao9zZMnbbL4WavKJvB",
            "handle": "",
            "pubkeys": {
                "identity": "CAESIEokc1r9Wfe4IyqA9P/56dO+5W1Hv9eOi2PXdUBDUf5X",
                "bitcoin": "AjjghznFUNeAkgmEdKYOESzj+PXFvVHUv+jbNWWQKkwG"
            },
            "bitcoinSig": "MEQCIAaKg1Cr676NVo7dz1KibSvvhjyrAXQceYakKwYR13+oAiBmAWqIyTWMuMPeVItwPzS1N2SDYeR5H4cD+uxGv1AghQ=="
        },
        "title": "multiimagetest",
        "longForm": "This is a test post dawg.",
        "images": [
            {
                "filename": "cat",
                "original": "zb2rhe2o6WbHqcER5VUKsMUbQrmpCC6ihg8qZ4JS9wVgKz9wm",
                "large": "zb2rhmBUB9i7UkfmeD3obJYK3FFS5K8N8QHaUanG8UWLVBHiY",
                "medium": "zb2rhaFhqziCWk1zo5tMRxQEUchfvJFaGG4DY1anEoR4GnYrN",
                "small": "zb2rhbDCeEiTTunugWPaRRKFCfNKUaB7aCR53nrPnMa9usZXY",
                "tiny": "zb2rhgqJDbshwAgPjs7X2h4mDm3V3BpLbp4tFGqkg1LNkg9yV"
            },
            {
                "filename": "random",
                "original": "zdj7Wazpqc5dGZ9yyKweKGjkGF3mAj5cjrWSV3QisHU34UsaQ",
                "large": "zb2rhemVicsnTAo454S6Cdq2Ct677B47ArbQ7AqNtWYWUbvBQ",
                "medium": "zb2rhY4sqZehNgKD7ehxHiG7z3wnpKZEeNccWxrfx1GmAckxy",
                "small": "zb2rhhMRWCb5ozMdez8JePnZnh9WRxyTCJVNk7CfLNVVaUmhz",
                "tiny": "zb2rhmxApBVCHh426vnYSJGSDH4KpKpqKyvY2CAWmaiuHd8tZ"
            }
        ],
        "tags": [
            "zb2rhXoKEJtXxB5pcxhmcLu1aCCY3MRHR1Vc4tSJMyzPy8KJv",
            "#freeWynona"
        ],
        "timestamp": "2017-10-05T00:13:53.892275067Z"
    },
    "hash": "zb2rhdrJUgp17bvjnEW98s9C2eToZHep1eh5i7SBp9jhBpREA",
    "signature": "evhmoAw3S/Qx3lmTStd0esnhPjwgWCfRncpGltyLjW3wPG7Gh8kd4uRSsS+LwoPMpVVvibLuIDi0WwyfsrkODA=="
}

POST /ob/post

Creates a new post:

{
	"title": "multiimagetest-4",
	"longForm": "This is a test post dawg.",
	"images": [{
			"filename": "cat",
			"large": "zb2rhmBUB9i7UkfmeD3obJYK3FFS5K8N8QHaUanG8UWLVBHiY",
			"medium": "zb2rhaFhqziCWk1zo5tMRxQEUchfvJFaGG4DY1anEoR4GnYrN",
			"original": "zb2rhe2o6WbHqcER5VUKsMUbQrmpCC6ihg8qZ4JS9wVgKz9wm",
			"small": "zb2rhbDCeEiTTunugWPaRRKFCfNKUaB7aCR53nrPnMa9usZXY",
			"tiny": "zb2rhgqJDbshwAgPjs7X2h4mDm3V3BpLbp4tFGqkg1LNkg9yV"
		},
		{
			"filename": "random",
			"tiny": "zb2rhmxApBVCHh426vnYSJGSDH4KpKpqKyvY2CAWmaiuHd8tZ",
			"small": "zb2rhhMRWCb5ozMdez8JePnZnh9WRxyTCJVNk7CfLNVVaUmhz",
			"medium": "zb2rhY4sqZehNgKD7ehxHiG7z3wnpKZEeNccWxrfx1GmAckxy",
			"original": "zdj7Wazpqc5dGZ9yyKweKGjkGF3mAj5cjrWSV3QisHU34UsaQ",
			"large": "zb2rhemVicsnTAo454S6Cdq2Ct677B47ArbQ7AqNtWYWUbvBQ"
		}
	],
	"tags": [
		"zb2rhXoKEJtXxB5pcxhmcLu1aCCY3MRHR1Vc4tSJMyzPy8KJv",
		"#freeWynona"
	]
}

PUT /ob/post

Edits an existing post:

{
	"slug": "multiimagetest4",
    "title": "multiimagetest-4",
	"longForm": "This is a test post yo.",
	"images": [{
			"filename": "cat",
			"large": "zb2rhmBUB9i7UkfmeD3obJYK3FFS5K8N8QHaUanG8UWLVBHiY",
			"medium": "zb2rhaFhqziCWk1zo5tMRxQEUchfvJFaGG4DY1anEoR4GnYrN",
			"original": "zb2rhe2o6WbHqcER5VUKsMUbQrmpCC6ihg8qZ4JS9wVgKz9wm",
			"small": "zb2rhbDCeEiTTunugWPaRRKFCfNKUaB7aCR53nrPnMa9usZXY",
			"tiny": "zb2rhgqJDbshwAgPjs7X2h4mDm3V3BpLbp4tFGqkg1LNkg9yV"
		},
		{
			"filename": "random",
			"tiny": "zb2rhmxApBVCHh426vnYSJGSDH4KpKpqKyvY2CAWmaiuHd8tZ",
			"small": "zb2rhhMRWCb5ozMdez8JePnZnh9WRxyTCJVNk7CfLNVVaUmhz",
			"medium": "zb2rhY4sqZehNgKD7ehxHiG7z3wnpKZEeNccWxrfx1GmAckxy",
			"original": "zdj7Wazpqc5dGZ9yyKweKGjkGF3mAj5cjrWSV3QisHU34UsaQ",
			"large": "zb2rhemVicsnTAo454S6Cdq2Ct677B47ArbQ7AqNtWYWUbvBQ"
		}
	],
	"tags": [
		"zb2rhXoKEJtXxB5pcxhmcLu1aCCY3MRHR1Vc4tSJMyzPy8KJv",
		"#freeWynona"
	]
}

DELETE /ob/post

Deletes an existing post: /ob/posts/:slug_or_hash

Rationale

Advantages

1. Allows for users to engage with visitors and promote sales
2. Creates basic tools for an influencer and affiliate program
3. It is a platform for censorship-resistant expression

Disadvantages

• index.json file can get bloated if there are a lot of posts
  • This could potentially be mitigated by only storing hashes of the post in an array

Backwards Compatibility

This OBIP extends the protocol and creates a collection of new APIs, as well as a new directory to store posts. This means that non-upgraded nodes will not be able to fulfil API calls for posts if requested. The server will return a standard error for unrecognised API calls.

Posts do not alter the existing database or API calls, so disruption to clients should be minimal. As a result, clients can choose to support this feature - if at all - at their leisure.

Reference Implementation

https://github.com/drwasho/openbazaar-go/tree/posts

Introduction

The OpenBazaar protocol can adopt new features via the OpenBazaar Improvement Proposal (OBIP) process. It allows anyone in the community to create a proposal for a new feature.

To get started, please read OBIP-0001 carefully to familiarise yourself with how to create an OBIP. It should be clear that OBIPs aren't a simple feature request [1], rather it is a place to submit a detailed specification that - if accepted - will be adopted into the protocol and implemented into code.

Feedback Phase

After an OBIP is accepted as a 'draft', the author of the OBIP will need to oversee the collection feedback from the community. To facilitate this, the 'issues' section of the OBIPs repo will be the central place to discuss draft OBIPs.

The author will create an issue for their OBIP (i.e. OBIP-XXXX: [Insert title here]). Members of the community will have a reasonable timeframe (at least 2 weeks) to comment, suggest changes, or raise objections. The author can interact with the community, make their case, and present changes based on feedback.

The author is fully expected to drive this process. Any OBIPs that have stalled in discussion due to the lack of the author's initiative will be gracefully retired.

Members of the community are expected to participate. It is the individual responsibility for anyone involved in OpenBazaar to leave feedback and participate in forming rough consensus. Failure to participate will be counted as an abstention. Moreover, the feedback phase at least 2 weeks (sometimes more depending on revisions), which is ample time to participate.

Rough Consensus

Rough consensus will be measured according to the following criteria:

1. Accept. The proposal is accepted.
2. Minor revisions. The proposal requires minor revisions before it can be accepted, but the concept is accepted.
3. Reject and resubmit. This should be resubmitted as a new proposal after significant revisions.
4. Reject. The proposal is rejected; no amount of revisions will be satisfactory as the concept is fundamentally rejected.

The author should keep a running tally of participant's opinions in the initial post, and edit the post to update it.

Contentious OBIPs

If there is some warm or hot disagreement regarding an OBIP, the discussion should immediately be paused in the issue and an online chat scheduled between both points of view (or representatives of both points of view).

More often than not, issues can be quickly and calmly resolved via a Google Hangout. However, if a compromise solution cannot be reached, a tie-breaking decision will be made by @hoffmabc.

OBIP Acceptance

If an OBIP has found rough consensus for acceptance, then a PR with working and testable code should be made to the openbazaar-go server repo with a title matching the corresponding OBIP for review.

Clients are under no obligation to immediately implement any new features in the protocol, unless it is a coordinated and critical upgrade.

Backwards Compatibility

It is critical that all OBIPs clearly delineate the impact its changes will have on the protocol, server, and clients (desktop, mobile, browser) - if any.

Conclusion

The OBIP process is designed to: 1) bring clarity to how changes in the protocol will be approached going forward, and 2) encourage developers to get involved to expand the utility of OpenBazaar for all users.

The OBIP process will continue to evolve as we learn what works, and what doesn't. Finally, at all times you must communicate with your peers respectfully and objectively. Abuse or assholism will not be tolerated.

[1] An issue will be created to collect simple feature requests that community members can turn into OBIPs.

OBIP-0005: Classifieds

Proposal: https://github.com/OpenBazaar/obips/blob/master/obip-0005.md
Author: @drwasho and @cpacia

  OBIP: 5
  Title: Classifieds
  Author: Dr Washington Y. Sanchez and Chris Pacia
  Status: Draft
  Type: Standards Track
  Created: 2017-08-27

Abstract

This OBIP describes the design of a 'classified'. Classifieds enabled a user can create a type of listing that can be used as a non-purchasable ad, where settlment of the listing takes place outside of OpenBazaar's internal wallet.

Motivation

OpenBazaar currently assumes all settlement will take place using Bitcoin via its internal wallet. However, many users may wish to take advantage of OpenBazaar's growing user-base, hosting & listing infrastructure to advertise their goods and services, but settle the transaction with buyers outside of Bitcoin.

Requirements

Classifieds enable the user to create a new listing type in addition to physical goods, digital goods, and services. This listing type cannot be purchased within OpenBazaar, but allows for all of listing functionality.

Specification

The specification calls for a change to contracts.pb, where a new ContractType is enumerated: CLASSIFIED.

enum ContractType {
    PHYSICAL_GOOD = 0;
    DIGITAL_GOOD  = 1;
    SERVICE       = 2;
    CROWD_FUND    = 3;
    CLASSIFIED    = 4;
}

All nodes must reject purchases of a 'classified' listing type.

Rationale

Advantages

1. Extends the functionality of OpenBazaar
2. Allows vendors who are not into Bitcoin to list on a decentralised marketplace, and can serve as a gateway to draw these people into cryptocurrency

Disadvantages

1. Search indexes will need to filter-out classifieds from physical, digital, and service listing types
2. Dedicated interface required for viewing classifieds that needs careful thought to avoid confusion for users

Backwards Compatibility

1. Non-upgraded nodes will not be able to create a classified. Since classifieds cannot be purchased by design, no major compatibility issues for purchasing should exist.
2. Clients typically display a store tab or view, where all of the user's listings are visible. Classifieds would need to be excluded from this list to prevent confusion, and a scenario where a user would attempt to purchase a classified. As a result, a store tab/view should only show listing types: PHYSICAL_GOODS, DIGITAL_GOODS, or SERVICES. Incidentally this is something that would need to happen necessarily as the protocol expands to support other listings types. Filtering out the CLASSIFIED listing type is similar to filtering out listings that do not ship to your country.
3. Search engines would need to factor-in what listing types are indexed, and what listing types are served by their endpoints. Search engines may elect to provide an endpoint dedicated to search for only classifieds.

Reference Implementation

https://github.com/drwasho/openbazaar-go/tree/new_classifieds

OBIP-0003: Channels

Proposal: https://github.com/OpenBazaar/obips/blob/master/obip-0003.mediawiki
Author: @cpacia

  OBIP: 3
  Title: Channels
  Author: Chris Pacia 
  Discussions-To: #openbazaar-2_0 on Slack, Github Issues, or 
  Status: Draft
  Type: Standards Track
  Created: 2017-9-27
  License: Public Domain

Abstract

Channels are a feature designed to improve the browsing experience in OpenBazaar. Being a decentralized application OpenBazaar faces challenges displaying interesting, relevant, and timely content to users. Most e-commerce platforms solve this problem by using their access to their centralized listing database to curate content for their home page or category landing pages. Since most OpenBazaar implementations are oriented towards consumers and run on either home computers on or mobile devices, it's not feasible for the software to index all listings.

One strategy for dealing with this limitation is to have the application download content from a centralized curator. While this approach would mostly work, it goes strongly against OpenBazaar's core value of decentralization.

The alternative presented here is to open the curation to everyone and allow users to seed their curated content on the OpenBazaar network. By allowing everyone to participate in curation we avoid having a single point of failure. Further we can take advantage of OpenBazaar's distributed architecture to distribute the content around the network ensuring the data will remain available even if the content creator is offline.

Definitions

A channel is one or more user curated pages of content.

A page is a static JSON document containing one or more views that is interpreted by clients. Pages can contain links to other pages creating a browsing experience similar to that of the web.

A view is the most basic element on a page. It contains the data to be displayed and information about how to display it.

Specification

Channel Schema

The channel schema consists of a JSON object containing some metadata and a list of views (to be rendered in order veriticaly):

{
  "name": "OB1",
  "logo": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
  "slug": "index",
  "lastUpdated": ""2017-09-28T03:15:51.785762669Z",
  "searchEndpoint": "https://search.ob1.io/search/listings",
  "onClick": "https://clickdata.ob1.io/channel",
  "onLoad": "https://loaddata.ob1.io/channel",
  "version": 1,
  "views": [
    // views here
  ]
}

Only name, logo, slug and views are required. onClick and onLoad are endpoints which clients are expected to POST to for data collection purposes. The POST body should contain the loaded page URI for onLoad or the URL of the clicked item for onClick.
The current version is 1. Slug must unique for each page and set to index for the main channel page.

Types of Views

ImageView

Self explanatory. Used for banner images, product promotions, etc. Images should be hosted on IPFS and can optionally link to a product or another page. Links may use either ob:// (for listings, user pages, or channel pages) or http:// (for channel pages only).

{
  "type": "IMAGE_VIEW",
  "imageHash": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
  "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page",
  "height": 275,
  "width": 580
} 

TextView

Display text on the page.

{
  "type": "TEXT_VIEW",
  "text": "Welcome to my channel!",
  "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page",
  "size": 28,
  "font": "noto sans",
  "color": "#343434",
  "align": "center"
} 

ListingGridView

A 4 by x grid of listing cards. Title should be displayed at the top of the view. Button is optional and it displays at the
bottom of the view and gives the ability to link to another page. The listing data must be included.

{  
   "type":"LISTING_GRID_VIEW",
   "title":"New Listings",
   "button":{  
      "Text":"See More",
      "Link":"ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page"
   },
   "listings":[  
      {  
         "vendor":{  
            "id":"QmWBSdbs7LLR7BdFgtKQA7CUq8aCzoTi74V7UwiwvfYpU5",
            "handle":"@yPayne",
            "avatarHashes":{  
               "tiny":"QmTHCaDpznJStWvPUSiKNDd53VVZmPtnrHx5diGP5gskCx",
               "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ"
            }
         },
         "data":{  
            "hash":"zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
            "slug":"air-direct-amplifier",
            "title":"Air Direct Amplifier",
            "thumbnail":{  
               "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ",
               "medium":"QmS1z4qW1SiDNtLD1Bfno8WEbFUV8qwb5CQxgR6BREyVTJ"
            },
            "price":{  
               "currencyCode":"btc",
               "amount":34
            },
            "nsfw":true
         }
      }
   ]
}

PaginatedListingView

Similar to the ListingGridView but designed to allow a large number of listing cards to be displayed on the page by using pagination. Clients are free to decide how many listings to display per page and whether or not to offer sorting functionality.

{  
   "type":"PAGINATED_LISTING_VIEW",
   "count": 200,
   "listings":[  
      {  
         "vendor":{  
            "id":"QmWBSdbs7LLR7BdFgtKQA7CUq8aCzoTi74V7UwiwvfYpU5",
            "handle":"@yPayne",
            "avatarHashes":{  
               "tiny":"QmTHCaDpznJStWvPUSiKNDd53VVZmPtnrHx5diGP5gskCx",
               "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ"
            }
         },
         "data":{  
            "hash":"zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
            "slug":"air-direct-amplifier",
            "title":"Air Direct Amplifier",
            "thumbnail":{  
               "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ",
               "medium":"QmS1z4qW1SiDNtLD1Bfno8WEbFUV8qwb5CQxgR6BREyVTJ"
            },
            "price":{  
               "currencyCode":"btc",
               "amount":34
            },
            "nsfw":true
         }
      }
   ]
}

UserGridView

A 4 by x grid of user cards. Title should be displayed at the top of the view. Button is optional and it displays at the
bottom of the view and gives the ability to link to another page. The user profile data must be included.

{  
   "type":"USER_GRID_VIEW",
   "title":"Top vendors",
   "button":{  
      "Text":"See More",
      "Link":"ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page"
   },
   "users":[  
      {  
          "id":"QmWBSdbs7LLR7BdFgtKQA7CUq8aCzoTi74V7UwiwvfYpU5",
          "handle":"yPayne.id",
          "avatarHashes":{  
             "tiny":"QmTHCaDpznJStWvPUSiKNDd53VVZmPtnrHx5diGP5gskCx",
             "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ"
          },
          "headerHashes":{  
             "tiny":"QmTHCaDpznJStWvPUSiKNDd53VVZmPtnrHx5diGP5gskCx",
             "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ"
          },
          "shortDescription": "Webstore specialized in selling unique, interesting and high-quality..."  
      }
   ]
}

PaginatedUserView

The user card equivilent of PaginatedListingView.

{  
   "type":"PAGINATED_USER_VIEW",
   "count": 200,
   "users":[  
      {  
          "id":"QmWBSdbs7LLR7BdFgtKQA7CUq8aCzoTi74V7UwiwvfYpU5",
          "handle":"yPayne.id",
          "avatarHashes":{  
             "tiny":"QmTHCaDpznJStWvPUSiKNDd53VVZmPtnrHx5diGP5gskCx",
             "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ"
          },
          "headerHashes":{  
             "tiny":"QmTHCaDpznJStWvPUSiKNDd53VVZmPtnrHx5diGP5gskCx",
             "small":"QmfVecQaoy1pZD3wsHHC82kYg24yhVaqBsAzm5aJCabXPQ"
          },
          "shortDescription": "Webstore specialized in selling unique, interesting and high-quality..."  
      }
   ]
}

SlideshowView

A view which which rotates through the provided image views.

{
  "type": "SLIDESHOW_VIEW",
  "height": 250,
  "width": 400,
  "images": [
    {
      "imageHash": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
      "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page"
    }
  ]
} 

CategoryView

A list of categories for the client to render. The optional field breadcrumbs is used to display the current nesting.

{
  "type": "CATEGORY_VIEW",
  "categories": [
    {
      "name": "Marvel",
      "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/marvel"
    },
    {
      "name": "Spiderman",
      "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/spiderman"
    },
    {
      "name": "Superman",
      "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/superman"
    }
  ],
  "breadcrumbs": [
    {
      "name": "Books",
      "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/books"
    },
    {
      "name": "Comic Books",
      "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/comic_books"
    }
  ]
} 

HBox

An HBox allows ImageViews to be aligned horizontally next to each other. HBoxes can be nested inside other HBoxes or inside VBoxes. Only ImageViews, TextViews, HBoxes, and VBoxes are currently supported inside HBoxes. All other types should be ignored.

{
  "type": "HBOX",
  "padding": 10,
  "views": [
  	{
	  "type": "IMAGE_VIEW",
	  "imageHash": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
	  "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page",
	  "height": 275,
	  "width": 580
	},
	{
	  "type": "IMAGE_VIEW",
	  "imageHash": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
	  "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page",
	  "height": 275,
	  "width": 580
	} 
  ]
} 

VBox

A VBox allows ImageViews to be aligned vertically on top of each other. VBoxes can be nested inside other VBoxes or inside HBoxes. Only ImageViews, TextViews, HBoxes, and VBoxes are currently supported inside VBoxes. All other types should be ignored.

{
  "type": "VBOX",
  "padding": 10,
  "views": [
  	{
	  "type": "IMAGE_VIEW",
	  "imageHash": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
	  "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page",
	  "height": 275,
	  "width": 580
	},
	{
	  "type": "IMAGE_VIEW",
	  "imageHash": "zb2rhcQdW4Jb9YmJUASEumQg4xetuc9tob9Hofn24g74c12p7",
	  "Link": "ob://QmYj1ojj3cRKrmkQR3o8KtPqmTbgsZWsgq5grpUpAbjiYx/channel/another_channel_page",
	  "height": 275,
	  "width": 580
	} 
  ]
} 

Loading a channel

When entering and saving a new channel a user should be able to enter either an OB URI (ob://ob1.io/channel) or HTTP URL (https://ob1.io/channel).
Clients should be able to fetch the main page json from either source.

Extensibility

Clients should ignore view types they do not know how to parse. This allows us to introduce new views without breaking old clients.

FAQ

Will the channel be slow to load and provide a bad experience?

This OBIP calls for listing data and user data to be provided in each view which means the only loading that needs to be done is the initial JSON document and images. It would be great to make it so these views do not need to provide the data and instead it could be fetched from IPNS but current IPNS speeds are too slow for this to be feasible. As IPNS optimizations come to fruition this option can be revisted.

As for initial page load, pages served over IPNS will be subject to IPNS load times but serving pages via HTTP is an option for those that care about page load speed and have the resources and technical knowledge to do so. Serving pages via HTTP also allows for dynamic page creation.

Given that the data must be provided with each view, wont the channel data get stale?

For pages served via HTTP the server can build the page using the most up to date data it knows about.

For pages served via IPNS, the responsibility falls on the channel creator to update and republish their channel periodically. Implementions can fairly easily provide automated functionality to iterate over the channel data, update each listing/user with current data, and republish. How stale a channel is will be dependent on the tools one use to curate the channel and how committed they are to maintaining it.

Wont users see a bunch of unmaintained channels with stale data?

Channels served via IPNS will drop out of the network after a week if the creator does not republish his data. It's unlikely stale channels will persist. Additionally this OBIP does not specify channel discovery which could itself be curated by a channel and only list well maintained channels.

How does a user actually curate a channel? Do they need a crawler? What tool do they use? Or is it entirely a manual process?

Curation is not specified by this OBIP as it will depend on the tools available to the user. API calls to create, update, and publish a channel are pretty easy to create and fairly easy to use. Crawlers are not needed per se as curators can find listings via other channels or via search. Though specialized crawlers might be desireable for curating listings behind Tor, as an example. Open source crawlers that do this already exist.

Less technical users will probably need to wait until UIs are created which make building channels more user friendly. Even without such UIs simply creating a JSON text file is orders of magnitude easier to do than building a search engine and a step in the right direction.

Is the average person going to do this? What is their incentive to do so?

Average people creating and sharing channels would certainly improve user engagment and interaction with the app but isn't necessary for the purpose of improving the browsing experience. The user experience would still be much improved if only several big players create and maintain channels provided that there is free entry and competition.

Further, there may be a financial incentive to create a channel. It's pretty trivial right now to create a "Buy ad space on my channel" listing which may provide a revenue stream large enough to compensate for the time invested into maintaining the channel.

Isn't there going to be all kinds of cross platform issues when rending the channel?

The channel schema provides the data to be displayed and a rough suggestion about how that data should be used. It's up to each client implementation to decide how best to render the data. For example, the ListingGridView might work well as a 4x2 grid on desktop, but mobile designers may choose to render it as an ImageSwitcher with swipe gestures. Futher platform specific channels can also be created, ex) ob://ob1.io/channel/mobile.

Doesn't this design preclude things pagination and/or sorting by price/rating, etc?

No. The PaginatedListingView and PaginatedUserView can probably hold several thousand listing/user data objects while still keeping the page to a reasonable size. Clients can paginate the listings/user cards and offer sorting as they desire. Should a page require more than one thousand listings, say, it would probably make sense, both from a UX and efficiency perspective, to break that view up into separate pages. For example, if you are trying to build a page that contains comic book listings and you have more than one thousand comic books, you should probably break the page up into multiple pages of comic book subcategories.

This is a catch all issue to record basic feature requests for OpenBazaar, and track whether or not they have been OBIP'd.

Please have discussion about OBIP 0006 here.

OBIP-0002: 3rd Party Search Providers

Proposal: https://github.com/OpenBazaar/obips/blob/master/obip-0002.md
Author: @tyler-smith

Currently, the 'options..options' object in the 3rd party search response is a list of dictionaries. I don't quite see why this is a list of dictionaries, and not a dictionary its self. At least, with some options/facets such as shipsTo, which has lots of possible options/values, it can take some time to loop through the list to find the correct dictionary. By changing this to a dictionary, like I have hopefully shown below, it could speed up search provider responses and the schema should make more sense. Maybe I am overlooking the reason for this being a list idk.

suggestion:
https://gist.github.com/maxharrison/72b955a3f93e9c6eaf1d787a647f36ec

If a listing has the CRYPTOCURRENCY contract type, it should include the metadata.coinType, metadata.coinDivisibility and the remaining inventory (from the upcoming inventory api).