openbazaar / openbazaar-desktop Goto Github PK

The User Page Store Tab is one of the tabs on the User Page. It should be shown when:

• the user clicks on the store tab in the User Page.
• the user enters an address with the store in the route (ie: /guid/store [routing is still being finalized]).
• the user clicks on an internal link with the store in the route.
• the user clicks on an external link with the store in the route.

FOR FURTHER DISCUSSION: Deep linking to filtered experiences

The User Page Store Tab should show the following information:

• the listings within the store, with optional sorting and filters applied. Each listing should be a Listing Card.
• the total number of listings for the selected criteria (filters).

The elements below are interactive:

The search input

• the search input allows the user to enter a search term, which filters the list by that term.
• search will use title, description.
• the grid/list toggle button will switch the layout of the Listing Cards from a grid to a list of horizontal rows.
• the wide view only applies when the listings are in grid view.
• it would be ideal if the last setting for the grid width is saved and applied when the user looks at other User Pages.
• the width toggle button will switch the area that displays the Listing Cards from 950px to 100% of the available width of the window minus the left side controls (shipping, category, etc.) and the chat sidebar.
• the sort by drop down will change the order of the listings when it is selected. The available options are [Price low to high, Price high to low, Name (title) A-Z, Name Z-A, Rating].

The Shipping section

• has a list of all countries.
• the Shipping section has a checkbox next to the address select list and next to the Free Shipping option. If the checkbox next to the address select list is not selected, the free shipping option should be disabled.
• if an address is selected and the checkbox next to the address select list is checked, the listings should be filtered by listings that can be shipped to the country of that address.
• if an address is selected and the checkbox next to the address select list is checked and the free shipping option is checked, the listings should be filtered by listings that have a free shipping option for the country of that address.

The Type Section

• this section has set of type check boxed options (Physical, Digital, Service).
• only the types that exist in the listings should be shown.
• all types are selected by default (All option).
• if only one type is available this section is grayed out/disabled.
• if the physical type is unchecked, the Shipping section is grayed out/disabled.

The Category section

• is a set of radio buttons that shows a list of all categories within the store.
• the first option is always All.
• selecting a category filters the listings by that category.
• if more than 6 categories exist, the categories beyond 6 are hidden.
• if more than 6 categories exist, a "more" link is shown, with the number of hidden categories.
• clicking the more link expands the Category section to show the rest of the categories.
• the section can expand up to twice it's height, after that it should get a scroll bar.
• under the current design, there is no limit to the number of categories.

The Rating section

• is a list of radio buttons that have ratings from 0 and up to 5."
• zero is the default.
• selecting one of the options filters the list for listings with that rating or more.

If the user is also the page owner, the following functionality is added:

The Status section

• is a set of options that can be turned on and off.
• the options include:
  • all (default)
  • published
  • draft
  • out of stock
• a "private" option may be added (to be determined)

We want to not only attract high quality moderators to OpenBazaar but also incentivize them to invest in their offering and take their moderator duties seriously on the platform. One way of being able to generate more revenue would be to allow them to charge upfront fixed fees on every transaction, not just the transactions that result in disputes. This would require an alternative 2-of-3 multisig transaction where a fee is sent directly to the moderator in advance of any dispute. Some may want to charge both an upfront fee and an additional fee in the event of dispute.

It's possible to enter too long/large values in the shipping section, the inputs should have max attributes to prevent the user from entering an invalid value and not knowing until the error message is shown.

The Connection Modal is an interface element that allows the user to choose a server to connect to and edit or create new connections. It appears when the current connection is lost, and when the user wants to change the connection.

Functional Requirements

• The current design calls for the connection management functionality to be in a modal.
• The modal should use the external scroll pane layout, with the height of the modal growing indefinitely with the number of connections, and the entire overlay area scrolling up and down if that height is greater than the app window.
• The tab states of the Connection Modal are not added to the browser history.
• If an error occurs with a configuration, it should be shown in the Connection Modal.
• The error should show a translatable string with details about the error based on information from the server that was contacted or the call attempt.
  • There should be an error message for when the server is not reachable.
  • There should be an error message for when the server rejects the login and returns an error.
• The error should have a dismiss button that will remove/hide that error.
• The modal has 3 parts, a navigation menu, a content area, and a close button.

