Closed Jpja closed 1 year ago
@Jpja thanks for posting this (first) issue!
This response will also explain why there is no public api (at least for now).
The current version of xcp.dev
can be considered an "opinionated" data explorer. My approach to adding features is mainly based on what I want to present in the website, and then I build the api endpoint(s) that will provide the feature/functionality.
But by being open source, anyone can build their own alternative implementation.
Here is the query that returns the issuance data you see in xcp.dev/address/<address>
:
SELECT i.*, b.block_time
FROM issuances i
JOIN blocks b ON i.block_index = b.block_index
WHERE i.asset IN (
SELECT asset
FROM issuances
WHERE issuer = $issuer
AND status = 'valid'
)
AND i.status = 'valid'
ORDER BY i.tx_index ASC;
This provides all the data I need to show the assets that at any moment the address of interest has been an issuer. And in my design, I want to show each asset only once, because then, the user is still able to find all issuance data related to an asset in its xcp.dev/asset/<asset>
page.
In this asset page (EDIT: In the api response from the asset page) both the source
and issuer
data for each issuance is presented.
But having said all this, what feature/functionality would you like to see that is not currently offered, or you would like to be done different or simpler/more direct (like not having to open multiple pages)?
Looking at the page https://www.xcp.dev/asset/PEONTRUST, I do not see the two variables clearly lableled. Source (original owner) and issuer (current-owner) should be clearly market. In this case they should be two different values. One can determine the values manually by reading through the ownership transfers.
However, I would like to add context to the OP. It is important information to clarify and not conflate these values. Currently, the only (semi) public counterparty API offered displays the new owner address for both 'issuer' and 'owner'. https://xchain.io/api/asset/peontrust
All in all it would be nice to have the most relevant information available for each asset. for example, this page draws from 4 different API sources in order to get all the relevant information in once place. https://thewojakway.com/card/peontrust
Information for each asset could include the following:
If you were to consider offering an public API, I would like to give it more consideration and add to the discussion then.
thanks!
Looking at the page https://www.xcp.dev/asset/PEONTRUST, I do not see the two variables clearly lableled.
Fair, I should have said "asset api response" instead of "asset page".
Here is the api response relating to the issuances for PEONTRUST:
{
"ip":"x.x.x.x",
"message":"",
"data": {
"asset_row": {"asset_id":"3169021483439","asset_name":"PEONTRUST","block_index":727248,"asset_longname":null},
"tables": {
"issuances": [
{"tx_index":1944400,"tx_hash":"1a16f978ed7e91ff3a856187e934cf3280869305d30eaff600e1b3e86c05b967","msg_index":0,"block_index":727248,"asset":"PEONTRUST","quantity":1971,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","transfer":0,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":50000000,"locked":0,"status":"valid","asset_longname":null,"reset":0,"block_time":1647230649},
{"tx_index":1966982,"tx_hash":"2e388efe2a7b923d04beb16f39236b0ca99b58b51151fedb9a3f278f251b023a","msg_index":0,"block_index":729157,"asset":"PEONTRUST","quantity":0,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","transfer":0,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":0,"locked":1,"status":"valid","asset_longname":null,"reset":0,"block_time":1648327752},
{"tx_index":2150723,"tx_hash":"b799ed81fdb285d3ed99f79b4732538fe9fb1a7e4cb38966f8c42ccec797204f","msg_index":137,"block_index":759528,"asset":"PEONTRUST","quantity":0,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"13TxabRnJncRY8rC6o5jzXyEYThbjpvghH","transfer":1,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":0,"locked":1,"status":"valid","asset_longname":null,"reset":0,"block_time":1666275319},
{"tx_index":2210607,"tx_hash":"f4c3eda85f65fd35b9febb92be7021473123c5409ee6ab07f0552751c92c0976","msg_index":222,"block_index":770068,"asset":"PEONTRUST","quantity":0,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"1N1JG4AoxfnR7K6AdyE3qAnoEd4PqdCtm3","transfer":1,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":0,"locked":1,"status":"valid","asset_longname":null,"reset":0,"block_time":1672684057}
],
"destructions":[]
}
}
}
The issuances array comes directly from the following query done to the protocol's SQLite database:
SELECT i.*, b.block_time
FROM issuances i
JOIN blocks b ON i.block_index = b.block_index
WHERE i.asset = $asset_name
ORDER BY i.tx_index ASC;
So, the api response includes ALL the issuance data available for an asset (even the invalid entries).
The page does hide some properties, but it is a design choice to avoid repetition while still providing the same fundamental information. Also, the protocol's database does not have an "owner" property, so I don't think I will adopt it.
But @speaktech, you might have discovered a (quite bad) bug. My understanding was that source
meant the transaction originator, not the original (as in the genesis issuance) issuer. Which is consistent with the use of the same field name for other types of transactions in the protocol.
Were you able to transfer the issuance of PEONTRUST a second time from the original/genesis issuer address?
PS: Thanks for your suggestions of what to include in the asset page / api. Some of these suggestions are already provided, but will still take your input in consideration for future features / adjustments.
Were you able to transfer the issuance of PEONTRUST a second time from the original/genesis issuer address?
Looking at the input address (source) for tx_hash: f4c3eda85f65fd35b9febb92be7021473123c5409ee6ab07f0552751c92c0976 you can see it came from the transferred issuer 13TxabRnJncRY8rC6o5jzXyEYThbjpvghH.
The Bitcoin transaction is correct, so the bug is not as bad as it seems (in this instance, maybe it can still be exploited?). Is just the message that is stored wrong in the SQLite DB, making my "hide unnecessary data" approach even more appropriate in this case lol.
@Jpja @speaktech anything else you want to discuss or add? If not I'll close this issue.
@Jpja @speaktech as explained above, the original issue of hiding the source
is a design choice to avoid repeating data. Because all issuances are always shown, the previous issuer
in a transfer (the source
) is the one above... BUT there was a case when this design missed data: when the genesis issuance is also a transfer.
The latest release (v0.9) fixes this by adding a "... from: \
..." to theissuer / source
result when the genesis issuance is also a transfer.
https://www.xcp.dev/asset/A12103990090051188182
Closing this issue as completed.
The
issuances
table has two addresses which are usually the same.However, when ownership is transferred the
source
is the previous owner and theissuer
is the new owner.Xcp.dev shows issuances for an address only when it is the
issuer
. I suggest showing also when the address issource
.