Saving and Displaying Image Onchain for Universal Tokens by zhous · Pull Request #2569 · ethereum/EIPs

zhous · 2020-03-27T17:43:57Z

A set of interfaces to save an SVG image in Ethereum, and to retrieve the image file from Ethereum for universal tokens.
It's an important ERC.

…g-n-Displaying-Image- for-Tokens.md

zhous · 2020-03-30T01:12:09Z

Welcome to the Ethereum Magicians forum to join the discussion:
https://ethereum-magicians.org/t/erc-2569-saving-and-displaying-image-onchain-for-universal-tokens/4167

zhous · 2020-04-05T10:57:26Z

Here shows "Some checks haven’t completed yet". Anybody could tell me how to complete the expected check?

…-2569.md

Fixed some wrong typing.

Fixed two wrong typing.

Fixed a wrong typing.

Fixed "type" from Standard Track to Standards Track.

zhous · 2020-06-10T16:42:13Z

Here's an application based EIP-2569: www.DHonor.io

zhous · 2020-06-10T16:43:27Z

Here's an application based EIP-2569: www.DHonor.io

zhous · 2020-07-17T09:36:59Z

I don't know why this EIP has not been accepted after several pulls. Please give us a help if you know the reason.

Here's an application based EIP-2569: www.DHonor.io
You can find the smart contract (early version) here:
https://github.com/naturaldao/DHonor

Yes, this is a big change. :)

Del.

MicahZoltu · 2020-07-17T11:02:42Z

EIPS/eip-2569.md

+A solution for storage of a fungible token's icon.
+A solution for storage of a non-fungible token's icon.
+A solution for storage of the icon/logo of a DAO's reputation token.


These will render as one paragraph. If you want a bulleted list you need:

Suggested change

A solution for storage of a fungible token's icon.

A solution for storage of a non-fungible token's icon.

A solution for storage of the icon/logo of a DAO's reputation token.

* A solution for storage of a fungible token's icon.

* A solution for storage of a non-fungible token's icon.

* A solution for storage of the icon/logo of a DAO's reputation token.

Changes made and committed

MicahZoltu · 2020-07-17T11:03:16Z

EIPS/eip-2569.md

+Hence we propose a set of interfaces to save an image for a universal token in Ethereum to keep the image permanent and tamper-resistant, and to retrieve an image for a universal token from Ethereum. 
+
+## Definitions
+```tokenId```: for a non-fungible token such as an ERC-721 token or a multi-token such as an ERC-1155 token which has a member "ID" to specify its token type or token index our proposed interface assigns an SVG image's file content to a string variable of the token's contract and  associates the SVG image to this "ID" number. This unique ID is used to access its SVG image in both a "set" operation and a "get" operation. 


Use single backticks around inline code:

`tokenId`: for a non-fungible...

Same issue in a number of places.

Changes made and committed

MicahZoltu · 2020-07-17T11:04:36Z

EIPS/eip-2569.md

+We propose to add three sol files in the existing ERC-721 implementation.
+Here are the details for the proposed sol files.
+
+```


Solidity syntax highlighting will be added to the renderer soon, this will tell the renderer to render using Solidity syntax highlighting.

Suggested change

```