Navigation Menu

• When a link is clicked, it switches visually to an active state.
• A "Configurations" link that will activate the Configurations state in the Content Area.
• If there are no saved configurations, the Configurations link should be disabled.
• A "New Configuration" link that will activate the Edit Configuration state in the Content Area for a new configuration with no data.

Content Area

The content area has 2 states, Configurations and New Configuration/Edit Configuration.

• If no configurations are currently saved, the default state should be New Configuration.
• If all current configurations are deleted, the state should switch to New Configuration.
• If there are saved configurations, the default state is Configurations.

Configurations
The Configurations state shows a list of currently saved configurations.

• The title of the Configurations state is "Server Configurations."
• There should be a "New" button. Clicking it will change the state to Edit Configuration for a new configuration.

Each configuration:

• Appears in a list of configurations.
• Shows its saved name.
• Shows its saved IP address.
• Shows one of the following:
  • A "Connecting" message if a connection has been attempted and is not complete. It may have other visual indicators it is connecting, based on the design.
  • A "Connected" message if the connection is active. It may have other visual indicators it is connected, based on the design.
  • The following buttons:
    • A delete button. Clicking it will show a confirmation dialog, with a cancel and a confirm button.
      • Clicking the cancel button will hide/remove the confirmation dialog.
      • Clicking the confirm button will delete the configuration.
    • An edit button. Clicking it will activate the Edit Configuration state with the data for that configuration.
    • A connect button. Clicking it will end the current connection and attempt to connect to the server in that connection's saved data.
• If the configuration was attempted and failed, it should be visually marked as having failed.
• The Default Configuration should only be shown if the client is installed from a bundled client/server installation file. It cannot be edited or deleted.

Edit Configurations
The Edit Configurations state is used for creating new configurations and editing/viewing the details of existing configurations,

• It should have the following fields:
  • Name
  • Server IP
  • Username
  • Password
  • SSL (On/Off)
• Show saved data in the above fields if this is a saved configuration that is being edited.
• There should be a cancel button. Clicking it will return to the Configurations state.
• If there are no saved configurations, the cancel button should be disabled.
• There should be a save button. Clicking it will save the configuration, change the state of the Configuration Modal to Configurations, and try to connect using the saved configuration.
• When the save button is pressed, the fields should be validated. If any are invalid error messages should be shown and the configuration should not be saved.

Close Button

Clicking the close button will close the modal.

Data

• The configurations are saved in local storage.
• One configuration is flagged as the current configuration.
• When the server is contacted with the login information from a configuration, it should return one of the following:
  • a message confirming the login
  • a message with an error code
    • a general error code
    • a wrong login/password error code
    • a too many attempts error code
    • others?

Open Questions

• We need to investigate whether logging into a remote node requires a locally installed certificate.

User cards in the Following tabs that are not reachable just look broken. This is probably just a placeholder but wanted to put it here.

When the client starts a local server (this should mean the node server and client were installed together through an installer file), the first time the node server runs it will need a password for the database encryption.

If the user chooses not to store the password, they will also need to enter it every time the node server starts.

This will not be necessary for remote node servers, or any node server that is started with the command line. When node server is started through the command line, the password will be handled through the command line at that time.

Functional Requirements

• When the client starts, if the client is connecting to the bundled local server and if no encryption password is saved in the client, an interface should be presented to enter an encryption password.
• The encryption password interface should be the same if it is a new password or an existing password (the client does not have data on whether this is the first time the server is running).
• The interface for the encryption password should include an option to save the password, and automatically send it any time that server is started.
  • Since the client does not know if the server is starting for the first time, the option to save the password would always be available, even if this password has been entered previously.
• A warning should be included that saving the password is not the most secure option.
• If the option to save the encryption password is activated, the encryption password should be saved by the client and automatically send with the startup command any time the bundled local server is started.
• The user should be required to back up their password (it could be exported as a text file).
• The user should be informed that if they lose this password, they will lose all transactions and never be able to recover them. This should be very strongly emphasized.
• When the password is sent with the startup command, if it fails an error should be shown.
• If the startup command fails, the user should be able to submit a corrected password, or connect to a different server (this may mean the password interface should be part of the connection modal, or there is a way to open the connection modal from the encryption password interface).

