feat(nft): exclude spam and phishing, refactored db#1959
Conversation
onur-ozkan
left a comment
There was a problem hiding this comment.
Great work! Some notes from first review iteration:
| let nfts: Vec<Nft> = self.get_nfts_by_token_address(chain, token_address.clone()).await?; | ||
| let locked_db = self.lock_db().await?; |
There was a problem hiding this comment.
You should lock the db before reading nfts
There was a problem hiding this comment.
UPD if we move lock_db before other db methods which access db it breaks it. well bcz another storage method tries to lock db while it already was locked.
There was a problem hiding this comment.
Oooh, I see. Hmm, that shouldn't be that way but let's not deal with this issue in this PR. You can revert it to previous state.
…ashSet, passes filter funcs, lock_db at the beginning
onur-ozkan
left a comment
There was a problem hiding this comment.
These are my last notes on this PR. Thank you for patience on fixing the previous ones.
As an extra note, if this PR doesn't need to be rushed, I would highly suggest testing and re-designing the usage of db locks if necessary. Right now as far as I understand, almost every function starts with locking, so if caller and callee locks the db, there is very high chance if being end up with deadlocks. Like it happened #1959 (comment) here.
shamardy
left a comment
There was a problem hiding this comment.
First review iteration from my side! I will review the rest of the code in the next and last review iteration!
| storage | ||
| .update_transfer_spam_by_token_address(chain, address_hex, true) | ||
| .await?; |
There was a problem hiding this comment.
This call is not needed if possible_spam was true before, also can possible_spam change from true to false? meaning that an NFT that was flagged as possible spam passes some criteria and gets reconsidered as not being a spam.
There was a problem hiding this comment.
This call is not needed if possible_spam was true before,
oh, yeah agree in refresh_possible_spam there is no need to send spam request again if possible spam is already true bcz of nft_db.common.possible_spam = moralis_meta.common.possible_spam;
also can possible_spam change from true to false
Well we dont know how moralis marks their nft spam or not spam.
But yeah it could be a situation that they changed possible_spam from true to false
But since we use separate db with spamy addresses I suggest to mark nft as spam if contact address has true in our db.
Another but :D I got your idea. lets check in refresh_possible_spam function whether the spam value for contract address has changed in our database or not. If moralis returns false and our spam api returns false for contract in refresh functionality then lets leave this as false.
There was a problem hiding this comment.
But yeah it could be a situation that they changed possible_spam from true to false
But since we use separate db with spamy addresses I suggest to mark nft as spam if contact address has true in our db.
I consider this an edge case, but NFT collections can gain traction after sometime and some of the false positive possible spam NFTs due to the criteria used to identify spams can become popular in the future. I see that we don't change true to false anywhere, we can keep it this way for now until we get real cases from users feedback.
| if let Ok(token_uri_meta) = serde_json::from_value(response_meta) { | ||
| uri_meta = token_uri_meta; | ||
| } | ||
| if let Some(url) = construct_camo_url_with_token(token_uri, url_antispam) { |
There was a problem hiding this comment.
I am interested to know how camo will be used for image_url/animation_url/etc.. , will the url be constructed from the GUI side? or will it not be used at all?
There was a problem hiding this comment.
@smk did /url/decode/{url_hex} endpoint capable to return you json object or if link returns image type content you will download picture, if request was successful of course(camo doesnt allow redirections). So yeah, GUI also should use camo to download pictures
There was a problem hiding this comment.
So yeah, GUI also should use camo to download pictures
Should we provide them the constructed camo url or will they construct it from their side? It can be an option in NftMetadataReq, if requested, we would then convert the urls after we retrieve them from database to camo format.
There was a problem hiding this comment.
Should we provide them the constructed camo url or will they construct it from their side?
GUI needs to convert image_url string to hex format and send get req to /url/decode/{url_hex}. There is no need to build the whole complex camo url, proxy does it on its side. All you need is to provide hex format. I think GUI can do it on their side.
It can be an option in
NftMetadataReq, if requested, we would then convert the urls after we retrieve them from database to camo format.
As far as I know they send get nft list req with max flag to see all nft info and then try to send req to image_url to download picture for all items. But of course we can speak about it and if they want we can add ready hex format.
|
@laruh please provide @KomodoPlatform/qa team examples of changes in this PR for docs and testing if needed. |
|
@laruh @KomodoPlatform/qa can this PR be merged or are there still some work to be done on the QA/docs side? |
Hi, I think we can merge it. Docs will be updated to match this PR, if we missed something from the current PR we also can add it. |
In this PR
exclude_spamandexclude_phishingparams were added forget_nft_listandget_nft_transfersRPCs.Db in native target was refactored. It doesnt use
details_jsonwith all rust struct fields anymore. To get nft and transfers from db, there is need to fetch all fields from the table. However update process some specific fields from became easier.If
exclude_spamis true, then all nfts or transfers wherepossible_spamistruewill be excluded from response.If
exclude_phishingis true, then all nfts or transfers wherepossible_phishingistruewill be excluded from response.Link to antispam API docs.
Second sprint iteration from commit 410330a
UriMetafrom json. It protects from phishing and solves cors problem.possible_phishing(add requests to/api/blocklist/domain/scanendpoint).contains_disallowed_urlcheck for possible spam urls during update process, so we will have already checked nfts in db, which can be excluded.Get NFT metadataresponse. If we get the error, then return Nft with empty metadata andpossible_spam:true.