FR: add asset category tags, allow someone from product to manually add icons and add/remove such tags

[alessandro-saglimbeni]

Some assets registered on the asset registry are more relevant than others for end users. In the wallets UI and in the explorer assets section we already have several test issuances clogging the view with unrelevant asssets.

We need a way to flag a subset of the currently registered assets, as "featured_assets", so that they can be displayed in foreground on GUI clients.

Going forward, to scale a bit the operations of flagging such assets in the registry as more issuers will want their assets to be featured, we'd need someone from product to be able to:

1. add/remove a new registered asset to the featured assets list
2. add/remove/change icons for such new assets (virtually all these assets will have icons)

[allenpiscitello]

Ideally the featured list would not be universal but capable of being optimized by each application. It also would be useful if we could tag one or more categories on an asset as well (such as security token, stablecoin, etc...) that applications could utilize. This would allow the most flexible behavior for future use.

Ideally the API would allow admin users to do the following:

• add or remove a tag on any asset

The API would allow any client to do the following:

• get the list of categories that have been defined
• get the list of assets that fall into any specific category

The tags can also be key-value pairs, where an asset can be the data. We could also add other information such as a website or other information.

[alessandro-saglimbeni]

Few Questions from @shesek

1. How is tag management going to work? The issue mentions it as future work, but having me in the middle whenever an update is needed is not going to work... we should figure this out sooner rather than later.

   1a. If tags are implemented as part of the assets db git (like icons), updating them would require access to the pgp signing keys. We'll need to figure out who can access this, and whether the users sign directly or have the API server do this for them.

   1b. Is there some existing management backend and/or authentication system that this should integrate with, or will it be a standalone system with its own ACL?

2. Should issuers authorize the tags their assets are associated with, in the same way they commit the issuance to the name/precision/website? Or perhaps with a signature from their issuer_pubkey?

3. Do we want to add tags to the block explorer GUI? Show them in the asset list, add an option to filter by them, etc?

4. If we're working on a new API and management UI for tags, we could revamp icons to use the same foundation while at it. Another icons-related improvement to consider is using binary serialization for instead of base64, the icons.json file is starting to get pretty big and is going to grow a lot more it seems.

5. I didn't quite understand what was meant by using tags as key-value pairs. Some examples of the use-cases this is meant to enable would be helpful.

[allenpiscitello]

Few Questions from @shesek

1. How is tag management going to work? The issue mentions it as future work, but having me in the middle whenever an update is needed is not going to work... we should figure this out sooner rather than later.

I'm not sure I understand the question.

1a. If tags are implemented as part of the assets db git (like icons), updating them would require access to the pgp signing keys. We'll need to figure out who can access this, and whether the users sign directly or have the API server do this for them.

This should be an admin feature of the registry. Users should not be able to set their own tags.

1b. Is there some existing management backend and/or authentication system that this should integrate with, or will it be a standalone system with its own ACL?

If we can reuse existing authentication services like devops already has in place for internal use we should use it.

2. Should issuers authorize the tags their assets are associated with, in the same way they commit the issuance to the name/precision/website? Or perhaps with a signature from their issuer_pubkey?

No need for issuers to be involved.

3. Do we want to add tags to the block explorer GUI? Show them in the asset list, add an option to filter by them, etc?

Not yet. There are plans to modify the block explorer already, we can incorporate it in new plans, no sense in doing it before then.

4. If we're working on a new API and management UI for tags, we could revamp icons to use the same foundation while at it. Another icons-related improvement to consider is using binary serialization for instead of base64, the icons.json file is starting to get pretty big and is going to grow a lot more it seems.

That would be good to do, part of the motivation.

5. I didn't quite understand what was meant by using tags as key-value pairs. Some examples of the use-cases this is meant to enable would be helpful.

What I mean is there may be some tag, such as "icon" and some value which is the actual binary icon. Or another tag which is "asset category" and we tag it as "stablecoin" or "security token". No tags are required for any asset, but can be utilized by clients such as the explorer or wallets.

An example of how to use this is like what you described above - I may want to have the explorer filter out NFTs by default since there are lots of them. Or I may want to view only stablecoins. The main use case in mind is to support having something like a wallet show certain assets with higher priority than others, since they are the most widely used.

[shesek]

I'm not sure I understand the question.

The question was basically whether we're going to build a GUI for tag management that someone from product could use, or have someone do this via the command line for now.

For the icons we currently have, every update has to go through me, which is obviously not scalable. You Alessandro mentioned that "Going forward ... someone from product to be able to ..." -- which I understood as a future work and not something that we'll have initially. But having me in the middle of every update is not a solution either. So we'll need to figure this out. :)

Users should not be able to set their own tags.

Just to clarify, what I meant by "user" in this context is the administrator working on behalf of Blockstream, not the end-user. Are we expecting the administrator to hold the signing keys locally, or delegate this responsibility to a server?

If we can reuse existing authentication services like devops already has in place for internal use we should use it.

Who can give me more detail on how that works? I'm not familiar with these systems.

There are plans to modify the block explorer already, we can incorporate it in new plans

Which plans?

What I mean is there may be some tag, such as "icon" and some value which is the actual binary icon. Or another tag which is "asset category" and we tag it as "stablecoin" or "security token".

I'm not sure having an arbitrary key-value map is worth the extra complexity. I would personally go with a simple list of tags (a set of arbitrary strings), and have a specialized (and typed/validated) implementation for fields that require a value like the icon.

[allenpiscitello]

The question was basically whether we're going to build a GUI for tag management that someone from product could use, or have someone do this via the command line for now.

No need for GUI. Willing to have a dirty way to do this. Ideally not just needing you specifically, but an API with an access key or something to allow certain people to do it.

Just to clarify, what I meant by "user" in this context is the administrator working on behalf of Blockstream, not the end-user. Are we expecting the administrator to hold the signing keys locally, or delegate this responsibility to a server?

User in this case is issuer. Should not be able to add to these keys.

Who can give me more detail on how that works? I'm not familiar with these systems.

I think keep it simple for now, don't worry about this.

I'm not sure having an arbitrary key-value map is worth the extra complexity. I would personally go with a simple list of tags (a set of arbitrary strings), and have a specialized (and typed/validated) implementation for fields that require a value like the icon.

As long as its possible to add more later without too much effort, that's fine.

[wintercooled]

I think this request fits into this issue:

It would be great to have a way for users to flag an asset they have issued as having a default logo they have already provided.

Possibly an approach is to add a 'default_logo' field to the registry. So if I own domain mydomianhere.com and I issue 3 assets:

Asset 1 first and then register the logo generic.png against the asset id for Blockstream to add to the infra registry for icons.
Asset 2 and enter default_logo as generic.png
Asset 3 and enter default_logo as generic.png

For assets 2 and 3 could we look to see if, for the same domain, we have a file named generic.png and auto-add that to assets 2 and 3 if so.

Implementation aside - we require a way for an issuer to issue assets and have them inherit the icon from one that already exists for the issuer.