Request: Please set a default expire date for items being sold

[locutus75]

To make the BM as update to date as possible, avoiding old/orphant sells from glocking the BM, I would advise to default set an expire date for sells; perhaps, as an option you could allow an override or later to extend, ofcourse let the seller pay to change this.

[sidhujag]

Expiry is controlled by the owner alias

[locutus75]

i know, but to mine opinion, the buyer should be "protected" from products which are being abanded; that way, you make a more up to date buy/selling system. In my experience, it is frustrating when you want to buy stuff, it takes a while to find a product that is still available and not being left "to rot" by sellers who are not keen on keeping track of their products (maybe they sold the product already throught other means) or users who leave the system (and expire date is far into the future). As mentioned, a system to extend the expiry date (or change at first), would also make coins available back to miners or masternode owners for instance. And it makes the user aware when they have to pay for changing the expire date also.

[sidhujag]

You would use escrow to ensure you are not paying for something and not receiving.

[locutus75]

its not a good thing that a market is full off stuff which is not available any longer. What would be a downside of using an expire date to ensure a more up to date market?

[sidhujag]

There already is an expiration date. See whitepaper.syscoin.org

[locutus75]

only for the alias, not for the items being offered.

[sidhujag]

Offers are connected to an alias

[sidhujag]

The idea is if an alias is active so is their store.. and if they dont intend to sell they set qty to 0 or during escrow the funds are refunded by arbiter because buyer doesnt get his goods

[locutus75]

That concept is totally clear to me; all I am pointing out is that there should be some buyer protection against orphaned items; this way, as I said, you guarantee a far more up to date marketplace. In my opinion, if you let this responsibility to the seller, it will eventually results in lots and lots of items which are no longer available. I really can't see the downside of not doing this (setting a expire date per item), certainly not when you could charge for extending this date. Please elaborate what the downside would be.

[sidhujag]

You know there is an expiry date for offers right? Its just controlled thru alias.. your saying have it per offer as an option instead of alias? That affects pruning quite a bit its doable but adds alot of unneeded complexity for not much benefit.

[locutus75]

yes per offer is what I am suggesting. Please ask arround, if people like a market where 80% of the products is listed as available, but cannot be sold because the sellers forgot to remove an item because it was sold on a different market (or whatever means), or any other reason. In my believe, a seller is only interested in selling the product, it does not care for if there are still items listed which are no longer available. You are making a stronger, up 2 date market, without having to worry about orphaned items. Your comment about "unneeded complexity" tells me that you don't see the urge, thats why I think you should ask arround. I believe it is key for the long term success of SYS.

[sidhujag]

you can do multiple things to get around the issue: 1) See the last time the offer was updated 2) See the last time the offer was purchased 3) See the last time there was feedback on a purchase 4) Overall rating and reputation of merchant 5) Escrow actually prevents seller from stealing money for goods he doesn't have. 6) Ask the merchant prior to purchase if good is available because the offer "looked" stagnant.

All these things in tandem get around this problem while reducing complexity in code.

[locutus75]

Let see it from a buyer perspective: when I am looking for someting, I do a search and lets say 50 results turn up; I dont want to worry about availability; if it is there, chance should be at least 50%, instead of 10% that it's available. So, anyway, lets not drag this to infinity. :-) I think you know my point by now. It's your call.

[sidhujag]

We can make it so the indexer simply prunes things that havent been bought for say 6 months or something like that... and it comes back after you update.. this way we arent complicating the codebase and the indexer is non-consensus based. That is something we can do after.

[dwasyluk]

Closing as this seems to have been discussed and can be handled in an update to the core code/indexer after 2.2 release.