Data

• When the command to start the server is sentif the startup fails an error code needs to be returned.
• The command to start the server should accept a parameter for an encryption password.
• If no encryption password exists, the server should accept a parameter for a new encryption password.
• When the command to start the server is sent with a new password, an error code needs to be returned if the new password cannot be set.
• When the command to start the server is sent with an existing password, an error code needs to be returned if the password is rejected.

It is a standard marketing trick to mark certain listings as sold out. As of writing, there are several vendors that use this trick, e.g.

• Hot Gadgets for You
• Tom Woods Jewelry
• Refur
• TaiwanTea

Each of those vendors use the listing title to mark the item as sold out. My suggestion is to add a flag in the listing object instead so that these can be machine readable (for better searching, filtering and display).

Brief Description: Clicking a link on a store profile breaks the client

Operating System (OS and version): Ubuntu 16.04

Reproducible (Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce): Always

Steps to reproduce:

1. Add a website link in profile and save.
2. Click the link when viewing profile.

Observed Behavior: Client goes white and is non responsive. No link is opened.

Expected Behavior: Link opens in external browser.

@morebrownies another border issue

and here:

both message and follow have the issue

I'm getting the above error in the chrome console on the lastest git pull. Electrum window looks like this:

As a general comment, the OB1.0 client has been misleading with silently ignored errors. For example, if there was an error loading listings from a store, the client would say "No listings". But there is a huge semantic difference between "No listings" and "Cannot load listings".

Exposing errors to users achieves two valuable things:

• It is good communication with users
• It makes issues/bugs bubble up faster, and easier to report

@jjeffryes I'm having a difficult time tracking this one down. It appears both instances have the same classes applied, but they render differently.

The instance on the listingCard is incorrect. It seems to have some extra vertical padding.

Several OpenBazaar vendors I have talked to mentioned they had problems with buyers paying most of the quoted amount, but missing just a bit to complete the transaction. This could happen if:

• The buyer's wallet subtracts the mining fee from the sending amount
• The buyer's wallet rounds down the amount paid
• The buyer uses an exchange, which may deduct a fee from the withdrawn amount

A solution for this problem is to allow for an optional "Mispayment buffer" like what Coinbase does:

Mispayments created unsatisfying customer experiences and a lot of work for everyone involved. We’ve built a way to allow merchants, through our v2 API, to create simple mispayment buffers. Mispayment buffers are percentages that can be applied to either side of the quoted order price, declaring a customized, merchant-specific range of acceptable payment amounts.

For example, let’s consider an Order for 10 BTC with a 1 % underpayment buffer. A customer who accidentally pays 9.9 BTC will successfully complete the order, while someone who pays 9.8 BTC will not. This gives merchants more control, allowing them to determine what is best for their business.

This will prevent accidental clicks that result in a lot of lost work

@morebrownies Could you also style the Deleting and Deleted state of the listing card? You could see them by applying .listingDeleting or .listingDeleted to the .listingCard element.

The styles were very much placeholder styles before, but now, with the removal of the overlay panel, they are even worse:

before:

now:

Anyhow, they're important for a few reasons:

a.) The delete is an async process and can complete at any time - the user may be happily scrolling further down the list when the delete completes, so we don't want to just remove the item having the page jump abruptly.
b.) Removing a listing may affect filters, e.g. a category may need to be removed from the cat filter. Having this update on the fly is a bit of a can of worms to make the experience smooth, so we've decide to take the approach of popping in a message urging the user to refresh:

c.) The delete could be initiated elsewhere, namely the listing detail modal. If it takes a bit, the user could close the modal landing back on the store. We would want a "deleting" state so the user understands the listing is in the process of being deleted.

Wiki Page: https://github.com/OpenBazaar/openbazaar-desktop/wiki/Listing-Card

The Listing Card displays basic information about a listing. It should have the following data:

• the default image of the listing (Small, Medium on retina devices)
• the title of the listing.
• the price of the listing
• the average rating of the listing and the number of total reviews
• if it can ship to one of the user's addresses
• if the Card is a paid placement (ad)
• if the Card is NSFW, and the user has "don't show NSFW" set, the Card should be blurred or not shown (not yet determined)

When shown in the User Page Store tab, the Listing Card should also show:

