NEP-51: Token Standard Requiring Optional Methods

[M-L-A]

See issue: #59

[localhuman]

Do we want an approve event?

[M-L-A]

For previous discussion on optional events, we can refer to the discussion on the original NEP-5 here: #4

In defense of approve, it allows people to transfer on behalf on someone, which people may find useful.

[RavenXce]

This lacks the necessary details for the new (and also existing) methods, so we can't discuss anything. Better to base of the current NEP-5 doc https://github.com/neo-project/proposals/blob/master/nep-5.mediawiki.

[M-L-A]

Have updated to be more in line with current version. Details should be enough to begin discussion. As mentioned, this is the "original" NEP-5 that has been in place (Finalized) since last year, until recently redacted to remove optional methods. Because many projects are currently using these methods (referred to NEP 5.1), and NEP-5 no longer contains those methods for people to find, this NEP becomes necessary.

[canesin]

@RavenXce we have been recommending this implementation due to a needed change in the VM. Please contact me or @localhuman in discord or email, as you feel best, so we clarify the needed changes in the way you call some contracts.

We all understand that a new token standard that just reinstitute a old one is not ideal, but unfortunately a oversight let a new standard proposal at the same time change the at time already finalized NEP5, now we have issues communicating across social channels that can put projects at risk.

@anfn101 this proposal should mark NEP5 status as "replaced" so people don't fall in that mistake.

[M-L-A]

I have added a note to NEP-5 saying something to the tone of that.

[mwherman2000]

@totalvamp @afong @tyler @lllwvlvwlll @erikzhang #58 is non compliant with the current direction that has previously been established for NEPs. It should only contain the incremental merthods. Nothing more. That is was agreed to. #GangOfZion being destructive again.

@erikzhang, to you as the NEP Editor, I recommend against you accepting this NEP.

An NEP-10 compliant solution to this issue can be found in this PR: #60

[mwherman2000]

@RavenXce This continued patterns of destructive community behavior led by @canesin and his Gang of Zion are going to destroy the NEO community.

[mwherman2000]

@totalvamp @afong @tyler @lllwvlvwlll @erikzhang #58 is non compliant with the current direction that has previously been established for NEPs. It should only contain the incremental merthods. Nothing more. That is was agreed to. #GangOfZion being destructive again.

@erikzhang, to you as the NEP Editor, I recommend against you accepting this NEP.

[EdgeDLT]

@erikzhang @mwherman2000

Michael's opposition to #58 is based on a supposed community consensus for a new NEP direction & demand against retroactive changes.

However, this current direction had no community consensus; instead, Michael has justified it based on his own preferences that went largely undiscussed for 30 days.

In addition, the only retroactive changes that have been made so far are Michael's own handiwork, where he retroactively changed a finalized NEP and subsequently re-proposed it under his own name.

I suggest this objection is ignored entirely, and NEP-51 is finalized to supersede NEP-5.

[mwherman2000]

@edgegasm You can read through the community based discussion, acceptance, and finalization of NEP-10 here: #40

[EdgeDLT]

@mwherman2000

On 12th May, you pointed out your concept of removing optional methods from NEPs going forward (an agreeable suggestion).

On 14th May, Erik agreed that there should not be optional methods; just new NEPs for separate methods.

On 17th May, you retroactively removed the existing methods from a finalized NEP (an unacceptable act that has caused much confusion to this date).

In what dimension is a conversation solely between you and Erik over the span of five days a 'community based discussion?' Do you see how ludicrous that is from the perspective of someone that has been noting your own belligerence towards members of CoZ, for supposedly basing decisions on private discussions rather than community involvement? I find it to be wholly unacceptable and hypocritical.

[canesin]

Just to publicly update I talked with @RavenXce in private to clarify. The intention was not to be disrespectful to any member of the broader community but unfortunately not every issue can be discussed in the open as it could damage projects.

Thank you for the comprehension, several members of the community have expressed the need for a forum, in which we are now working to establish, to channel this sometimes more heated (but usually well intention ed) discussions, as more traditional watchers and people not so familiar with open source chaos (to those interested I invite the read of the now classic "The Cathedral and the Bazaar" text: http://www.unterstein.net/su/docs/CathBaz.pdf).

[saltyskip]

#61 or #60 seem to be a better solution as it does not break compatibility of existing projects, and allows us to maintain NEP-5 as the base token standard, with or without extensions

[erikzhang]

#61 or #60 seem to be a better solution as it does not break compatibility of existing projects, and allows us to maintain NEP-5 as the base token standard, with or without extensions

Agree.