I am working on this goal now.
I think including a messanger is a bad idea. Users should
trade addresses for an otr-XMPP chat, to securely talk
about illegal activities.
https://github.com/zack-bitcoin/NewsCoin
It has a built-in reputation system, and NxM addresses
for easy escrows of all types.
It uses Slasher instead of POW. Miners have an incentive
to do networking so that they can collect transaction
fees.
Topic: Decentralized marketplace discussion (Read 936 times)
Hello everyone,
We are thinking of making a decentralized P2P marketplace (p2pm). Since the coding would take quite a long time we decided to first ask you guys if the realization that we propose seems reasonable and worthwhile and if not why.
So here are the main features that we want this marketplace to have:
1. It will be decentralized in the sense that all data (messages, propositions, frozen, ratings, transactions etc) will be stored in encrypted and distributed way (like bittorent sync), but all GUI (e.g. web sites of merchants) are supposed to be up to the groups owners and may not be stored in the p2p network/be a part of the base client.
2. (this is probably the most important part of the whole system and the one that we are not 100% sure about) – Users will be able to form their own groups (networks) and become the group’s moderators. The moderators/administrators will solve any disputes that will happen in this group and they will be able to invite people to the group as well as kick them out of the groups. They could solve disputes by either taking the risks on themselves and paying the side that is not satisfied with the transaction. They can as well punish one of the sides (the buyer and the seller) and transfer the prepayment that will be frozen on both of the party’s accounts for the time that the good travels by mail. We were thinking that to protect both parties there are 2 possible systems – either construct a decentralized mechanism such that it would be best for the seller to actually sent the good and for the buyer to pay for it. Unfortunately we couldn’t find any that we would be completely satisfied with (we tried to adapt the NashX approach but for each mechanism proposed we found a way to trick the system for either the buyer or the seller). The second is to find some sort of centralization of the system and this is what we are proposing pretty much. Again, the problem of trust is the major question and we see no better way of providing it for the moment. There is probably some legal issues here that we should consider.
Another point: each user will have a rating (within each group he participates), the higher his rating is, the smaller the comission that he pays to the administrator. The buyer and the seller will rate each other after each transaction. The administrator will think what to do with users that either always give bad ratings or always receive bad ratings.
3. The system will include a messenger, so that in case the buyer didn’t get his good, he could contact first the seller and then the group administrator if this is needed.
4. Apparently there is need of some incentives to store and transfer p2pm data. Some approaches like bitstorage could be used (https://bitcointalksearch.org/topic/announce-whitepaper-for-bitstorage-a-peer-to-peer-cloud-storage-network-348868).
We are thinking of making a decentralized P2P marketplace (p2pm). Since the coding would take quite a long time we decided to first ask you guys if the realization that we propose seems reasonable and worthwhile and if not why.
So here are the main features that we want this marketplace to have:
1. It will be decentralized in the sense that all data (messages, propositions, frozen, ratings, transactions etc) will be stored in encrypted and distributed way (like bittorent sync), but all GUI (e.g. web sites of merchants) are supposed to be up to the groups owners and may not be stored in the p2p network/be a part of the base client.
2. (this is probably the most important part of the whole system and the one that we are not 100% sure about) – Users will be able to form their own groups (networks) and become the group’s moderators. The moderators/administrators will solve any disputes that will happen in this group and they will be able to invite people to the group as well as kick them out of the groups. They could solve disputes by either taking the risks on themselves and paying the side that is not satisfied with the transaction. They can as well punish one of the sides (the buyer and the seller) and transfer the prepayment that will be frozen on both of the party’s accounts for the time that the good travels by mail. We were thinking that to protect both parties there are 2 possible systems – either construct a decentralized mechanism such that it would be best for the seller to actually sent the good and for the buyer to pay for it. Unfortunately we couldn’t find any that we would be completely satisfied with (we tried to adapt the NashX approach but for each mechanism proposed we found a way to trick the system for either the buyer or the seller). The second is to find some sort of centralization of the system and this is what we are proposing pretty much. Again, the problem of trust is the major question and we see no better way of providing it for the moment. There is probably some legal issues here that we should consider.
Another point: each user will have a rating (within each group he participates), the higher his rating is, the smaller the comission that he pays to the administrator. The buyer and the seller will rate each other after each transaction. The administrator will think what to do with users that either always give bad ratings or always receive bad ratings.
3. The system will include a messenger, so that in case the buyer didn’t get his good, he could contact first the seller and then the group administrator if this is needed.
4. Apparently there is need of some incentives to store and transfer p2pm data. Some approaches like bitstorage could be used (https://bitcointalksearch.org/topic/announce-whitepaper-for-bitstorage-a-peer-to-peer-cloud-storage-network-348868).
Jump to: