Spec for `ob://` links

What are the valid ob://? It seems we have /store/... for listings. Are we still going to have /about, /followers? IPFS has it’s own path system and I’m concerned there will be collisions. Already QmZXGKrRRe5RTDhvzhZfSTe8vYBDGV7HBoNz5FS3U9FnUa/store is ambiguous, because in the context of IPFS this means the store object under QmZXGKrRRe5RTDhvzhZfSTe8vYBDGV7HBoNz5FS3U9FnUa. cc @cpacia

[jjeffryes]

Here’s a list of the valid addresses in the reference client:

• @[handle] - navigate to a user page based on a handle. Resolves to /store if the user has vendor set to true in their profile, otherwise resolves to /home.
• peerID - navigate to a user page based on the peerID. Resolves to /store if the user has vendor set to true in their profile, otherwise resolves to /home.
  • @[handle] or peerID can be followed by a / and ‘home’, ‘store’, ‘following’, or ‘followers’.
  • ‘/store’ can be followed by the slug for a listing, which will show the listing.
• transactions - will resolve to transactions/sales.
  • transactions can be followed by a / and ‘purchases’, ‘sales’, or ‘cases’.
• search?[query] - will load the search screen and execute the query. The query can have the following parameters:
  • providerQ = encoded url for the provider query. ex: providerQ=https%3A%2F%2Fsearch.ob1.io%2Fsearch%2Flistings%3Fq%3Dbananas%26p%3D0%26ps%3D12
  • q the term to search for
  • p the page to start on. If p = 3, page 3 of X will be shown.
  • ps the page size.
  • sortBy the value to sort by.
  • Other parameters will be treated as filters.

[rmisio]

Does transactions/ take a query? The reference client currently creates the following URI:

Yes, the url params map to the different ways to filter / sort the transactions list, for example:

ob://transactions/purchases?search=abcde&sortBy=UNREAD&states=0-1-2-3-4-5-6-7-8-9-10-11-12

Can we link to ratings?

You mean the “Reviews” section within the listing overlay? No, not that I’m aware of.

Can we link to a specific purchase?

Yes, add the orderId as query param:

ob://transactions/purchases?sortBy=UNREAD&states=0-1-2-3-4-5-6-7-8-9-10-11-12&orderId=QmVvcLYWk2z4itE9t8Jzbava8rs9iPw8HGKabYKay5evXv

FWIW, transactions and orders are something specific to a particular node, so I’m not sure how much it would make sense to share these (i.e. a link with an orderId could be shared between vendor and buyer, but for anyone else it will result in a Order not found state). The main reason the state is tracked in the url is a.) to be able to internally link to an order or a transactions list filtered in some specific way b.) If the user refreshes the page, their state is maintained.