We need separate Events standard [NEP]

[telezhnaya]

We have NEP-141 FT, NEP-171 NFT, NEP-245 MT.
All of them use or will use the same events logic. Let me try to collect this logic into one meta-standard, so that we can reuse it in all these and other NEPs.

[colerob1776]

Is it possible to force users to use the standard by encapsulating this structure into the log! macro in the near-sdks? So to log events, the macro could be event!(standard: &str, version: &str, event: &str, data: &str).

It seems like this standard gets overlooked (I didnt know about it when I started on NEAR in earlier this year) since it cant be enforced, but there are some major benefits as a result of the standardization. If all contracts followed this standard, more efficient indexing structures would be possible such as a bloom filter to quickly know if a given shard in a block contains an event, without having to search the logs of each shard to ensure inclusion of the given event. The current approach will become increasingly less feasible as the number of shards increase

[frol]

@austinabell What do you think about this addition to near-sdk-rs? Should we invite people to create an issue on near-sdk-rs and submit PRs as part of Hacktober Fest? 😄

[austinabell]

@austinabell What do you think about this addition to near-sdk-rs? Should we invite people to create an issue on near-sdk-rs and submit PRs as part of Hacktober Fest? 😄

I don't have an opinion. If the events format is standardized enough, that could come into the SDK. Is there an NEP or format in a spec somewhere that someone could use?

cc @itegulov @ChaoticTempest

[frol]

@austinabell Yes, it is actually a small and self-sufficient NEP: https://nomicon.io/Standards/EventsFormat

[frol]

@colerob1776 Would you like to champion the implementation for near-sdk-rs? I guess, you can go ahead and submit a PR

[coleFD]

@colerob1776 Would you like to champion the implementation for near-sdk-rs? I guess, you can go ahead and submit a PR

Yep, I can work on it. I have run across some discussions that the future goal is to include support for other serialization formats. Is it safe to only assume JSON for now?

[frol]

@coleFD Yes, it is safe to assume only JSON support, just leave room for future extensions.

[coleFD]

The screenshot is the route that I am going with this. Does this look reasonable to follow through with? My only thought is:

1. Since most of the logs that come from this will not be formally standardized but will be used across dapps in similar sectors (eg. swap events), I think the key is having fields that group similar events without having to infer grouping based on the data field. To me the event field is the only field that accomplishes this and would be the target for bloom filtering. Does it make sense to make the standard and version field optional as well or do you see applications here as well?

or it may be cleaner to privatize the logging functionality from the environment functions and just expose the Event struct with an emit() implementation. If we wanted to remove the serialization format parameter, we could have different Event types for each format EventJson, EventBorsch, etc.

[coleFD]

We can move this conversation here: near/near-sdk-rs#934

[frol]

Does it make sense to make the standard and version field optional as well or do you see applications here as well?

I see it important to have the standard be required and encouraged developers to come up with their own names there (e.g. Fayyr and a couple of other projects already adopted this strategy: https://stackoverflow.com/a/72186527/1178806)

[frol]

FYI, Arbitrary JSON Events support in near-sdk-rs that was contributed by @coleFD and thoroughly reviewed by @austinabell was merged! near/near-sdk-rs#934

@coleFD Thanks for the contribution!