Distributing symbol-dapp metadata #12
Replies: 1 comment
|
The point 1 above is an in-depth implementation for DAOs, it doesn't fit as is, as a solution for storage and distribution of metadata about dapps. It is mentioned as a an example of distributed agreements with Symbol features. Adding some notes to illustrate the usage of point 2 above with a library like symbol-taxonomy. The aim is to make it easy enough to read transaction series and identify them by their structure as illustrated here. const taxonomy = new Lib.Taxonomy(
'UBCDigital.NamedAssetCreation',
new Lib.TaxonomyMap([
[0, { type: TType.NAMESPACE_REGISTRATION, required: true }],
[1, { type: TType.MOSAIC_DEFINITION, required: true }],
[2, { type: TType.MOSAIC_SUPPLY_CHANGE, required: false }],
[3, { type: TType.TRANSFER, required: false }],
]),
new Lib.SemanticsMap([
[3, new Lib.OptionalEntry([], 0)]
])
)The "semantics" part is less relevant in this discussion board, it permits to plan repeating transactions in a serie - which in the context of symbol-dapp metadata may not be too relevant to mention in details. In the above source code, we define a taxonomy named Named Asset Creation. For instance, wallet software can use these classes to determine a more precise schema / image of a transaction depending on the type of transactions it contains. This discussion board does not imply that any series of transactions should be used to represent a dapp in symbol-dapp ; It serves as a starter for the discussion around metadata in relation to symbol-dapps listing. |
Uh oh!
There was an error while loading. Please reload this page.
As I have previously introduced in the control panel discussion board, I want to organize a discussion about the storage format and representations of some dapp metadata and the need to streamline the process of managing app listings.
In fact, when speaking of dapps, it has even more value to consider a flexible metadata system in the context of a Projects List / Projects Registry as we want to keep the system updateable in the future, etc.
Following notes and questions:
Do we want a strict and standardized approach for an App Registry, looking at some of the ideas implemented in Governable like the so-called launch agreement. As we probably want to allow more than one person to add projects, it may be interesting to discuss pre-listing agreed upon metadata about dapps.
Another similar but more flexible approach at structuring dapp listing can be to use transaction taxonomies, an idea which is also borrowed by the above Governable and is available as symbol-taxonomy. In this context, a dapp listing would require a specific series of transactions to be issued. Important note here is that symbol-taxonomy does not solve the problem of registry, it solves the problem of metadata about dapps only.
What important metadata is necessary in relation to dapps? Name, URL, Description, [Author?], [Notes?], ...
Do we need some sort of protection for updates to this metadata?
These questions are open for anyone to answer, who wants to contribute in this discussion. 👍
All reactions