feat: add event-standard

[ghost]

Based on #256 (comment)

Need to separate standards of event vs. the information it captures.

Event Standard

This pr says every event should adhere to common format - json, binary, etc.

[danielwpz]

hey, do you think we need a version for the event standard itself? So that we can support the evolution of this standard.
lets say years later we decide to remove some fields from the event json, there should be a way for event consumers to tell whether it could handle an event correctly

[ghost]

wasn't thinking of that but yes, do you mean this - https://github.com/near/NEPs/pull/268/files#diff-54ad87ad1f7568238db42e0751f9ceecdcf416d189dc7896e6a565aee0bc2140R51

As this standard evolves and reaches a more stable version e.g. >= 1.0, we can expect less disruptive changes for implementors. Of course it shouldn't be enforced so if v0.5 works for consumer A then potentially still be able to parse v1.0 events but some fields would be null.

[ghost]

Just understood what you meant. How would we know other format like BINARY event changed from v0.1 to v.0.2.

Not sure, I think that's part of discussions that hasn't happened yet for the different formats an event can be. Each format could have the version embedded or appended like so EVENT_BINARY_V0.1.0. I will enquire about this

[frol]

I am all for having a dedicated NEP for the events. Yet, I am a bit concerned about having too many event formats, so I believe that we don't want to have versioning; I believe having unique names will be enough:

• EVENT_JSON is quite flexible since you can parse only standard, version, and event, and only then decide if you need to deal with data which is quite arbitrary, so I hope JSON events won't ever need anything beyond that
• EVENT_BINARY is not specific enough, so we might come up with a better name in the first place, and make sure we can parse standard_id, standard_version, and event_kind from the event header easily, and after that, it could be quite arbitrary binary sequence
• I cannot come up with any extension that we won't be able to express with the first two, but if we ever would need that, I believe a unique name EVENT_XXX will be more than enough

That said, I don't want us to overengineer the marker name and introduce versioning where we only define a serialization format and a slim header (standard_id, standard_version, and event_kind)

[danielwpz]

yeah by adding version I meant something like EVENT_JSON 1.0.0 <json_event_body> as the logging output.

The reason why I think it would be nice to have a version is that this proposal is mainly driven by a NFT use case #256 , we cannot say it's flexible enough for all other cases. A semantic version, if used properly, could help clients to identify incompatible updates of this standard, no body can guarantee this standard won't change in the future.

I totally agree to make this simple and slim, one work around could be logging NEP268_JSON <event_body>. So that in case a new standard was proposed, there is a way for consumers to distinguish them.

[danielwpz]

another concern is that we current have a limit for the max number of logs a transaction could have. If we are using logs for events, this could be a bottleneck.
Imagine a NFT contract which allows batch mint/transfer is very likely to be affected by this limitation.

[ghost]

Yes the limitation is 16kb string. It is already limited e.g. a batch with very large number is generally not possible. Hoping for a good baseline but is a known drawback.

While it is a good idea to version events themselves, soon will end up something like this

NEP1_JSON {"version":"1.0.0", "standard":"nep1"}
NEP2_JSON {"version":"1.0.0", "standard" :"nep1"}

This could be seen as unnecessary duplication or a very complex versioning system.

We want the events to be generic and not only for NFTs. Most of the specificities are in the data field, the rest is generic.

[frol]

This PR was taken over in #298 and resulted in NEP-297.