```solidity

Changes made and committed

MicahZoltu · 2020-07-17T11:07:26Z

EIPS/eip-2569.md

+Our proposed interfaces define how a smart contract saves an image for a universal token in Ethereum which keeps the image permanent and tamper-resistant, and how a smart contract retrieves an image from Ethereum for a universal token.  
+
+By calling our proposed interfaces we assume users are accessing an SVG image. 


When authoring an ERC, write it as a specification rather than a suggestion of a specification. Instead of saying "Our proposed interfaces define..." say something like "An EIP-2569 compatible contract MUST have a method with the signature getTokenImageSvg(uint256) view returns (string memory)" or similar.

Changes made and committed

MicahZoltu · 2020-07-17T11:08:06Z

EIPS/eip-2569.md

+Step 1: for a token such as an ERC-721 or ERC-1155 token which has a member variable "ID"  to specify a token type or index and a member variable string to keep an (SVG) image associated with the "ID", retrieve the (SVG) image from Ethereum by calling our proposed "get" interface with the token's ID; 
+for a token which doesn't have a member variable "ID" to specify a token type of index but has a member variable string to keep an (SVG) image, retrieve the (SVG) image from Ethereum by calling our proposed "get" without an "ID". 


Consider defining the interface in the specification section as a Solidity interface, and include notes on any required behavior of the functions.

I am not sure if I get your point. Would you please elaborate this a little bit? Did you mean I move the " setTokenImageSvg: for an ERC-721 .....getTokenImageSvg: for an ERC-721 ......" from the "Definitions" section to here , after "Step 2:......" and before "Step 1: for a token......" ?

A good specification may look something like this:

Implementations of this standard MUST implement the following interface:

interface Erc2569 { function getTokenImageSvg(uint256 id) returns (string memory); function setTokenImageSvg(string data) returns (uint256 id); }

If you pass the id returned by setTokenImageSvg into getTokenImageSvg then getTokenImageSvg MUST return the same value that setTokenImageSvg was provided.

I got your point after I reviewed EIP-1. Changes made and committed

MicahZoltu

I left some initial feedback, and before being merged as final some changes should be made to this EIP. However, everything that is necessary for a draft merge is here so this is good to merge.

axic · 2020-07-17T16:29:52Z

EIPS/eip-2569.md

+
+Hence we propose a set of interfaces to save an image for a universal token in Ethereum to keep the image permanent and tamper-resistant, and to retrieve an image for a universal token from Ethereum. 
+
+## Definitions


This seems to be not in line with the sections set out by EIP-1. Perhaps EIP-1 should be improved?

Ah, good catch. This should be a subsection of Specification rather than its own section.

I got your point after I reviewed EIP-1. I made a relatively big change by merging the original "definition" section to the "specification" section. Changes made and committed.

A set of interfaces to save an SVG image in Ethereum, and to retrieve the image file from Ethereum for universal tokens. It's an important ERC.

zhous added 2 commits March 28, 2020 01:38

Create eip-Saving-n-Displaying-Image- for-Tokens.md

3a0759c

Rename eip-Saving-n-Displaying-Image- for-Tokens.md to EIPS/eip-Savin…

b4b560c

…g-n-Displaying-Image- for-Tokens.md

Update eip-Saving-n-Displaying-Image- for-Tokens.md

26d1cbc

zhous changed the title ~~ERC for Saving and Displaying Image Onchain for Universal Tokens~~ EIP for Saving and Displaying Image Onchain for Universal Tokens Apr 11, 2020

zhous changed the title ~~EIP for Saving and Displaying Image Onchain for Universal Tokens~~ Saving and Displaying Image Onchain for Universal Tokens Apr 11, 2020

zhous added 5 commits May 31, 2020 18:57

Update and rename eip-Saving-n-Displaying-Image- for-Tokens.md to eip…

42d0457

…-2569.md

Update eip-2569.md

4a214d2

Fixed some wrong typing.

Update eip-2569.md

3d79664

Fixed two wrong typing.

Update eip-2569.md

912b0c6

Fixed a wrong typing.

Update eip-2569.md

b993da4

Fixed "type" from Standard Track to Standards Track.

zhous added 3 commits July 17, 2020 18:24

Create Improved Mechanism for ETH 2.0 Staking.md

f6d2968

Yes, this is a big change. :)

Update Improved Mechanism for ETH 2.0 Staking.md

a9630e2

Delete Improved Mechanism for ETH 2.0 Staking.md

dbcc12a

Del.

MicahZoltu reviewed Jul 17, 2020

View reviewed changes

MicahZoltu approved these changes Jul 17, 2020

View reviewed changes

MicahZoltu merged commit 0259736 into ethereum:master Jul 17, 2020

axic reviewed Jul 17, 2020

View reviewed changes

ethereum deleted a comment Jul 21, 2020

		Our proposed interfaces define how a smart contract saves an image for a universal token in Ethereum which keeps the image permanent and tamper-resistant, and how a smart contract retrieves an image from Ethereum for a universal token.

		By calling our proposed interfaces we assume users are accessing an SVG image.

		Step 1: for a token such as an ERC-721 or ERC-1155 token which has a member variable "ID" to specify a token type or index and a member variable string to keep an (SVG) image associated with the "ID", retrieve the (SVG) image from Ethereum by calling our proposed "get" interface with the token's ID;
		for a token which doesn't have a member variable "ID" to specify a token type of index but has a member variable string to keep an (SVG) image, retrieve the (SVG) image from Ethereum by calling our proposed "get" without an "ID".


		Hence we propose a set of interfaces to save an image for a universal token in Ethereum to keep the image permanent and tamper-resistant, and to retrieve an image for a universal token from Ethereum.

		## Definitions

Conversation

zhous commented Mar 27, 2020

Uh oh!

zhous commented Mar 30, 2020

Uh oh!

zhous commented Apr 5, 2020

Uh oh!

zhous commented Jun 10, 2020

Uh oh!

zhous commented Jun 10, 2020

Uh oh!

zhous commented Jul 17, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

A good specification may look something like this:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MicahZoltu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants