I only skipped through it but clearly the writer has very limited experience on many subjects around P2P... If that is the quality of developers Sys is hiring good luck.
EDIT : Much of the info re: Shadow and its ShadowMarket is incorrect.
EDIT2: Blockchain is NOT the always the answer!
From looking at github of sdc what I saw was cloning and renaming of cinnicoin and blackcoin and then a few anon features on top with a big EM commit. Judging by the quality of commits I put the project in the early prototype stage perhaps skipping design phase. Since there is no code to look at for markets and very little information on how it works other than it uses bitmessage I made the valid assumption that it is openbazaar clone with an attempt at anon and an html5 template as a frontend.
Perhaps instead of one word answers you can elaborate on more information about how it is more than just bitmessage since that is the base for all of your communications in sdc. At this point sdc market is irrelavent due to no code to fallback on perhaps you should put more information up on how it will work, and perhaps I should remove it from my comparison list because at this point it's not really a competitor in the marketplace sphere.
I'm sorry you disn't try to read the entire post.. Biggest nuggets were near end. Anyways your comment about blockchain ddos is invalid if you understand how openbazaar works and the fact that some features are not trustless... Because in the p2p marketplace design you will have to delegate to a non trustless design to be able to have offers always up for example you will have the ddos attack more of a possibility than a trustless system that allows all these features on the blockchain without sacrificing identity of user.
Edit: Thinking about p2p implementation some more, since the P2P design doesn't store offers anywhere but in memory of each and every client which is why there is say a 2-4 day limit of transactions before they are removed forever... I see a horrible scaling problem in bandwidth needed to be able to relay transactions simply just to "keep-alive" current offers. Say there are a million offers currently listed across the globe on a p2p marketplace, every client will need to relay a message saying that all 1 million still exist every x number of days, as the number increases more and more bandwidth is needed to relay the transaction. It becomes an exponential problem to what is a linear demand for bandwidth in the blockchain. In the blockchain approach once it's sent once, its stored in the DB so doesn't have to send again. The people claiming bloat is an issue is simply because of the bandwidth needed to sync up to the network, however this is minuscule compared to the demand of bandwidth needed to maintain a p2p marketplace by relaying keep-alive messages for every offer still online every x days. Bitbay dev has a plan to counter this by creating subset markets on different ports so people can connect to the one they want to look at, and each subset network is responsible for relaying messages within itself. I don't know of the implications of that approach yet without studying some code or implementation.
So in reality bandwidth is a BIGGER issue in p2p than in blockchain. The fact that SDC dev claims that I don't understand that the blockchain approach IS P2P shows his lack of understanding of the underlying technologies of his own project. Expected from a copy and paste clone.
I've actually updated the
blog to talk about the bandwidth requirement differences in the section "Bandwidth considerations of P2P vs blockchain marketplace"
I also took out the darksend stuff, probably was wrong information that someone had about shadow coins anon tx.. but I rewrote that part as: " ShadowCoin’s marketplace plans to offer anonymous transactions via encrypted messaging and stealth addressing, I would say it is the leader in anon innovation of all competitors at this point."