You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an alternative to packing variable length strings into multiple tx message fields, e.g. for crowdsales & fixed number asset issuances, we should consider using what I'm calling advisory attributes. These attributes could be (key, value) pairs associated with any uniquely identifiable object - address, tx, currency id, wallet id, etc - stored in an external service.
They are advisory because an application, e.g. Omniwallet, can choose to get the attributes and present them to the user as reliable information. Applications with appropriate authorization can insert/update/delete attributes it uses. This provides users with flexibility and a viable way to administer the data associated with their objects.
For instance, a crowdsale tx message would have a pointer to the service it uses to store its attributes (e.g. name, description, category/sub-category/tags).
Another example is a Visibility attribute that indicates if the associated object should be seen by everyone or just a particular group or users who explicitly choose to see it. TMSC-based currencies could be hidden by default from the general public. This provides a way to maintain the usefulness of the TMSC environment without exposing all that test data to unsuspecting users.
A related, but separate, issue is what business model to use for this service - which could be offered by multiple providers.
Thoughts?
The text was updated successfully, but these errors were encountered:
We had a wide-ranging discussion about how this type of data is intended to be stored. We talked about potential ways to be more flexible with what is stored in the protocol in the future, but most pertinent to Marv's idea above is this description of storing meta-data about an asset, which has been agreed to (at least in principle) by multiple protocols: https://github.com/mastercoin-MSC/spec/blob/master/AssetIssuanceStandard.md
Almost by definition, my notion of advisory attributes are application-level objects and therefore exist and operate independent of the protocol. Omniwallet could use them to add value by providing a more robust, more informative UI/UX.
As an alternative to packing variable length strings into multiple tx message fields, e.g. for crowdsales & fixed number asset issuances, we should consider using what I'm calling advisory attributes. These attributes could be (key, value) pairs associated with any uniquely identifiable object - address, tx, currency id, wallet id, etc - stored in an external service.
They are advisory because an application, e.g. Omniwallet, can choose to get the attributes and present them to the user as reliable information. Applications with appropriate authorization can insert/update/delete attributes it uses. This provides users with flexibility and a viable way to administer the data associated with their objects.
For instance, a crowdsale tx message would have a pointer to the service it uses to store its attributes (e.g. name, description, category/sub-category/tags).
Another example is a Visibility attribute that indicates if the associated object should be seen by everyone or just a particular group or users who explicitly choose to see it. TMSC-based currencies could be hidden by default from the general public. This provides a way to maintain the usefulness of the TMSC environment without exposing all that test data to unsuspecting users.
A related, but separate, issue is what business model to use for this service - which could be offered by multiple providers.
Thoughts?
The text was updated successfully, but these errors were encountered: