Regarding the NEP177/171, I see your point that this update could be more than just metadata. Our indexer uses the full triplet, and that saved us from some spam engines that would just mint garbage with wrong triplets. All in all I think this is the least point of debate.
Regarding event names, nft_update
might be more consistent, but itâs better to have clear distinction between contract-level update and token-level update. Given that the nft_metadata
method returns contract metadata, I interpret the nft_
prefix to tell me that this method/event is from an NFT contract, and not necessarily related to a NF Token. So an nft_update
event for me still has the question attached as to what is being updated, as it is way less obvious than with nft_{mint,transfer,burn}
. The consistency comment was more update the update contract event. I find the contract_update_metadata
quite confusing, especially if youâre telling me that youâre not really paying attention to the standard part of the event triplet. How do you know that the event was emitted from an NFT contract and not some FT contract or DAO or anything else? So IMO the contract update should have a nft_
prefix. And from there on having a clear line between update token and update contract is logical to me. Also updating the indexer with a new event name if the data might be incompatible with the existing, pre-used format is actually a plus, since that way you can update backwards-compatible and go back in time more easily than by coding special rules for block heights when events were updated in a per-contract-level.
The 16 kB log limit is kind of a point, since I already saw people using the media field to store base64. I do not like the current pattern of the indexer having to call RPC methods, as it breaks unidirectional data flow and creates HTTP requests that increase cloud costs and load on all systems (NEAR, yours, ours). So replacing nft_token
calls with event logs would be a big improvement, but that might better be paired as an NEP that allows for increasing the log limit and then the mint event should emit metadata as well. Making metadata optional in the update event could spare us some of that, but create one path for unidirectional and another path for the current data flow. I think thatâs more an introduction of complexity than is worth for our road to have sane data flow.
All in all, no problem with NEP171/177, I think we can skip emitting metadata, even though current data flow is messy. On the event name I am still convinced that nft_update
is not really clear. I could also make my comment on the proposal for updating contract metadata. If everything else stays the same, all you need to do on your indexers is:
match (standard, version, event) {
...
(_, _, "nft_update") => handle_update(data),
(_, _, "nft_update_token") => handle_update(data),
...
}
Ofc this assumes you are ignoring standard as you said, not sure what youâre doing with version. But itâs literally one line of code. Letâs just make the standards as clear and self-communicating as possible.