We’ve spent the last month deep in design in collaboration with many talented teams. We’ve received an incredible amount of feedback from the EOS development community. And all of this has rolled up into our latest version of the dGoods v0.2 spec available on Github.
In parallel, we’ve been hard at work on the implementation side of things. And this week, we are excited to announce the release of our closed Alpha for the dGoods Smart Contract implementation. The first teams to have access are the teams involved in the dGoods initiative. They will all be reviewing, integrating, and pressure testing the implementation to shake out any issues ahead of a public release.
Now, on to a few hot topics from the past few weeks…
Asset Type JSON/Metadata
The concept of “True Ownership” is synonymous with Blockchain technology. Because of immutability, for the first time ever, we can have true ownership over digital assets. So the question we get asked a lot is, why put data in a JSON file that’s not part of the token? Doesn’t that break immutability?
When we talk about a digital goods economy, we are talking about a wide variety of asset types, such as 3D game assets, 2D art assets, music files, concert tickets, and many more. For dGoods to be a meaningful standard, it needs to be flexible enough to handle any asset type thrown at it. This is where we see other standards missing the mark, and why we chose to build dGoods.
To achieve this flexibility, we developed the concept of “asset types”. Each asset type comes with it’s own set of data requirements that we store in a JSON file. Let’s compare JSON files for 2 different asset types.
3D Game Asset
[{
// Required Fields
"lang": string; two-letter code specified in the ISO 639-1 language standard
"name": string; identifies the asset the token represents
"description": string; short description of the asset the token represents
"imageSmall": URI pointing to image resource size 150 x 150
"imageLarge": URI pointing to image resource size 1024 x 1024
"3drender": URI pointing to js webgl for rendering 3d object
"details": Key Value pairs to render in a detail view, could be things like {"strength": 5}
// Optional Fields
"authenticityImage": URI pointing to resource with mime type image representing certificate of authenticity
}]Ticket Asset
[{
// Required Fields
"lang": string; two-letter code specified in the ISO 639-1 language standard
"name": string; identifies the event the ticket is for
"description": string; short description of the event the ticket is for
"location": string; name of the location where the event is being held
"address": string; address of the location where the event is being held
"date": Unix time; starting date of the event
"time": Unix time; starting time of the event
"imageSmall": URI pointing to image resource size 150 x 150
"imageLarge": URI pointing to image resource size 1024 x 1024
"details": Key Value pairs to render in a detail view, could be things like {"openingAct": "Nickelback"}
// Optional Fields
"authenticityImage": URI pointing to resource with mime type image representing certificate of authenticity
"duration": string; length of time the event lasts for
"row": string; row where seat is located
"seat": string; seat number or GA for General Admission
}]Naturally, each asset type has very different requirements. Attempting to capture all these requirements in a one-size-fits-all approach would leave us with a standard that lacks the specificity needed.
With our “asset type” approach, developers can pick the type that’s relevant to their product. They are also free to create new types that might require a very specialized scope. And in doing so, dGoods is able to support an incredibly wide variety of digital asset types and usecases.
Back to the question at hand. Why put data in a JSON file that’s not part of the token?
The simple answer is that we kept it out of the token to save on RAM. While we’re not actively optimizing yet, we do weigh RAM usage into our design decisions. Strings are very expensive; and if we rolled all of that data into the token, the resulting smart contracts would be enormous, and the RAM cost would be prohibitively (and arguably needlessly) high.
But, doesn’t this break immutability?
Not at all. We do not prescribe where you put those asset type JSON files. To make them immutable, you simply store them on IPFS. IPFS sends you a hash of the file as a key for the purpose of looking up the JSON. If you put that hash in your token, then you have immutability.
With dGoods, we try to strike a balance between being prescribed versus providing flexibility. In this case, we wanted to give developers the option. If immutability is important to you, dGoods supports it.
Early Adopters
Another question we get a lot is: how can our team join the dGoods initiative?
dGoods is a free and open source standard aimed at supporting a diverse development community. As a result, if your product has interesting and unique digital asset usecases, then we want to hear from you. And we welcome you to join the dGoods initiative.
If your team is interested in being an early adopter and integrating with dGoods, get in touch with us; either through our website at dGoods.org or via telegram at https://t.me/dGoods_EOS
The dGoods standard is supported by a growing group of incredibly talented teams: Mythical Games, EOS Lynx, Scatter, Token Pocket, pixEOS, Cypherglass, Bloks.io, Math Wallet, Infiniverse, Greymass, MEET.ONE, ITAM Games, and NOVA Wallet.
