I'm not entirely sure of the product requirements at the moment, so i'm deferring this until later, and those requirements are more concrete. but the manager app and the portal and perhaps other third-party apps will definitely want to display some sort of history for a name or history for a resolver or history for a registry, etc., etc., which needs to encode either
a) a highly specific concrete list of actual ens protocol events that have occurred or
b) a higher-level abstraction over those events to simply describe the changes that have occurred, and then uis can pull the protocol-specific values from the rpc as necessary, for example, like the actual data and then decode it into the specific events for the ui.
if we store actual data, the amount of storage used could go crazy?, and looking up event log data is probably pretty trivial via rpc. so we probably omit it for now. or compare with/without to get some metrics
ensure Event is fully generic
- re-materialize
Registration.start to keep that semantic
- add transaction
to to Event
- if nesting under Transaction, then obviously store it there
- the
Event type is what's actually stored within history
- still link to an
Event via event.id for Registration/Renewals
- correlate
Events with Domain/Resolver for audit trail
- add an enum
name that reflects the name of the event
- maaaybe need to make this a higher level concept to merge ENSv1/v2 ideas
- if name is refactored, include a
signature field that includes the full unique signature of the event
filtering *.history
- allow
where: { signature: "..." } (only necessary if name doesn't correlate)
- allow
where: { name: "..." }
- allow filtering
timestamp (gte/lte) where: { timestamp_gte: 0, timestamp_lte: 0 }
- allow
where: { from: Address }
also provide Account.events which returns all events for which the account is sender
- allow name/(signature)/timestamp filtering as with
*.history
IF the view must be grouped by transaction, store transactions & events so that the api-level pagination is trivial
otherwise just store them as a flat list of events under history and call it a day? the filters then need hoisting and i hate that.
Domain Events (Domain.history)
ENSv1 Registry events
ENSv1 NameWrapper events
ENSv1 Registration events
Resolver Events (Resolver.history)
- AddrChanged (addr)
- MulticoinAddrChanged (coinType, address)
- TextChanged (key, value)
- ContenthashChanged (hash)
- NameChanged (name)
- AbiChanged (contentType)
- PubkeyChanged (x, y)
- InterfaceChanged (interfaceID, implementer)
- AuthorisationChanged (owner, target, isAuthorised)
- VersionChanged (version)
probably need a join table domain_history_entries to link (domainId, eventId) and a resolver_history_entries for (resolverId, eventId)
if resolver events are to also be recorded in the domain history, we can go ahead and do that, easy enough
add to example queries
add integration tests for the events, including pagination tests that check against the (timestamp, chainid, etc) sort
I'm not entirely sure of the product requirements at the moment, so i'm deferring this until later, and those requirements are more concrete. but the manager app and the portal and perhaps other third-party apps will definitely want to display some sort of history for a name or history for a resolver or history for a registry, etc., etc., which needs to encode either
a) a highly specific concrete list of actual ens protocol events that have occurred or
b) a higher-level abstraction over those events to simply describe the changes that have occurred, and then uis can pull the protocol-specific values from the rpc as necessary, for example, like the actual data and then decode it into the specific events for the ui.
if we store actual data, the amount of storage used could go crazy?, and looking up event log data is probably pretty trivial via rpc. so we probably omit it for now. or compare with/without to get some metrics
ensure Event is fully generic
Registration.startto keep that semantictoto EventEventtype is what's actually stored withinhistoryEventviaevent.idfor Registration/RenewalsEventswith Domain/Resolver for audit trailnamethat reflects the name of the eventsignaturefield that includes the full unique signature of the eventfiltering
*.historywhere: { signature: "..." }(only necessary if name doesn't correlate)where: { name: "..." }timestamp(gte/lte)where: { timestamp_gte: 0, timestamp_lte: 0 }where: { from: Address }also provide
Account.eventswhich returns all events for which the account is sender*.historyIF the view must be grouped by transaction, store transactions & events so that the api-level pagination is trivial
otherwise just store them as a flat list of events under
historyand call it a day? the filters then need hoisting and i hate that.Domain Events (
Domain.history)ENSv1 Registry events
ENSv1 NameWrapper events
ENSv1 Registration events
Resolver Events (
Resolver.history)probably need a join table
domain_history_entriesto link(domainId, eventId)and aresolver_history_entriesfor(resolverId, eventId)if resolver events are to also be recorded in the domain history, we can go ahead and do that, easy enough
add to example queries
add integration tests for the events, including pagination tests that check against the (timestamp, chainid, etc) sort