• whether it has free shipping
• whether it is pinned
• whether it is hidden

Outside the User Page Store tab, the Listing Card should also show:

• the avatar of the seller
• the country the listing ships from, if physical
• the country the listing applies to, if service

Interactive Elements

• The title is clickable, clicking on it will open the Listing Detail modal.
• hovering over the country it ships from should show the name of the country (probably in a tooltip, not determined yet)

A lot of the early OpenBazaar adopters are Bitcoiners which are active on Reddit. I thing complementing Twitter and Facebook with Reddit would enrich the vendor profiles.

At Duo Search we're trying to filter listings by language. (E.g. an English might not want to see listings in German, French or Spanish.)

It would be very useful if the vendor specified the language used for his listing, so that filtering by language can be done automatically.

Below are examples of how the category free text field is been used by current online vendors:

• Yard Sale - Electronics
• Corn, Pumpkin, Melon etc.
• 6. Tools/Misc.
• Cedar oils / essential / resin
• Hobby & Sports
• Coins & Paper Money :: Bullion :: Silver :: Bars & Rounds
• Shoe Care & Accessories › Shoelaces

As you can see, vendors have been creative with separator fragments (using -, ,, /, ;, &, ::, ›) to make a hierarchy of subcategories. It would be helpful if the client front-end (and backend, cc @cpacia) could have better support for a path of sub-categories instead of a single flat monolithic category field.

Bring in a micro-font that will give us the Bitcoin symbol, a la:
http://www.righto.com/2015/02/how-to-display-bitcoin-symbol-using_14.html

In the current OB 1.0 setup, a node can simultaneously be a vendor and a moderator. In practice, nodes that are both a vendor and a moderator are either:

• A great vendor, but a 'below-average' moderator
• A great moderator, but an amateur vendor

It is so easy for a vendor to say "sure, I'll be a moderator, my fee is X%". They will usually neglect their moderator duties, such as having a moderator policy, advertising its moderator services, deal with disputes promptly, stay online 24/7, etc. It is also confusing for buyers to see the vendor information and moderator information mashed up into a single page.

Take a great store, Yabisi Kakaw. It is also a moderator node, but neither the Description nor the About section has any mention of it, or the moderator policy. Indeed, such moderator information would distract prospective buyers. Yabisi Kakaw is an example of an "accidental moderator".

I also feel that the design of moderator nodes has to be tailored to moderators. Take our most professional moderator, BazaarGuard. It has hijacked the "About" section to stuff its moderator Terms and Conditions. Notice also that BazaarGuard has no listings, as that would be confusing.

If you click into any Select2 field inside the Settings modal, and then scroll, all the select2 dropdowns, the shipping tiles, and the photos stay fixed in the modal, while the other content scrolls under them.

Note: we are planning to refactor this modal to match to the new full-page scrolling design, doing that may fix this issue.

A radio-style control to select a bitcoin display unit should be added to the Settings/General tab.

Functional Requirements

