moonstream-to
Schema for ABI generated dashboard properties
proposed schema:
{
"title": "Dashboard",
"description": "Dashboard settings",
"type": "object",
"required": ["id", "name"],
"properties": {
"id": {
"type": "uuid",
"description": "id of dashboard"
},
"name": {
"type": "string",
"desciption": "name of dashboard"
},
"subscriptions": {
"type": "array",
"description": "Subscriptions to report on",
"items": {
"type": "object",
"required": ["id"],
"properties": {
"id": {
"type": "uuid",
"description": "Subscription id"
},
"report_ABI": {
"type": "boolean",
"description": "if set true - must report ABI data"
},
"ABI_selections": {
"type": "array",
"description": "Abi methods to report on",
"items": {
"type": "string",
"description": "method to report on from ABI"
}
}
}
}
}
}
}
Sample object:
{
"id": "9a14bb46-215b-4878-ba4a-01b15489ed88",
"resource_data": {
"name": "Crypto Elephants secondary market activity",
"subscriptions": [
{
"subscription_id": "0869942d-3cd2-4ea5-9424-d0f3e1653173",
"generic": [
{"name": "transactions_in", "filters": {"from": "0x9f8B214bF13F62cFA5160ED135E233C9dDb95974"}},
{"name": "transactions_out", "filters": {"to": "0x9f8B214bF13F62cFA5160ED135E233C9dDb95974"}},
{"name": "value_in"},
{"name": "value_out"},
{"name": "balance"},
],
"methods": [
{"name": "safeTransferFrom", "filters": {"tokenId": "110392"}}
],
"events": [
{"name": "Transfer"},
{"name": "Approval", "filters": {"approved": "0x7Be8076f4EA4A4AD08075C2508e481d6C946D12b"}}
]
},
]
}
}
How will these metrics be displayed to user on frontend?
Version 1
For each metric, a distinct bar or line graph (user can select) representing time series over the selected time period.
Future versions... maybe?
User can select how to group metrics together into different charts. We may adopt a Mixpanel-like data model in which there are reports (representing individual charts) and dashboards (representing groups of charts).
How will we validate dashboard create and update requests?
- Load ABI from subscription resource.
- For each method and event, check that the ABI contains that method or event.
- For each filter on method or event, check that the ABI for that method or event contains the filter argument and that the value has a consistent type.
- For generic metrics, check against a static schema.
On error, return 400 response with a body that describes the failed validation.
For example, if a user submits a dashboard like this:
{
"id": "9a14bb46-215b-4878-ba4a-01b15489ed88",
"resource_data": {
"name": "Crypto Elephants secondary market activity",
"subscriptions": [
{
"subscription_id": "0869942d-3cd2-4ea5-9424-d0f3e1653173",
"generic": [
{"name": "transactions_in"},
{"name": "transactions_out"},
{"name": "value_in"},
{"name": "value_out"},
{"name": "balance"},
],
"methods": [
{"name": "safeTransferFORM", "filters": {"tokenId": "110392"}}
],
"events": [
{"name": "Transfer"},
{"name": "APOORVAL"}
]
},
]
}
}
We will not create a dashboard. We will return a 400 with Content-Type: application/json and the following JSON body:
{
"errors": ["methods[0]: ABI does not have method: safeTransferFORM", "events[1]: ABI does not have event: APOORVAL"]
}
What happens if a user changes the ABI on a subscription that is part of this dashboard?
We will not allow users to edit an ABI on a subscription. If they want a new ABI, they should create a new subscription.
Otherwise, we would require too many consistency checks on subscription updates.
What if a user wants to crawl all methods or all events?
(And there are a lot of methods and events.)
{
"id": "9a14bb46-215b-4878-ba4a-01b15489ed88",
"resource_data": {
"name": "Crypto Elephants secondary market activity",
"subscriptions": [
{
"subscription_id": "0869942d-3cd2-4ea5-9424-d0f3e1653173",
"generic": [
{"name": "transactions_in", "filters": {"from": "0x9f8B214bF13F62cFA5160ED135E233C9dDb95974"}},
{"name": "transactions_out", "filters": {"to": "0x9f8B214bF13F62cFA5160ED135E233C9dDb95974"}},
{"name": "value_in"},
{"name": "value_out"},
{"name": "balance"},
],
"all_methods": true,
"all_events": true
},
]
}
}
If "all_methods": true and "methods" is specified, return a 400 response.
If "all_events": true and "events" is specified, return a 400 response.
It's more explicit and easy to understand from a debugging standpoint than if we add a priority to handling these keys.
What if a user wants to crawl smart contract state?
We do need to add crawlers that periodically check state variables on smart contracts. This is out of scope for this first version, as it requires us to extend our crawlers.
Tracking as a separate issue: https://github.com/bugout-dev/moonstream/issues/346
We apply new field on dashboard resource: counted_events
{
"id": "9a14bb46-215b-4878-ba4a-01b15489ed88",
"resource_data": {
"name": "Crypto Elephants secondary market activity",
"subscriptions": [
{
"subscription_id": "0869942d-3cd2-4ea5-9424-d0f3e1653173",
"generic": [
{"name": "transactions_in"},
{"name": "transactions_out"},
{"name": "value_in"},
{"name": "value_out"},
{"name": "balance"},
],
"methods": [
{"name": "safeTransferFORM", "filters": {"tokenId": "110392"}}
],
"events": [
{"name": "Transfer"},
{"name": "APOORVAL"}
]
"counted_events": [ {"type": "event", "name": "Transfer"}]
},
]
}
}
That field define wich events must live in cards component.
Change "subscriptions": [ frontend | "dashboard_subscriptions" backend to "subscription_settings": [
Update to use object-keys instead of array
"methods": {
"0x93123": {"name": "safeTransferFORM", "filters": {"tokenId": "110392"}}
"0xabcdef": {"name": "safeTransferFORM", "filters": {"tokenId": "110392"}}
},
Alternative approach:
"methods": [
{"name": "safeTransferFORM", "filters": {"tokenId": "110392"}, "selector": "0x12345"}
{"name": "safeTransferFORM", "filters": {"tokenId": "110392"}, "selector": "0xabcdef"}
],