-
Notifications
You must be signed in to change notification settings - Fork 45
Redesign asset listing and validation infrastructure #32
Redesign asset listing and validation infrastructure #32
Conversation
@@ -95,13 +87,17 @@ public static void setBaseCurrencyCode(String baseCurrencyCode) { | |||
public static List<CryptoCurrency> createAllSortedCryptoCurrenciesList() { | |||
final List<CryptoCurrency> result = new ArrayList<>(); | |||
|
|||
final ServiceLoader<SpecificAltCoinAddressValidator> loader = ServiceLoader.load(SpecificAltCoinAddressValidator.class); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Loader is used twice, here and in AltCoinAddressValidator. I'm not sure if it makes sense to introduce separate class like AlitCoinAddressValidators
to encapsulate this one line.
@@ -95,13 +87,17 @@ public static void setBaseCurrencyCode(String baseCurrencyCode) { | |||
public static List<CryptoCurrency> createAllSortedCryptoCurrenciesList() { | |||
final List<CryptoCurrency> result = new ArrayList<>(); | |||
|
|||
final ServiceLoader<SpecificAltCoinAddressValidator> loader = ServiceLoader.load(SpecificAltCoinAddressValidator.class); | |||
for (SpecificAltCoinAddressValidator validator : loader) { | |||
result.add(new CryptoCurrency(validator.getCurrencyCode(), validator.getCurrencyName(), validator.isAsset())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My tase tells me that validator should not hold general info about currency, but if we'd like to introduce an additional class (i.e. BchRegistrant) with altcoin description that would force users to create an additional class. What's your take on this?
import org.bitcoinj.core.Address; | ||
import org.bitcoinj.core.AddressFormatException; | ||
|
||
public class BchAddressValidator extends AbstractSpecificAltCoinAddressValidator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should use currency name (BitcoinCashAddressValidator) or a symbol, and if symbol then all letters in upper case or like it's now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use the ticker symbol, but do standard capitalization, not all caps.
import java.util.stream.Collectors; | ||
|
||
import lombok.extern.slf4j.Slf4j; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're using an old version of IDEA that doesn't respect the new codeStyles/Project.xml
file that's checked into this repository, which means you're mis-organizing imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, it respected code style from exchange. Is this one different?
|
||
import bisq.core.util.validation.InputValidator; | ||
|
||
public interface SpecificAltCoinAddressValidator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name is ugly. I'd rather have it called AltCoinAddressValidator
but it's already taken by that class that aggregates all alts.
final ServiceLoader<SpecificAltCoinAddressValidator> loader = ServiceLoader.load(SpecificAltCoinAddressValidator.class); | ||
for (SpecificAltCoinAddressValidator validator : loader) { | ||
validators.put(validator.getCurrencyCode(), validator); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A List<SpecificAltCoinAddressValidator>
should be constructor-injected here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(as opposed to doing the ServiceLoader
lookup directly within the ctor)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean that there should be something else registered with Guice that would provide a list of validators?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I just mean normal injection, i.e. classes should take their dependencies through constructors, not create them themselves. How those deps get wired up is a different matter. Guice might have a role to play there, maybe not. I'd have to look / think about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we call it AssetProviderRegistry
?
@@ -93,6 +70,10 @@ public ValidationResult validate(String input) { | |||
ValidationResult regexTestFailed = new ValidationResult(false, | |||
Res.get("validation.altcoin.wrongStructure", currencyCode)); | |||
|
|||
final SpecificAltCoinAddressValidator validator = validators.get(currencyCode); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't declare local variables final unless absolutely necessary.
@@ -0,0 +1,2 @@ | |||
bisq.core.payment.validation.altcoins.bch.BchAddressValidator | |||
bisq.core.payment.validation.altcoins.ella.EllaAddressValidator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I had in mind here for the SPI is something that would be called, e.g. a TokenListingProvider
, and implementations of that SPI would provide everything necessary to list a token, including any custom validators like this. So think self-contained, higher-level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned in Slack just after the comment above, perhaps what we want for naming is just TokenProvider
.
And actually, we may want to take this opportunity to raise the level of abstraction one degree and start referring to these things in general as "assets", as-in "crypto assets". That term has emerged pretty strongly as the most general class that includes everything from BTC itself to altcoins (e.g. ETH, LTC) to tokens, e.g. all things ERC-20 on top of ETH.
We already distinguish within Bisq between altcoins (coins with their own chain) and "tokens" (coins that ride on another chain, e.g. ERC-20). Asset is the missing generalization here.
So I could see us calling the SPI here AssetProvider
, and updating our documentation to talk about "listing an asset" on Bisq, instead of "listing a token".
So the AssetProvider
would be one-stop shopping for all your Bisq asset listing needs: it would define your asset name, asset ticker symbol, asset address validation, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use isAsset in the CryptoCurrency to distinguish between pure altcoins (own blockchain) and assets like ERC-20. So far it is only used to show an extra popup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NACK, per single comments already added. Thanks for getting this up for early review, @blabno.
Feel free to add more commits, and if you want to --amend
/ interactively rebase the commits you already have here, that's fine, please do (I'd ask you to clean them up into atomic commits prior to merging in any case).
|
||
@Override | ||
protected final void configure() { | ||
bind(AssetProviderRegistry.class).toInstance(AssetProviderRegistry.getInstance()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will require a change in bisq-desktop
to include PaymentModule or it will hit runtime exception.
8ba96b0
to
c949a24
Compare
I just rebased this against master (93baf56) and force pushed. Will follow up with a few review commits now. |
This change builds on initial work in prior commits to fundamentally redesign the way we manage assets in Bisq. Previously, assets were "listed" by adding them in several places, mainly AltCoinAddressValidator and CurrencyUtil. This led to large and growing classes that do everything and that are prone to merge conflicts any time there is more than one open pull request to list an asset. Now we have a new, top-level 'bisq.asset' package (we may want to extract this to its own repository for several reasons). Within, we have a first class concept of an 'Asset' (think "crypto asset", as in the most general term possible for all different kinds of crypto currencies, tokens, colored coins, etc.). Assets implementations are listed in the META-INF/services/bisq.asset.Asset service-provider file. Two subtypes of Asset exist: Coin and Token. 'Coin' is what we have always meant when saying "altcoin" so far: i.e. a coin that has its own blockchain. A 'Token' is an asset that does not have its own blockchain, but rides on top of another through a smart contract, e.g. ERC-20 tokens. And indeed, there is an abstract Erc20Token subtype that captures this common suitation and provides various conveniences. In this commit, several assets have been extracted, including Bitcoin, Bitcoin Cash, Ether, Instacash and Ellaism. Each represents an at least somewhat different kind of asset, and therefore provided a good basis for ensuring that the changes in this commit were sufficiently generalized to accommodate the other asset extractions that will follow in subsequent commits: - Bitcoin is a base currency for Bisq - Bitcoin Cash is a typcial Bitcoin-based altcoin - Instacash is another Bitcoin-based altcoin - Ether is a non Bitcoin-based altcoin - Ellaism is an ERC-20 token A number of changes remain to be made in the new types introduced here, including Javadoc, and this will be added prior to merging the series of commits that will make up the overall pull request. Also note that the tests in AltCoinAddressValidatorTest have been left intact for now, as a means of double-checking that everything works as expected from the application level. It should also be noted that AltCoinAddressValidator is essentially becoming a translation layer (an "anti-corruption layer" in DDD terms) where the new 'bisq.asset' world meets the old AltCoinAddressValidator / CurrencyUtil world that bisq-desktop already knows. It is intentional that this refactoring has been isolated in this way, leaving the old "contract" for AltCoinAddressValidator and CurrencyUtil intact. We can see about refactoring bisq-desktop to deal more directly with the new AssetRegistry interface in the future, but it is not necessary, and indeed not desirable to do all of that now in this PR. The idea is to redesign the underlying infrastructure now, enough to make it more manageable to deal with going forward.
Note that the existing OctocoinAddressValidator was nothing more than a copied and pasted Base58 bitcoin address validator (identical to PNCAddressValidator, incidentally, which will also be deleted when we extract PNC).
@blabno, please study the commits I've added above, and be sure to read the full comment in cab46e2. Could you follow suit with what I've started here by continuing to extract each remaining asset, one commit at a time? You can push commits up as soon as you have them and I'll review them as quickly as possible to make sure everything is on track. Of course if you have questions or concerns, please bring those up too, here or in Slack. Thanks! |
3277cfd
to
2f231d3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK.
@blabno, please have a look through the final review commits I pushed above.
Note that I'm mid-flight on updating the https://bisq.network/list-token document to reflect these changes, but I wanted to get this PR merged asap, in case, @blabno, you wanted to include this work in this month's compensation request. There is no rush to do so, by the way, and you can feel free to defer this until next month's, when the actual value of these changes has had some time to become clear. Either way is fine.
Redesign asset listing and validation infrastructure
And preserve old /list-token links by redirecting to new /list-asset. See bisq-network/bisq-core#32
@ManfredKarrer, @blabno, see my commits above to docs and website. The old https://bisq.network/list-token link is now https://bisq.network/list-asset, and the doc has been fully reworked to reflect the new structure and process (bisq-network/bisq-docs@c0e9ffc). I will now let authors of all outstanding asset listing pull requests know that they need to rework their PRs to adhere to the new instructions. |
I can do the rework for those PRs. |
Probably we should add that the sorting is case insensitive In section Write tests for your asset I would add that the test should go into the same package as the new asset. We should probably mention that there should be no additional classes. If any is required then make it an inner class of new asset. |
Yeah, it's documented in the file itself. Didn't want to duplicate that too much.
Probably a good idea.
Probably a good idea, but should also be covered by the "follow existing conventions" tip. Feel free to patch the doc to add these items if you like. Otherwise, I'd say let's see how actual PRs play out and tweak / tune the doc as necessary along the way. Thanks for the review though. |
We decided in Slack to close all the existing PRs and have authors resubmit, as a way to get early validation that the new instructions are sufficient. |
Individual asset address validation tests are now handled in dedicated unit tests. This test is now essentially an integration test, ensuring that AltCoinAddressValidator interacts correctly with the underlying AssetRegistry infrastructure. This work was intended to be part of bisq-network#32.
This appears to be dead code, see @blabno's inquiry about it at https://bisq.slack.com/archives/C1267HFD1/p1521801524000052. If this is in fact *not* dead code, i.e. it gets used to print out certain reports at release boundaries, I suggest we still kill it here, and re-write that code in such a way that it (a) uses the new bisq.asset infrastructure and (b) doesn't require duplicating ticker symbols in this class. This work was intended for inclusion in bisq-network#32.
No description provided.