• the options are BTC, mBTC, μBTC and satoshi.
• the default is BTC.
• when the option is changed, any price data should be refreshed to be shown in that format (make sure cached renders, if any, don't show the old format).
• the option chosen should be shown in the format appropriate to the current language.

Data

• the option chosen should be saved in local storage.

See OpenBazaar/OpenBazaar-Client#1823 for an example of this functionality.

The current medium text editor used in the settings and edit listings views isn't ideal. It should be replaced by a WYSIWYG editor with the following criteria:

• is WYSIWYG, either as you type or with a preview button.
• adds clean and minimal HTML to the text.
• can be applied to a textarea element, and keeps the content of that textarea element in sync with the HTML it generates, so saving the content requires no or very few extra steps.
• is open source, with an MIT or compatible license.
• can restrict the allowed tags (see list below) to match the tags allowed by the server.

Allowed Tags:

• h2
• h3
• h4
• h5
• h6
• p
• a - can have the href, title, and alt attributes, http, https, ftp, mailto, and ob2 schemes
• u
• ul
• ol
• nl
• li
• b
• i
• strong
• em
• strike
• hr
• br
• img - can have the src and style attributes, is assumed to be an external image
• blockquote
• span

The following text editors are suggested:

• Trumbowyg
• Quill

The About Modal is a modal that should be shown when

• the About link in the page navigation list is clicked.
• it is programmatically opened (we don't have a use case where this would be triggered other than the About link currently, but it should still work).

Currently, there is no plan to have functionality to open the About modal to a specific tab.

When the About Modal is open, it does not change the address shown in the address bar. Like most modals, the About Modal is not recorded in history.

The About Modal should show the following elements:

• the current value of one Bitcoin in the user's fiat currency..
  • if the user has selected BTC as their currency, the current value element is not shown.
• a tab menu with the following tabs:
  • The Story
  • Contributors
  • Donations
  • Licensing
• clicking each tab will show that tab section, and put an active indicator on the tab element.
• The headline of the currently active tab.
• The version number of the client and server, in the format ("client X.X, server X.X"). The client version number can be retrieved from package.json. The server version should be in the settings data (an issue has been posted for this).
• A "Check for Update" button. This will activate the update code, and update the app if an update is available (stub this in for now, the functionality is not yet available).
• The logo of OpenBazaar, along with the text "OpenBazaar" and some icons. This is visual only, and has no functionality.
• A close button. This will close the modal. The Escape key should also close the modal (these are both built-in functions of the base modal view).

The tabs have the following elements/functionality:

The Story

• The headline, "The Story of OpenBazaar".
• The main text in the modal (content TBD). This will be static formatted HTML text. (check with Jenn for this text)

Contributors

• The headline, "Contributors".
• The main text area in the modal will have some text, and a list of the contributors to OpenBazaar.
• TODO later: when we implement an endpoint on openbazaar.org with dynamic contributor data, this section can be updated to pull from that endpoint instead.

Donations

• The headline, "Donations".
• A QR code for the address to send donations to the OpenBazaar project. This can be supplied by Sam.
• The same address in plain text.
• Clicking on the address will add it to the user's clipboard. If the user clicks on the address and it is added to their clipboard, a message should be shown, similar to when the guid on the about tab of the user page is clicked (the same styles can be used).
• A "Copy Address" button. Clicking on it will add the BitCoin address to the user's clipboard.
• A "Open in Wallet" button. Clicking on it will open the transaction in the app's internal wallet. (stub this in if the internal wallet hasn't been built. As of 12/12/16, work has not yet begun on the internal wallet).
• A static text area is at the bottom.

Licensing

• The headline, "Licensing".
• The main text in the modal includes the MIT license, and a list of the libraries being used.
• A link to our github repo.
• A list of the major libraries we use (look at package.json for a basis).

The existing settings modal should have an advanced tab with settings that are technical and/or less frequently used.

Functional Requirements

The following settings should be available for the user:
Appearance

• Radio-style buttons to select the window controls style (Mac/Windows).*
• Radio-style buttons to turn advanced visual effects on or off.*
• Transactions
• Radio-style buttons to select whether additional data is saved to the wallet for each purchase.*
• Radio-style buttons to select a low, medium, or high default fee.*

Server

• Text displaying the current firewall type.
• A button to open the connection management modal.
• A button to show a list of the connected peers. The list should show each GUID, clicking on one should navigate to that user's user page.
• A button to turn off the server.
• If the server is the local default server installed with the bundled app, a button to turn on the server.

SMTP Integration

• Radio-style button to turn SMTP notifications on or off.
• Text input for SMTP server address.**
• Text input for SMTP user name.
• Text input for SMTP password.
• Text input for SMTP email address. **
• Text input for SMTP recipient email address.**
• If the SMTP notifications are turned on, all the other SMTP fields must be filled out or an error should be thrown when the settings are saved.
• A button to test the SMTP settings. It will open a connection to the SMTP server using the user name and password in the inputs, and show a success/fail message.

• these settings are saved in local storage.
  ** these settings should be validated to make sure they have the right format.

Data

• the current firewall type and SMTP settings should be retrieved from the settings API.
• the SMTP settings should be saved to the settings API.

I just noticed that the toggle for list and grid view is done globally. It might make more sense to make this local to the store front. I know that's horribly a pain in the ass, but for stores that have digital music as compared to physical goods it might make sense.

Perhaps we should make the stores choose this setting @morebrownies

What about having a boolean flag (similar to NSFW) that indicates whether or not the price for the listing is negotiable? I've personally lived in Shanghai, China for 4 years and back then buying stuff from the local markets without negotiating would have been weird/rude.

Some services require more advanced pricing, like price in BTC per minutes, hours (language classes) or words, characters (translation).

OpenBazaar should have special price units in order to facilitate price comparison. This way third-party search engines could better categorize services, for example "English teachers starting at 0.1 BTC/45 min" or "Translators from English to Spanish: starting at 0.001 BTC/character".

In the edit listing shipping section if you enter invalid data, the error message says the data is missing, which is confusing.

The inputs should have max attributes to prevent excess text being entered.

It's also possible to enter a number so big it is converted to an exponent. It would be better to put a max on the field so the user can't enter too large of a number.

npm WARN deprecated [email protected]: ReDoS vulnerability parsing Set-Cookie https://nodesecurity.io/advisories/130
npm WARN deprecated [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

When on your store and listing data changes, a pop in message appears urging you to refresh. The message is not super visible right now and is easily missed.

It's currently set with fixed positioning. The fixed positioning is important because the user may be scrolled very far down the store when we need to show the message, so having it be fixed will allow it to be at the top of their view no matter what scroll position they're at. Hopefully, the fixed positioning can stay. All else though is probably fair game.

Wiki Page: https://github.com/OpenBazaar/openbazaar-desktop/wiki/Listing-Details

The Listing Details view is a modal. It should be created and shown when:

• the user clicks on a Listing Card's listing link in the UserPage Store tab
• the user clicks on a Listing Card's listing link in a Channel
• the user clicks on a Listing Card's listing link in Search Results
• the user enters the address of the listing in the address bar and presses the enter key
• the user clicks on an external link with the address of the listing
• the route for the listing is navigated to for any reason

The Listing Detail modal should show the following information:

• the listing title
• the listing price in the user's chosen currency
• the listing type (physical, digital, service)
• the listing condition
• the item description
• the default image for the listing (Medium, Large for retina screens)
• the other images, if any, for the listing (shown at reduced size, but loaded at Medium/Large size)
• the attachments, if the listing is digital
• shipping information
• the terms and condition
• the return policy
• the average review rating
• the total number of reviews
• whether the listing has free shipping (if physical)
• the reviews
• the tags

The following elements are interactive:

• clicking the Buy Now button will start the purchase flow.
• if the listing has variants, they will be shown as select lists, with the default for each variant selected.
• if variants are out of stock, they are shown, but are grayed out and can not be selected
• if clicked on, the small images for the listing will be shown at a larger size (still being determined)
• the large image can be zoomed (still being determined)
• the Load More button will load additional reviews when clicked
• the close button closes the modal, per the standard modal behavior

If the user is the owner of the listing:

• an edit button is shown. Clicking on it opens the edit modal for this listing.

One of the observed trends from the Duo Search data is that free-text fields lead to "messy" situations, despite the bulk of the cases being "organised". Return policy is a good example, presented below.

I've collected all the different return policies that Duo Search has scraped since the beginning. It's available here for your perusal. There are 1813 distinct return policies, but when you look into them there are literally hundreds of duplicates for "No return" (small sample shown below):

    "No Returns.",
    "no refunds.",
    "no returns.",
    "All sales final.",
    "No returns.",
    "There is no way back!",
    "There is no way back...!",
    "No Returns on digital items.",
    "Returns are a no-go.",
    "No returns. No tradeback. Nothing.",
    "no refunds, will resend once if not recieved",
    "no returns, if u dont recieve will resend once",
    "no returns, if you don't recieve will resend once.",
    "no returns, if you don't recieve, will resend once.",
    "No Returns",
    "No returns",
    "no refunds",
    "No returms",
    "No return",
    "No refunds on digital items",
    "No refund",
    "No warranty and no returns.",
    "No returns or refunds",
    "Returns accpeted.",
    "No returns on food items.",
    "No return policy",
    "No Refund",
    "NA",
    "N/A",
    "Non Refundable",
    "No Return",

In an effort to make free text fields more consistent across OpenBazaar stores (and more machine readable) having pre-set options for the return policy would help. My suggestion would be to a have few preset options, plus a "Custom" field for those that require free text. For example:

• "No returns"
• "Full refund available"
• "Full refund available, minus shipping costs"
• "Custom..."

This hybrid strategy could work for many fields, including condition, weight, refundPolicy and category.

I find it really hard to figure out where to grab the window when I want to drag it because there's no border on the address bar.

On startup, use electron.screen.getPrimaryDisplay().scaleFactor to adjust the scaling for Linux.

Something like the below should work:

if (platform === "linux") {
var scaleFactor = require('electron').screen.getPrimaryDisplay().scaleFactor || 1;
$("body").css("zoom", 1 / scaleFactor);
}

Pressing ESC is a common way to close a drop down. However, since our modals close on an ESC press, then pressing ESC to close an open drop down also closes the modal.

Since we're using select2 for all drop downs, select2 gives us the proper state classes to detect an open drop down and we can then not close the modal in this case.

Brief Description: Can't install 2.0 on a PC

Operating System (OS and version): Windows 7
OpenBazaar version (shown on About OpenBazaar page in menu):
Hardware: Lenovo Y570

Reproducible (Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce): Always

Steps to reproduce:

1. Open directory in CMD the target directory.
2. Run "git clone [email protected]:OpenBazaar/openbazaar-desktop.git"
3. Stay with your frustration to get an answer as to why.

Observed Behavior:fatal: Could not read from the remote repository.

Expected Behavior:???

Additional info (links, images, etc go here):

A common issue for vendors in OB1.0 is that their store seems online to them (they can see their storefront) but actually they are not visible to the outside world.

Similar to other P2P software (e.g. BitTorrent clients, or Bitcoin Core), it would be useful to show the number of connected peers, detailing the number of incoming and outgoing connections.

This would help vendors know when their store is not visible to the outside world, or when their store is being flaky. It may also be "exciting" for store owners to see people connect to their node.

(This was briefly discussed in the partners call.) There are several use cases for allowing vendors to list listings that do not cost any Bitcoin. These include:

• Free samples
• Freecycling
• Super low barrier-to-entry testing
• (possibly) Barter

Free listings, not having a corresponding Bitcoin payment, do not need a moderator to moderate a Bitcoin transaction. Free listings would follow the same purchase flow as paid listings, with buyer orders being immediately 'funded'.

The buyer and seller would still be able to make use of OpenBazaar infrastructure around transactions, including ratings, chat, transaction history, channels, etc.

As of writing for the 270 online stores, 264 have exactly one "combination" of moderators across their listings and 6 have exactly two combinations of moderators. (Since different listings can have a different set of corresponding moderators, a given store can many have several moderator combinations.)

The empirical data suggests that stores do not make much use of the flexibility in picking a different set of moderators across listings. I suggest removing that flexibility altogether. This would allow for a store to have a well-defined set of moderators that could be displayed on the store page.

Clearly communicating moderator options at the store level is something we are trying to do at Duo Search, and this simplification would help.

The same thing happens within the Create listing screen. When I'm focused on the Category/Tag input, I can't scroll the body.

In OB1.0 a significant number of stores created have/had no contact information. This is problematic because:

• A store with no contact information (at least one of email, Twitter, Facebook, phone, etc.) is not conducive to ecommerce
• When a store with no contact information goes offline, we can't reach out and provide help (e.g. the 30 minutes offline automatic email from Duo Search)

I would suggest that the frontend client warns sellers with no contact information somehow.

npm install produces a few warnings reproduced below. (I'm running node v6.3.1.)

Justins-MacBook-Air:openbazaar-desktop justin$ npm install
npm WARN deprecated [email protected]: ReDoS vulnerability parsing Set-Cookie https://nodesecurity.io/advisories/130
npm WARN deprecated [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN prefer global [email protected] should be installed with -g

At Duo Search we have had several vendors (and buyers) wanting "category links" that link to a specific category. For example, https://duosear.ch/@vintagefashion/Belts would be a link to the belts available on the @vintagefashion store.

There are a couple of considerations for building category links:

1. We want to use the same link structure as the reference client. Will the OB 2.0 reference client have such category links?
2. In OB 1.0 there are "special" vendor links, e.g. @vintagefasion/store and @vintagefasion/about. If this will also be the case in OB 2.0, this means that the simplest implementation @[guid]/[category] does not work if the category is store or about.

cc @jjeffryes, @morebrownies, @hoffmabc