-
Notifications
You must be signed in to change notification settings - Fork 2
feat: generate contracts for Dojo events #11
Conversation
a62baad
to
42d3c47
Compare
42d3c47
to
03ff137
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.
Thanks for the good refactoring on the compiler part. Makes it more concise. 👍
event_selector: felt252, | ||
keys: Span<felt252>, | ||
values: Span<felt252>, | ||
historical: bool |
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 wondering if the historical should come from the calldata or something we defined when registering the event. @Larkooo could it make sense for the user to toggle this?
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.
At the moment, the historical
flag is provided through the dojo::event
attribute. That means, it is readable from the event contract (with historical()
). An option would be to call the event contract in the emit()
function to get the value of the historical
flag. So, no need to provide it when registering the event nor when calling the emit()
function.
What do you think ?
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.
Since we will add permissions, passing the boolean is effectively the cheapest way to do it, instead of reading additional data from the storage.
So let's keep it like this for the first iteration I think.
values: Span<felt252>, | ||
historical: bool | ||
) { | ||
EventEmitter::emit( |
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.
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.
Is there a real safety issue to emit an unexpected event from a "malicious" contract ?
I would say that, as the address of the system which emitted the event is stored in the event data, it's easy to filter out malicious events.
On the other hand, it can be heavy for a project to handle permissions for all its events.
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 checked with @Larkooo and it seems we need permissions. The point I feel hard it's the cost.. since permissions checks is expensive. But without permissions, everybody could overwrite some values... which could lead to unexpected client behavior.
4a2df9b
to
0ce9233
Compare
@remybar just added the Also added the permissions, let's sync on that when you have a chance. Thank you again for the great work on that! |
At the moment, a Dojo event is tagged with the attributes
dojo::event
anddojo::model
. To avoid that, this PR implements contract management for Dojo events directly with thedojo::event
.dojo::model
is no more useful for Dojo events.