EIP-999 widely compatible status

[naumenkogs]

I think our EIP should introduce a number statuses, for example:
0x1: not authenticated
0x2: timing (daily?) limit reached
0x4: temporary frozen account
...
0x8: specific application-related status

This will make wallets integration much easier.

Although I can also imagine when business rules require a lot of super-specific statuses.

[naumenkogs]

Another idea is to let validator define getStatusInfo(statusId) which returns hardcoded explanation string. Or not hardcoded, but updatable by token regulator? Sounds a bit crazy.

[carchrae]

to keep to the crazy of EIP/ERC numbering, we can make a repo of contract status codes. then return the code that corresponds to an issue that defines it. eg, 0x2 -> #2 (message: "EIP-999 widely compatible status")

[carchrae]

would allow updating of text and also allow community to add their own codes

[naumenkogs]

@carchrae does it mean that app should query GitHub repo each time it gets a status? (well, or cache it, not much different)

I think this approach potentially could add more politics. We will have a hardfork/softfork fights, but on github, not on the blockchain. If one party asks for new status, and other party thinks it's not a good one.
In addition, Github central point of failure/trust.

I think even though getStatusInfo() approach is not beautiful, it is more robust.

[carchrae]

i just proposed as a simple mechanism for publishing code text without having to deploy a contract to do so. i fully agree with all the shortcomings you mention.

an alternative, much like the ENS, is to have a validator status contract on the blockchain that lets people add a new status code to the list in that contract. maybe charge a nominal (nom nom nom) fee to avoid spammers adding lots of junk messages.

[carchrae]

both of my proposals were attempts to create a shared/normalised version of status codes rather than having each contract maintain the same or similar text for each code. (or worse, different meanings for each code)

[naumenkogs]

Probably we want something like TokenRegistry but for statuses.

I this case there are 2 ways to interpret statuses:

1. Wallets have to call this contract explicitly to ask for description of a particular status
2. We can call this contract from Validator and return a string explanation in addition to status code.