Comments on altcoins.md

[JustinDrake]

each additional wallet will consume substantial resources

I think "substantial" is a gross overstatement. My mobile phone supports several SPV wallets. The desktop reference client (which vendors would use) could easily support tens of SPV wallets. Also vendors are free to choose their currencies, opting in or out as they see fit.

it is possible to run more than one openbazaar-go instance on your machine

This hack is not practical. The reason is that it means duplicating listings. The duplicate listings would have different hashes (because the Ricardian contract would have slightly different currency parameters) and so ratings would be scattered across duplicate listings when they should be unified. Duplicate listings have other issues related to search and discovery. I urge the openbazaar-go team to consider this carefully. It's not that hard to design a protocol flexible enough to support multiple currencies from the get go.

[hoffmabc]

Oh so like redesign the whole thing on Ethereum?

[cpacia]

Who's going to write the SPV wallets for all those altcoins? At this point in time the only other one with any libraries to do it is ethereum.

[JustinDrake]

Who's going to write the SPV wallets for all those altcoins?

I guess the respective altcoin dev teams. See for example the Zcash team who have a recent PoC zcash/zcash#1113 (comment)

redesign the whole thing

I think my point is the exact opposite. That is, with protocol flexibility devs can embrace altcoins without redesigns.

on Ethereum

If the Duo team does end up embracing Ethereum (something which the OpenBazaar community seems to strongly welcome; see screenshot below with 32 points and 97% upvotes) we will be trying to remain compatible with the protocol as defined by openbazaar-go. This issue is a good faith attempt to push for that direction, alongside several other issues I've filled and discussions I've had with Chris. 👍

[hoffmabc]

It's not that hard to design a protocol flexible enough to support multiple currencies from the get go.

I was responding to designing from the get go. I interpreted that as our protocol was not flexible enough and that it needed to redesigned. Ideally I'd love to support multiple currencies if possible as the payment rail shouldn't assume that any crypto currency remains top dog forever.

One thing that does worry me though (and is something I've always espoused) is that it will be a massive increase in scope to support these other platforms. If we can find a good way for others to do the support to integrate then I'm all for it.

So far there is very small amount of contributions being made outside of OB1 to this platform, which is fine, but we continue to focus on the highest value and most relevant work to our group in order to get things done.

You guys have done a great job of identifying some interesting new extensions of the OpenBazaar work, but we will need your and others help to build this stuff. We also have OB1 projects that we develop and cannot focus on all of this with our current staff.

(something which the OpenBazaar community seems to strongly welcome; see screenshot below with 32 points and 97% upvotes)

Of course the community wants it because they don't have to build it and who doesn't want more ice cream if offered? This is a poor gauge of what will make the project successful. At this point it is obvious that Ethereum is not a platform used for commerce that is comparable to Bitcoin's traffic, which is meager already to begin with.

We need to put our heads together and figure out a strong way to make everyone happy, but I certainly don't think just cramming other alt coins onto the platform in a rushed way will make anyone happy.

[JustinDrake]

I was responding to designing from the get go. I interpreted that as our protocol was not flexible enough and that it needed to redesigned.

By "get go" I mean the full public launch of OpenBazaar 2.0. I'm alluding to the difficulty of updating the protocol post-launch. (I slightly expand in the second point here.) The protocol is not flexible in really obvious and easy to fix ways. See for example issues such as this one, from October 2016. It's a trivial and obvious change which Tyler agrees is worthwhile and "almost no change". Despite that there's resistance. (E.g. my latest comment was ignored and this 6-month old issue is still not addressed or included in one of the 7 milestones.) It's not rocket science, but requires good will from the ultimate decisions makers of openbazaar-go.

So far there is very small amount of contributions being made outside of OB1 to this platform

Really? Duo has made so many contributions to the OB platform that I'm somewhat baffled by this comment.

[hoffmabc]

If #188 is not even surfaced I don't understand why this would be a hard to implement change later on. Am I missing something?

Really? Duo has made so many contributions to the OB platform that I'm somewhat baffled by this comment.

You guys are the only ones pretty much outside of our team contributing and on the go repo alone you all have submitted 50 something commits out of at least 1,000. I never saw a PR for #188.

You also have almost 80 issues filed and I don't see any code or PRs against those requests. I'm not trying to make you feel bad about it, but if you would like us to consider some of these things more realistically then code it up and we'll review the PR.

You don't think that's reasonable?

[hoffmabc]

We do appreciate your help, but it's kind of frustrating that you think we're stonewalling all the things you want to do.

[JustinDrake]

I don't understand why this would be a hard to implement change later on. Am I missing something?

You may be missing that this is a non-backwards compatible protobuf change, i.e. a "hard-fork" protocol change. AcceptedCurrency goes from being a string to being an array.

I don't see any code or PRs against those requests

Have you not seen my PR fixing #381. (Note that you personally requested this PR.) The change has broad support (see here, with support from Tyler, Dr Washo and myself) and a PR. Yet, despite all that, the ultimate decision makers of openbazaar-go have had this PR hanging for two months, and again providing no follow-up to my last comment.

it's kind of frustrating that you think we're stonewalling all the things you want to do

How many of the openbazaar issues in this list have been addressed or at least put in milestones? Virtually none. These are the facts. Now compare that to the only non-OpenBazaar issue, which is the go-libp2p issue listed at the very end. The attitude there is supportive. See this acknowledgment stating "I'll try and get this done ASAP for you guys.".

[cpacia]

You may be missing that this is a non-backwards compatible protobuf change, i.e. a "hard-fork" protocol change.

It's not a hark fork. It can be a change that is only known to upgraded nodes with the old field marked as deprecated.

[hoffmabc]

Ok so I didn't want to get in the way of the debate over PR #381 because it sounds like there's some disagreement on how useful the refactor is. We should have resolved that by now so you're right to be upset about that one. @cpacia please either review and move forward on this or close it if we're not going to do it.

As far as your very long list of requests, you have to realize these are going to go into our backlog and we'll try to address them as we can. If you think they're higher priority then we're responding relatively then we'll just have to figure out a way to expedite stuff.

The ipfs team is extremely accommodating, but one issue vs. 80 is a lot different. I'm sure they'd have difficulty responding to all those requests just as we are. Let's chat about this on Monday.

[cpacia]

Not making it into v2