Have we lost our path with this specification? I’m actively asking myself this question these days: Why? Because originally, I set up to define a token standard that is “ownership concept” neutral or non-skeuomorphic: And since we’re now defining consensual
mintWithPermission instead of bumping the document’s status to “Review.”
Here’s what I deem immediately useful to the Ethereum community today.
A token standard document that carries as little implicit notion of private property as possible - the goal being to innovate on different kinds of property, e.g., “Harberger Property,” [1,2,3] partial common ownership , and to, e.g., replicate the true nature of bits on the internet [5, 6].
It may not be entirely clear to many, and we probably haven’t done the best job at communicating: But it’s clear that if we had configurable property that isn’t implicitly biased towards, e.g., giving all possible rights to the “owner,” at least in the self-referential digital space many call “web3,” we could attack such interesting problems.
Buterin et al.'s “Decentralized Society” contributes to the Account-bound tokens specification, despite scope-creeping the entire field: It unbundles the concept of ownership as a bucket of interaction rights.
“4.7”, the “Plural Property” section brilliantly identifies the challenges we want to address :
- web3 overemphasized the notion of “transferability” of property, making it impossible to represent simple and ubiquitous property contracts like an apartment lease.
- Traditionally, property rights are defined in Roman tradition as bundles of rights:
- rights to use property (“usus”)
- rights to consume and destroy (“abusus”)
- rights to profit (“fructus”)
- In the real world, someone rarely possesses the “full bucket” of ownership rights.
So to re-iterate on the introduction of this post: I’ve become unsure if we haven’t lost our path here. For E.g. the argument that ABTs discourage key rotation is blatantly false and misguided in the actual context. It’s because truly our intent isn’t to “bind” to accounts: But more to establish a new and unbiased relationship between on-chain property and their subjects (users).
Consider the tables and chairs in a bar. They’re owned by the bar: But then nobody really owns a chair in a bar. You get up (e.g. to the toilet) and then in some social contexts and depending who you are and what peers are with you in the bar - your chair is free when you come back or it isn’t.
This is the type of new ownership experience I’m talking about. E.g. making a differentiation between possessing, squatting, and owning. Using, profiting, transferring, lending, destroying, remixing, etc.
For that, my initial design goal was to strip EIP-721 of all implicit notions of transferability and private property. Yes, we could have used more proper terminology like: “function controllerOf” rather than e.g. “function ownerOf” - but to me, there has always been the question of backward compatibility.
E.g. If we end up creating an entirely original token standard in a vacuum, like EIP-5114 - will there be adoption? Having recently been exposed to the “worse is better” idea , I’m still of the opinion that “worse” and hence backward-compatible, is better.
Still, now that we’ve successfully implemented
function mintWithPermission in the reference implementation and since we’re now making normative statements about a user’s “abusus” rights (namely when it should be burnable), I’m wondering if we’re not getting overly biased again.
Here’s what I want for EIP-4973: I want to create the most minimal and backward compatible version of a token that carries as few implicit skeuomorphic ownership biases from our modern world as possible. I deliberately don’t want to replicate existing ownership experiences.
Then, and even though this may be to the detriment of some EIP editors that e.g. are asking for “censorship-resistant” tech (looking at you @MicahZoltu), I’d want to “finalize” EIP-4973 as a base token such that others can e.g. re-implement new and existing ownership experiences.
So how would we get there? E.g. I’d be happy to remove
function burn again. I’d also be happy to put a statement in saying that this standard shouldn’t be used to bind tokens non-separable to an account. And I wanna frame it where this standard becomes the bare minimum boilerplate standard for an on-chain property.
I hope that sounds reasonable to everyone! How do we get there?