dGoods dev update — mar 5.19
Just a few short weeks ago, we publicly released the dGoods v0.1 spec. Our goal was to give the dev community an early look at our design thinking for the dGood standard. With dGoods, we’re aiming to provide a robust and comprehensive standard that supports a diverse range of development requirements. As a result, we wanted to give the dev community a chance to pressure test our thinking, our designs, and provide valuable, expert feedback.
In short, the response from the development community has been tremendous. We’ve had an outpouring of feedback and suggestions that have been critical to this step in our roadmap. So first off, we want to say a big THANK YOU to the EOS dev community for jumping in and supporting the dGoods initiative.
While the blockchain market is new and relatively small today, we don’t see it staying that way; not in the slightest. As blockchain continues to penetrate mass market, we will see a large booming economy emerge that is entirely centered around digital assets. What we see ahead is a world where hundreds of millions of digital assets are created, bought, and sold. It’s this vision that drives a lot of our design decisions for dGoods, and we wanted to be transparent about it.
While dGoods is free and open source, the design is primarily focused on commercial use cases like mass market gaming, ticket sales, the music industry, etc. This is something that heavily influences our decision making as we go through all the feedback we’ve received from the dev community.
From our perspective, while dGoods needs to solve the problems we face now, it also has to be designed to handle scale, and an incredibly fast growing market.
With that out of the way, let’s move onto some of the hot topics of the last few weeks.
The speculative RAM market on EOS has been a consistent challenge for the EOS development community. So it’s understandable that a large discussion point with dGoods has been around how we manage RAM correctly.
The short answer is, yes, there are optimization opportunities, but no, we’re not going to address them all now. Our plan is to first figure out what all the features are that dGoods needs to support. Then once that’s done, we will focus on optimizations. For those wondering about RAM efficiency, we hear you, and we’ll get to it as soon as we have a solid spec designed for dGoods.
Secondary Indices for Categories
There have been many debates around whether we include secondary indices for categories or not. While some believe we shouldn’t include them to save on RAM, others view it as critical to efficiently managing large volumes of digital goods. This is one of those decisions that has a trade off whichever way we go. But if we are aimed at providing a meaningful standard that will support hundreds of millions of digital assets, then the path forward becomes clear.
Here are two cases where providing this kind of flexibility can be key:
- A game aimed at mass market where we expect hundreds of thousands of players, if not millions. A single game reaching this kind of success will need flexible ways to easily organize an extremely large volume assets, and we expect to see many games with this kind of success.
- An eBay-like digital asset marketplace will want to easily display and organize assets from every game and app available. They’ll want to provide a seamless user experience where their customers can easily find the things they’re looking for. As a game developer, these marketplaces play a key role in providing you with liquidity.
In the very near future, where blockchain has achieved mass adoption, we believe having more flexibility with categorization is better than having less. And the trade-offs are worth it.
There has been a lot of talk across the industry regarding Fungible and Non-Fungible Tokens (NFTs). NFTs have been central to inspiring us with the possibilities that blockchain can offer.
As we dove into the dGoods design, we found a new paradigm that we are calling Semi-Fungible Tokens (SFTs). We see SFTs playing a crucial role and being the primary use case for tokenized digital assets; therefore, we felt it was important to define it separately from NFTs and Fungibles.
Here are a few use cases to help explain SFTs:
- You are selling 200 tickets to a concert. All the tickets are the same, but they have a different seat #.
- Your game has a limited set of 1000 digital swords that look and function exactly the same, except they all have a different serial # from 1–1000. Most players might not care about the serial #; a sword is a sword. But a few hardcore players might attribute varying value based on the serial # attached to the asset. For example, 1 of 1000 might be worth more to someone versus 200 of 1000.
Yes, these are technically NFTs, but to the end user, they aren’t being advertised as 1 of a kind, the only one in the world, or 100% unique! Instead, for these types of use cases, we’re using the term Semi-Fungible Token.
We see a future where SFTs will be the dominant use case in the emerging digital goods economy; and as a result, we are making SFTs a core part of the dGoods standard. We’ll spend a lot more time talking about this soon.
With the draft v0.1 spec out in the public, we are continuing to gather feedback and refine the spec. We welcome any input you might have.
We are continuing to add more features to the spec which we’ll announce as we go.
And finally, we’re working on the first pass of the smart contract code for dGoods. We will be aiming to release an Alpha version very soon. It will be available first to only our collaborating teams and early adopters. So if you’re interested in being part of either of those groups, don’t hesitate to reach out to us on Telegram: https://t.me/dGoods_EOS
A big thank you to all the teams behind the dGoods standard: Mythical Games, EOS Lynx, Scatter, Token Pocket, pixEOS, Cypherglass, Bloks.io, Math Wallet, Infiniverse, Greymass, MEET.ONE, ITAM Games, and NOVA Wallet