-
Notifications
You must be signed in to change notification settings - Fork 773
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a json template for digital assets #125
Comments
Proposal a JSON template for digital assets.This proposal may change as needed to address comments or during implementation. Once the implementation is finished we will add the spec to the documentation. Right now the payload field is being used for 2 different purposes: to define the digital asset; and to add extra information to transactions. The proposal is to divide them into two separate fields. A digital asset field that is created in a A digital asset may have several characteristics:
The transaction would have an {
"id": "<uuid>",
"divisible": "<true | false>",
"updatable": "<true | false>",
"refillable": "<true | false>",
"data": "<json document>"
}
Changes to be the current transaction model.
Previous {
"id": "<sha3 hash>",
"transaction": {
"version": "transaction version number",
"fulfillments": [],
"conditions": [],
"operation": "<string>",
"timestamp": "<timestamp from client>",
"data": {
"uuid": "<uuid4>",
"payload": {
"title": "The Winds of Plast",
"creator": "Johnathan Plunkett",
"IPFS_key": "QmfQ5QAjvg4GtA3wg3adpnDJug8ktA1BxurVqBD8rtgVjP"
}
}
},
} New {
"id": "<sha3 hash>",
"transaction": {
"version": "transaction version number",
"fulfillments": [],
"conditions": [{
"cid": "<condition index>",
"condition": { },
"owners_after": ["<new owner public key>"],
"amount": "<int>"
}],
"operation": "<string>",
"timestamp": "<timestamp from client>",
"asset": {
"id": "<uuid>",
"divisible": "<true | false>",
"updatable": "<true | false>",
"refillable": "<true | false>",
"data": "<json document>"
},
"metadata": {
"id": "<uuid>",
"data": "<json document>"
},
},
} New {
"id": "<sha3 hash>",
"transaction": {
"version": "transaction version number",
"fulfillments": [],
"conditions": [{
"cid": "<condition index>",
"condition": { },
"owners_after": ["<new owner public key>"],
"amount": "<int>"
}],
"operation": "<string>",
"timestamp": "<timestamp from client>",
"asset": {
"id": "<uuid>",
},
"metadata": {
"id": "<uuid>",
"data": "<json document>"
},
},
} The amount is specified in the condition. Implementation detailsWe need to add extra arguments to Difference between
|
How does the new
|
Just think this is a desirable feature that should be supported. But don't know how it would be implemented yet. |
ok, maybe start from what you need to get the divisible assets working (and maybe the backlink from any |
Maybe change |
I'd suggest to remove
For now, I'd leave both of these goals/requirements out until we have a use case for them (which we haven't so far, if I'm not mistaken).
I'd like to know more about this as well. I could see that we drag
Second that. It should be clear that |
Actually this has already come up multiple times with COALA modelling; depending on the queryability of transactions, we may need to come up with ways to update a transaction's state (to support forward linking, as opposed to our current backward links). However, I agree in that we should spin updates and refills out into entire projects, since they'll take some investigation and will likely be involved to implement. Just to put on digital paper some thoughts about updatability:
|
My thought was that nothing prevents you from creating a divisible digital asset with amount=1 that can be refilled.
I agree. In an initial implementation we will not be able to refill or update a digital asset. Just put it there because is a use case we will want to support. I am not sure yet how the
I think I will renamed it to |
I don't think this is a problem for us since we don't know and don't care about what the digital asset is (its just a json document). Its the user responsibility to know what they are writing, "updating" in the database |
True; I meant the comment as more a concern for queryability, since we're "updating" the database but the existing links are still to the old objects. |
In terms of queryability you would need to be able to return the history of the digital asset or return the most recent version. If This is mostly expeculation right now because I don't know how this would be implemented or what are the use cases. |
hahahaha |
Some more thoughts related to the digital asset definition. Since the I am fine with this for now. It simplifies the initial implementation but if the need arises for the future we can consider moving Regarding linking To implement this we could look at the asset field of the input(s) and use that asset id. At the same time we can make sure that all the inputs are for the same digital asset. |
There needs to be an additional change to initial model. |
I finished implementing the digital asset template as described in this issue. Since we now actually have a place to store digital assets does it make sense to still index the payload, and query by payload? What would be the equivalent of |
This sounds pretty good. Is it a problem if there's a large number of transactions related to an asset (e.g. do we need to think about pagination / etc)?
It would be nice to be able to filter transactions based on their payload, for example if I wanted to only get a certain type of transaction, but I guess right now we don't really do this (we only allow searches by the |
This would be mostly an api issue I guess |
OK, this can be an option. I'd like to make sure though that we have a similar API for querying a payload by hash (and eventually by IPLD-hash). |
So should I keep the payload uuid and querying by payload? |
I am still not sure if The advantage of carrying the entire asset payload is that it may make validations simpler. |
I am pro linking to the |
Its a secondary index should be O(log(n)) |
done in #680 |
At this point the digital asset looks like this:
The digital asset is defined by the payload which is a generic json object. The hash is added by bigchaindb to allow users to query bigchaindb for the digital asset hash.
This is a simple way to keep track of digital assets on bigchaindb but it is not enough.
We need a generic template for a digital asset so that we can provide more full feature queries on the digital assets.
The text was updated successfully, but these errors were encountered: