This thread will collect public development updates of AE_MDW - Elixir middleware on a weekly basis.
At the moment, we are a team of 3 people: @danielaivanova.chain, @Arthur and @karol.chain, while @sslavov (from SuperHero team) is helping with frontend work to provide full experience.
AE_MDW is meant to be a go-to tool for everybody wanting to explore history and name system in Aeternity ecosystem.
In this first update, I’ll briefly summarize overall status.
AE_MDW can currently do:
(For description of endpoints and examples, please consult ae_mdw/README.md at master · aeternity/ae_mdw · GitHub)
There is a lot of other, “invisible” functionality implemented:
This week’s focus is mainly in areas related to designing and implementing Naming System support (@karol.chain), start of dockerizing of the whole service (@Arthur) and start of updating legacy middleware front-end to support AE_MDW backend.
if possible it would be nice to have the new swagger / openapi definition as soon as possible 
This one is still the most up to date: https://github.com/aeternity/ae_mdw/blob/master/priv/static/swagger.json
The naming part will be changed once names land the master.
Last week, Artur worked on preparing Docker images of middleware for people who want to host MDW without the need to build them first.
Stanislav was exploring approaches how to adapt legacy MDW front-end with our new backend.
Karol was updating the ways we synchronize names and auction, to speed up syncing and reduce complexity.
[WEEK 33]
Arthur - finalizing docker file, CIs investigation
Daniela - - swagger specs for naming system + refactoring
Stanislav - added pages: transactions for an account, contract, list of contracts
Karol - implemented sync + fork invalidations on new DB design, start of name endpoint refactor
No blockers found.
Next week we expect merging new name system and docker + progress in NS swagger specs, CI and finishing frontend functionality with current endpoints design.
[WEEK 34]
Arthur - docker file perf optimizations, CI investigation + testing various configs
Daniela - fixing swagger txs issue, fixing performance tests logic + docs, tests for naming system
Karol - merged new name system (currently with disabled invalidations - TODO) + readme about NS
(Note: name system is ready to use, endpoints will keep backwards compatibility.)
No blockers found.
Next week we will finalize name system - invalidation and tests, possibly merge docker config.
More investigation how to approach CI for MDW is needed.
[WEEK 35]
Arthur - work on missing endpoints for frontend, work on Vue hosted by Phoenix for dropping node
Daniela - adjusted swagger specs for new NS, added new swagger.json file, writing tests for NS
Karol - finished invalidations (name system is merged & complete now), block(s) endpoint design
No blockers.
We are focusing on implemetation of missing endpoints for frontend.
[WEEK 36]
Arthur - work on Vue-Phoenix integration for hosting frontend without Node dependency
Daniela - finalized name system tests, work on tests for block/blocki/blocks endpoints
Karol - logic for block/blocki/blocks endpoints, exploring oracles integration
No blockers.
Next week we want to finish swagger tests for block(i/s) endpoints, progress on Oracles endpoints (active/inactive/all) and possibly revive AE node HTTP endpoints in MDW
[WEEK 37]
Arthur - finalizing Vue-Phoenix integration and Docker configuration, resuming work on CI integration
Daniela - finished tests and swagger specs for block/blocki/blocks endpoints, extending performance tests with name and block endpoints
Karol - enabling AE node HTTP endpoints, oracles syncing/invalidations, start of oracles endpoints, mainnet deployment debugging
No blockers.
Next week - merging Docker, Vue-Phoenix integration, improved performance tests and ideally finalizing Oracles
Can‘t wait to test the middleware 
Middleware is synced and ready for initial testing, running here https://mainnet.aeternity.io/mdw
e.g.:
$ curl -s "https://mainnet.aeternity.io/mdw/status" | jq '.'
{
"mdw_height": 310468,
"mdw_synced": true,
"mdw_tx_index": 15392897,
"mdw_version": "0.1.0",
"node_height": 310468,
"node_version": "5.5.4"
}
Performance is not representative, we plan to use a better performing host in near future.
I took the swagger.json file and imported into swagger-hub. I had to make some small changes (dunno if there are some errors within the file or whether it was a conversion problem of swagger hub).
you can play around with the API here:
@karol.chain just started playing around with the new middleware and it seems like we cannot filter active names by owner. this was possible previously
edit 1:
edit 2:
btc.chain
btc.chain appears in the list of auctions but the data returned seems to be outdated (maybe it was revoked before and now has again a running auction?)btc.chain it returns active=false and status=name => shouldn’t the status be revoked or active then?claims, bids & update arrays stand for
edit 3:
the response of /name/kryptokrauts.chain looks like this:
{
"active": true,
"info": {
"active_from": 164809,
"auction_timeout": null,
"claims": [
4910093
],
"expire_height": 337727,
"ownership": {
"current": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"original": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV"
},
"pointers": {
"account_pubkey": "ak_2QGAAqDXK7g8zCbck7zm25TGAW1hRuVCET2SRCCFCMSMjrVCrF"
},
"revoke": null,
"transfers": [],
"updates": [
13654101,
9992918,
6685739,
4968822,
4968737
]
},
"name": "kryptokrauts.chain",
"previous": [],
"status": "name"
}
I know that this name was revoked in the past and had at least 3 claims within the initial auction. how can I get this data?
Hi @marco.chain thanks for testing!
1.) filter names/auctions by owner - that’s not implemented at the moment
I’ll add another index keeping this information and extend the name querying to support it.
2.) btc.chain:
$ curl -s "http://localhost:4000/name/btc.chain" | jq '.'
{
"active": false, # not active any more - expired
"info": {
"active_from": 192815,
"auction_timeout": 29760,
"claims": [
4813782,
4726470
],
"expire_height": 242815, # expired at this height
"ownership": {
"current": "ak_2u8Ut2pD7e2AEfaENDocUz2vfyu745j9dckMJp5243BSwCynbT",
"original": "ak_2u8Ut2pD7e2AEfaENDocUz2vfyu745j9dckMJp5243BSwCynbT"
},
"pointers": {},
"revoke": null,
"transfers": [],
"updates": []
},
"name": "btc.chain",
"previous": [],
"status": "name"
}
But, indeed it’s also in auction again at the moment:
$ curl -s "http://localhost:4000/names/auctions" | jq '.data [] .name'
"b.chain"
"8.chain"
"5.chain"
"btc.chain"
"ant.chain"
"jelly.chain"
"nikita.chain"
"AEStudio.chain"
"neuralink.chain"
The name endpoint first checks active and inactive names, because in case like this, if it shows auction first, there wouldn’t be a way to get the last valid name information (ownership, txs related to the name, …)
I’ll add another endpoint auction - that one will return last bid information only if it is in auction.
The status field in name reply - can be either:
If the name was revoked with revoke transaction - the status would be “name” (because it was a real name before), active would be “false”, and revoke would have transaction index instead of “null”.
The integers in arrays of claims, updates, transfers and single integer in revoke - they are transaction indices - unique integer identifiers of txs.
The idea was to not return all the details for each name, as it can be a lot of data. User can take the transaction id and query it if needed, eg. - first claim for btc.chain:
$ curl -s "http://localhost:4000/txi/4813782" | jq '.'
{
"block_hash": "mh_YgGcm1CPaTgLAzyuDspNEj5mUC7S45zcU4PciyTdbeis9r25J",
"block_height": 163055,
"hash": "th_2eopxM3qfDKJSgUn3hQfii7JHzHWgZwoRiFpJAQBTd2L5BYvsD",
"micro_index": 9,
"micro_time": 1572790967367,
"signatures": [
"sg_qFpAA7VPWHpLZrfroeBkDeeJuBWYrqdkNjFA7DHHVw6TSpVfXGPmmydA4KizgjWqA9ywqLoTAPiWQmy1EfABfeoMkkUE"
],
"tx": {
"account_id": "ak_2u8Ut2pD7e2AEfaENDocUz2vfyu745j9dckMJp5243BSwCynbT",
"fee": 16360000000000,
"name": "btc.chain",
"name_fee": 5e+20,
"name_id": "nm_REqqEHnPPD5ZGgqeHSn9HwE5K1e99kmE4pjsKJSJbjoH8ZMdA",
"name_salt": 0,
"nonce": 3,
"type": "NameClaimTx",
"version": 2
},
"tx_index": 4813782
}
But since it’s a valid use case to get everything in one go, I’ll add expand query parameter which when present returns full jsons for txs in those arrays, to avoid roundtrips needed for pulling all info.
(README in repo should have explanations for all fields in the replies)
3.) kryptokrauts.chain
Locally, I have a fixed version of MDW, so pulling full history for a name works:
$ curl -s "http://localhost:4000/txs/forward?name=kryptokrauts.chain&limit=100" | jq '.'
{
"data": [
{
"block_hash": "mh_8KVfET8fJW7AX5exbUNu4k9448xEEzbunG8enT5vQM6Szh3r3",
"block_height": 161256,
"hash": "th_pxVHa3C9QmbfmSZQJ3m4uuzNeQLaPbwZxqetxS7zVdh1DWo35",
"micro_index": 0,
"micro_time": 1572466616063,
"signatures": [
"sg_A4YLyxnrA2tRfEgXQuGADhgdLdgp5Po6CmjWffTS1yhKEt2ehJsiNfMZSaJU9sKs4beLNsYFkYw7KvxXSSXEUz5ipq81Q"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"fee": 16700000000000,
"name": "kryptokrauts.chain",
"name_fee": 2865700000000000000,
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_salt": 13738264157424663000,
"nonce": 2,
"type": "NameClaimTx",
"version": 2
},
"tx_index": 4677602
},
{
"block_hash": "mh_2cC6yYfJbuzFtkEHY7iu9UFAWW6fKPYT1G3TX7mZCnyhie84hP",
"block_height": 161723,
"hash": "th_kNBQdCtdtYGKnUMGs6Bam7Vq93Mx6dwo6oTLhsdznXEZoFgMK",
"micro_index": 2,
"micro_time": 1572550092237,
"signatures": [
"sg_Xo71X4BF1ubwVGCEJnZhMLAbtku2Z9coC3LD6gcTfJkmDCvWhCcWEtcLQoJFqxxybTVk7QkNfvXPHoFNC4zhSLk3LzLUS"
],
"tx": {
"account_id": "ak_2ruXgsLy9jMwEqsgyQgEsxw8chYDfv2QyBfCsR6qtpQYkektWB",
"fee": 16540000000000,
"name": "kryptokrauts.chain",
"name_fee": 4e+18,
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_salt": 0,
"nonce": 133,
"type": "NameClaimTx",
"version": 2
},
"tx_index": 4712510
},
{
"block_hash": "mh_2TT4DSk8UCRMmbXaSnFukovirHC2D2KEkhsQuiNhcqPHt4e29t",
"block_height": 161730,
"hash": "th_2aKbv2DSfa42UarE4WF7yQw9NVJ9LsPA38MdiuZks73pVLGwAh",
"micro_index": 17,
"micro_time": 1572551564324,
"signatures": [
"sg_EYx8irvokXVuLEzhyAVCbQ1tpe7zGgYnrmFjxHrgSybo3bQhk8kNj3ymNeJRrYMCAGa3wJDkZukSGNgaPDkjJFnYjX8QD"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"fee": 16540000000000,
"name": "kryptokrauts.chain",
"name_fee": 4.2e+18,
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_salt": 0,
"nonce": 75,
"type": "NameClaimTx",
"version": 2
},
"tx_index": 4713104
},
{
"block_hash": "mh_2iKjfjJXyPT5Wwars2BbrzNGDsgsvoDUb2KKBaxfLnjvLoQemZ",
"block_height": 162223,
"hash": "th_259B1j2hHmg9BbcKyMbTKCB1KXqiddrHTYKBiUwJk8J5hRTSzq",
"micro_index": 34,
"micro_time": 1572638969545,
"signatures": [
"sg_JzRjEZFkUqLt3YuELMKA6BnxM9DgVCoEhnjWTLJeQkQ5XfKzTH6KKFaEL2yAHpqijZwn5jK5qZmfyeJZ6t5GMH2Kp66As"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"client_ttl": 0,
"fee": 17700000000000,
"name": "kryptokrauts.chain",
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_ttl": 0,
"nonce": 105,
"pointers": [
{
"id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"key": "account_pubkey"
}
],
"type": "NameUpdateTx",
"version": 1
},
"tx_index": 4749564
},
{
"block_hash": "mh_iNeqDa2RascsrZFWCyjNdb7mWSWi1TzdmB5JW1MphpVMBy21f",
"block_height": 164329,
"hash": "th_5iDs97dCh8o3UE3XmRVyUosgUwpRUB3K2qJz1AqyfjLLtiFgt",
"micro_index": 0,
"micro_time": 1573020264503,
"signatures": [
"sg_GVw95MPapandxQkPebr8m3TN4CMLe5YUhXh7LD2zMN8tUwToKdaeL65ExnRgd9C2o7A7NyAH75zZZ9WRiRxzj2yHHrPFV"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"fee": 16700000000000,
"name": "kryptokrauts.chain",
"name_fee": 2865700000000000000,
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_salt": 12169832380676643000,
"nonce": 123,
"type": "NameClaimTx",
"version": 2
},
"tx_index": 4910093
},
{
"block_hash": "mh_9ibihHDwhLgwZTGR4ECn5iLLw4DFyK7yi2vS1C5JUvtRgugRC",
"block_height": 165115,
"hash": "th_2FmHk71wWxcx2oUfNAavX5TUnFA8vaS83aNhuwgYQt3u59NkGz",
"micro_index": 15,
"micro_time": 1573162891973,
"signatures": [
"sg_WD2C9BMBV6moUCkrKMtBsTccn98pKzrkyhK8nnTYrj7pGZ4V5Zo5Lgtao61ieRggVzG94H2VVKQzHPTAZrUJXx29QePtX"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"client_ttl": 0,
"fee": 17740000000000,
"name": "kryptokrauts.chain",
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_ttl": 50000,
"nonce": 125,
"pointers": [
{
"id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"key": "account_pubkey"
}
],
"type": "NameUpdateTx",
"version": 1
},
"tx_index": 4968737
},
{
"block_hash": "mh_2ZvfuMY6Pc5rNFLunHWZQgjTdUagndt6PFoWMV3pjVan71Q3gJ",
"block_height": 165117,
"hash": "th_2TFuNFBhA69SUaoeXhKhjopcRXDBLgbxTFsmrDDH9wjnGyfueE",
"micro_index": 43,
"micro_time": 1573163102805,
"signatures": [
"sg_WmpCrRPvZCeKtWkbYFsKc6P3mSKLECnR4CgVBx5mg3c7Y2Lq1NTVA7njWZ6h96eC7yu7MHCRCRyiE7USpTsZBrv9UxuLM"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"client_ttl": 0,
"fee": 17740000000000,
"name": "kryptokrauts.chain",
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_ttl": 50000,
"nonce": 126,
"pointers": [
{
"id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"key": "account_pubkey"
}
],
"type": "NameUpdateTx",
"version": 1
},
"tx_index": 4968822
},
{
"block_hash": "mh_2fJ9KEE5UnvvgA8kKnfGnAq82CUAqtgBr5CFrBJquJufWe7bUy",
"block_height": 195999,
"hash": "th_2CMshRX2jJE9im7AMsBnjSic2px8sHh989vpmQx8tPn7wHkHMM",
"micro_index": 36,
"micro_time": 1578749492928,
"signatures": [
"sg_GvYhieGPYFZYfPUfyEMq8bF5wVjUEaBNJ9LNFTPtagPDPuqJVgs6wVB7Nm2fqQACXNFxYbBvdWvH6aMxSggCi5UtfNUv6"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"client_ttl": 0,
"fee": 17760000000000,
"name": "kryptokrauts.chain",
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_ttl": 50000,
"nonce": 137,
"pointers": [
{
"id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"key": "account_pubkey"
}
],
"type": "NameUpdateTx",
"version": 1
},
"tx_index": 6685739
},
{
"block_hash": "mh_85uHYvH27J38Rd8CQiJnSCGqpMS6rtcGKBYCSYk1ayPPc4MM6",
"block_height": 239966,
"hash": "th_7RVW3kUKctkqSeperGiW3WdJtmG5N8sqwFhRrcTtREGYkiUfE",
"micro_index": 23,
"micro_time": 1586707720770,
"signatures": [
"sg_SNhJWwV1yYmVL44WsKSp4pQ9DvV5vq4ZMXWKHyiz8jbRLeRTzajZtSFxVEPGw2T3RHaTBrNCpn79Z5iqkcKtyeBbjHppV"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"client_ttl": 0,
"fee": 17760000000000,
"name": "kryptokrauts.chain",
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_ttl": 50000,
"nonce": 179,
"pointers": [
{
"id": "ak_2QGAAqDXK7g8zCbck7zm25TGAW1hRuVCET2SRCCFCMSMjrVCrF",
"key": "account_pubkey"
}
],
"type": "NameUpdateTx",
"version": 1
},
"tx_index": 9992918
},
{
"block_hash": "mh_2QXcrh5qjcNkx72xGwHbfKYeL5Gbf7iGr4it6XTVKvDYna6hGw",
"block_height": 287727,
"hash": "th_2QEKrD4drPfqcGAaEGHL76cLRdxDtwXuJqfJzPQDEpxUpAXBdZ",
"micro_index": 12,
"micro_time": 1595343236527,
"signatures": [
"sg_VQSP5Ehcwp9xin5zUHMJRe443L9kaS1buBUGTyh9qTFyQHs8Ab71F4RgCTUkCKsM4fxB78vv7vpJ55At4JprDphA6f7pN"
],
"tx": {
"account_id": "ak_5z1fmzTKR1GA1P7qiLDCC1s3V7AK2RRpNbXqUhfHQbUeg7mmV",
"client_ttl": 0,
"fee": 17760000000000,
"name": "kryptokrauts.chain",
"name_id": "nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr",
"name_ttl": 50000,
"nonce": 215,
"pointers": [
{
"id": "ak_2QGAAqDXK7g8zCbck7zm25TGAW1hRuVCET2SRCCFCMSMjrVCrF",
"key": "account_pubkey"
}
],
"type": "NameUpdateTx",
"version": 1
},
"tx_index": 13654101
}
],
"next": null
}
I’l push the fix upstream and we will update public hosts so it’s possible to retrieve transaction history related to name…
On deployed host without the fix, you can get the same result with:
curl -s "http://localhost:4000/txs/forward?name_id=nm_2HMHaB4d5H85b7m1PhU734Ebcfsyf7LwHwTdpUmYAyMgbYV6Lr&limit=100" | jq '.'
There doesn’t seem to be a revoke TX for that name, maybe it was during the period the node seeds were changed and there were multiple long running forks so it didn’t end up in main chain.
Thanks again for feedback!
thanks for clarification about that topic.
thanks! 
further explanation here:
do you think this is possible? if not can you please elaborate the limitations?
I think we are talking about different things here. the tx-endpoint already used to work, didn’t it?
in case of kryptokrauts.chain I performed a NameUpdateTx with name_ttl=0 and this caused an “implicit” revoke of the name.
can you give advise how to get all historical information for a certain name?
currently I guess we need to implement some custom logic within our application to extract that information based on the tx-history for the name (analyzing all NameClaimTx, NameUpdateTx & NameRevokeTx)
Contracts
For the ContractCreateTx the calldata isn’t decoded yet whereas for ContractCallTx we get the decoded calldata. Will you also add this for the ContractCreateTx?
With https://github.com/aeternity/ae_mdw/blob/master/README.md#name-resolution you should get a complete history.
In the reply, there’s a key previous, which shows previous “epochs” - time spans during which a particular name was active until expired or revoked.
Each name info for epoch has key ownership:
"ownership": {
"current": "ak_2CXSVZqVaGuZsmcRs3CN6wb2b9GKtf7Arwej7ahbeAQ1S8qkmM", # from transfer tx
"original": "ak_2CXSVZqVaGuZsmcRs3CN6wb2b9GKtf7Arwej7ahbeAQ1S8qkmM" # claimant
}
original - shows which account claimed the name
current - shows the last owner - either claimant or the last account the name was transferred to
The history of all transfers in the epoch is under the key transfers - tx indices for now.
(will be inline with the future “expand” parameter)
Similarly the revoke field - if non-null, it has tx index which can be used to pull the revoke tx details.
(will be expanded in future if requested)
The auctions - each auction is represented by the claim transaction, in claims key, where each claim represents auction bid.
Non-auction names (too long, or before Lima hardfork) have only the first claim.
ok I think I understand now. so I guess it is wrong that kryptokrauts.chain has an empty array for previous.
=> although there wasn’t an explicit NameRevokeTx it definitely expired due to my false NameUpdateTx with name_ttl=0
you can read the story here: https://kryptokrauts.com/log/first-claim-ever-of-an-aens-name
is previous currently only filled if there is an explicit NameRevokeTx?
Previous is filled only if:
there was some period of time during which the name was inactive - no matter if it expired implicitly (by owner not extending the name activity period via NameUpdateTx) or explicitly (by owner issuing NameRevokeTx) AND the name is/was active again after that…
If the name was active just once, it’s just inactive name with empty previous array.
ok I understood. yes then there seems to be an issue for kryptokrauts.chain where previous should be filled because it has been claimed 2 times. can you check that?