I’m trying to understand the “roles” defined in the EIP712 structure Aggreement(active,passive)
If A want to create a “give” request to B, he first asks B to sign Aggreement(active=A, passive=B), but then A could issue a “take” instead of “give”.
Instead, I think the agreement should be TransferAgreement(from,to,token). That is, the signature should describe the token movement direction, not the user issuing the transaction.
The signer of this structure depends on the inactive side of the transaction (you could argue that actually both sides sign, as sending this transaction requires the “giver” or “taker” to sign it.)
In another note, you could support meta-transactions by having the signatures of both “giver” and “taker”:
e.g. move(address giver, address taker, bytes giverSig, bytes takerSig, string tokenURI)
@dror, thanks for your comment it’s all relevant and valid. I’ll respond to it in more detail in the future.
How EIP-4973 Account-bound tokens could drive curation in the music NFT industry
In the following post, I want to highlight a problem we’ve encountered in the music NFT industry. As a quick aside, these days, I work as a tech lead on https://neume.network, and we’re essentially building a socially scalable data pipeline to extract and augment on-chain data. For all of the music NFTs hosted on Ethereum, in contrast to the Graph Protocol, at Neume, we’re not trying to make contract storage data more accessible. Instead, we want to build a list of music NFTs that users can listen to via an app like Spotify.
A quick disclaimer: My work on Neume Network is financed by hifilabs.co, and they’re creating https://musicos.xyz, an audio player built on the music NFT data that we’re indexing with the Neume Network software.
But truly, this was never our intention: But I was caught off guard by the user feedback, and so this post is somewhat a reflection on what happened and led to problematic emergent effects.
See, for https://musicos.xyz, as it’s an audio player like Spotify, we naturally wanted to index the best possible and probably also most popular platforms. So when starting the project, we intuitively went for the popular ones - those that we knew provided nicely sounding songs.
And when they launched musicos a few days ago, I suddenly found myself confronted with the following user feedback questioning the credible neutrality of the Neume Network indexer. Here’s what users said:
So let us unpack what is being discussed here. In my own words: Guspy, Supersigil, and thepark.eth are all asking for their tracks to be listed on the music-os app we had just released. And they did so by pointing out an interesting dynamic in the music NFT space. guspy mentions that the music they had minted through a custom contract on https://www.manifold.xyz/ isn’t showing up on music-os. They’re saying that having their contract being indexed is posing a challenge: And that instead, had they minted their song on Catalog, Sound, or MintSongs, then it probably would have made it into music-os.
Extrapolating their statements here, too, we can reason that any track that gets lots of exposure through a music player may fare better on first and secondary sales. So potentially, for guspy et al., having their songs exposed on music-os can potentially mean an improvement in income. Or anyways that their songs are listened to at all.
In the post by Supersigil below, they help double down on the argument, namely that artists need to be given the option to “be their own platforms” and that hence the favoritism of Neume Network to implement the big music NFT platforms first is a challenge to all artists hosting independent contracts.
There’s also an interesting insight in their posts: Namely that the platforms are curated by genre or type of music. And so, despite some artists’ work having the potential for popularity - they may never end up being exposed to larger audiences given the moderation policies of the respective platforms.
Experimenting with Music NFTs
And there’s actually more context to unpack here: Historically, the big platforms like sound.xyz and catalog.works have been heavily curated - or at least that’s how their music sounds to my ears. I can back this up with visitor data, too, as I had played around with a minimalist website that allowed users to listen to sound.xyz and catalog.work’s songs on a website I called https://tracks.lol.
For a brief moment in time after its release, it gathered a notable listener community and was widely shared on Twitter despite the website having any meaningful web design or other functionality. Below’s a screenshot of the page, or you can see it yourself by visiting: https://tracks.lol:
And what my intention had been here is that I had been experimenting in the true sense, and so I carefully controlled the website’s utility to test the music’s popularity.
As you can see, there weren’t any fancy animations - no marketing website to convert users. All there was a single page that played music from sound.xyz and catalog - with the hypothesis being that people would still like this arguably “shitty” website because it played nice music! And oh boy, did they! Here’s a screenshot of my plausible.io tracker, and you can access the numbers yourself by clicking the following link Plausible · tracks.lol
So clearly, it couldn’t have been my sick web design skills or the amazing utility you got from the website’s controls. The reason people briefly shared the page was the music on it was nice.
And let me reassure you, this is also the qualitative feedback I’m gathering from anyone that I manage to expose to sound.xyz and catalog’s tracks! They’re doing a great job in properly curating NFTs to seed the initial consumption network.
And I’m capable of negating that argument, too: Where if you’d built a website that focuses on listing the highest grossing NFT sales on OpenSea, you’d end up not with an aesthetically pleasing newsfeed of NFTs: You’d just get a seemingly random list of Bored Apes, and, in fact, I can prove this to you right away by asking you to visit: Top sales | Context where at the time of writing, the four latest updates in the feed are apes - boring!
But despite curation platforms like sound.xyz and catalog.works accelerating the music NFT industry in the first place, there is a sort of tragic story in this utility provision too, which are the problems pointed out today by thepark.eth, Supersigil, and guspy: Namely, that while curation can excel an artist’s work, it’s also gatekeeping other artists from putting their latest tracks in front of a larger audience. And it discriminates against genres.
In the end: This capability to curate who and what song is gonna be popular comes with a lot of influence, and so: curating, gatekeeping, and/or censoring: Those actions create power structures. Structures that are actively being misused today to seek further self-serving profit.
The fact that those who moderate do so opaquely - with non-consistent guideline interpretation. With potential implicit bias and little public accountability. Governance, as we say in the crypto-sphere, doesn’t seem to be a meaningful keyword.
But OK - what has any of this to do with EIP-4973 and Account-bound tokens? And yes, at least for now, this post has been overfocusing on the problems and not a solution. It’s a principle I work by called “problem-driven development,” and so now, since we’re sufficiently informed, let’s discuss a potential solution.
Thesis first: “Broad commoditization of infrastructure creates newfound equity”
A thesis I have been pursuing with https://rugpullindex.com, the Neume Network, and now also with Account-bound tokens is how infrastructure provision and making it broadly available to any players in a market can produce a wealth-transfer or generally broader equity. With rugpullindex.com I’ve seen this because others built mobile apps based on my API. With Neume Network, we’ll see this effect emerge as developers are capable today of replicating the https://musicos.xyz experience by using our GPL-3 licensed Neume Network crawler or by simply using our data set at neume-network/data.
As pioneered by Sabre and Amadeus in the airline industry, by commoditizing and co-owning the infrastructure - namely the database that holds all future flights - similarly, we’re able to create competition around the supply of good music NFT metadata offerings: And we postpone what Ben Thompson calls “Aggregation Theory,” an effect of profit-seeking and monopolizing a market’s supply side.
But enough with the theory: Simply put, what the above means is that EIP-4973 can make the data structure for consensual music curation available to anyone with a wallet using account-bound tokens to express agreements on-chain. And it simultaneously removes relevancy from the big curation platforms like sound.xyz and catalog. So how would it work?
Consent-based Music Curation using Account-bound tokens
See EIP-4973 is a truly peer-to-peer contract in the sense that no single individual or group has different privileges when interacting with the contract. This isn’t true for many contracts, by the way! Most EIP-20 contracts implement permissioned minting, and so do EIP-721 tokens to preserve artificial scarcity.
But EIP-4973 doesn’t implement such hierarchical logic. It’s flat, and instead, for two addresses (EOAs or contracts), if both addresses provide a valid signed message, then an Agreement over a document hosted at string tokenURI may be etched to the chain.
That storing of a consensual agreement can be done two ways - and surprisingly, it’s NOT done through minting, but instead, we implement two bulky functions called function give and function take. Here’s a drawing of how they work.
from can give an ABT to to and is the sender of the transaction.
to can take an ABT from from and is the transaction’s sender.
I’m linking the reference implementation code snippets below in case you want to dive deeper. But for continuing to read this post, it’s not necessary to understand them deeply.
To clarify: The result of both of these functions is that a new token is minted to address to: And their validation method is similar. Namely, both need two valid signatures of string tokenURI from address from and address to. Their difference is who represents the active part on-chain and who just provides a signature. The figure below outlines the difference in both cases:
For function give(address to, ...), address from must wait for address to's signature to arrive and can only then send the transaction on-chain to cement their agreement. Whereas in the case of function take(address from, ...), address to takes the ABT from address from and hence has to include their signature.
So these primitive functions have been deliberately called “give” and “take.” It’s because, in the World of Warcraft universe, where Soulbound items were first implemented and since this in-game metaphor has become EIP-4973’s baseline, players could also “give” and “take” certain items.
In case a player completed a quest, the NPC often “gave” the player items: But it was at the player’s discretion to preserve them in their bag. Likewise, although this challenges the “consent” metaphor, players could “take” items from a dragon or firelord they had slain earlier.
On-chain consent agreements for music NFT curation
So going back to our initial story of how EIP-4973 Account-bound tokens can help the music NFT industry’s curation problem, here’s what I’d like to say:
Right now: It is a one-way street where artists are practically dire for having their tracks minted on popular curation websites. It’s also a problem as the infrastructure for curation is proprietized - so assuming this moat strengthens further over time: It’ll also negatively raise the bar for unestablished artists to publish.
And we must acknowledge that the above-mentioned dynamic won’t go away overnight too. Instead, given our thesis that commoditizing infrastructure can break markets, I think by using EIP-4973 for consensual on-chain curation of music NFT playlists, I think we could achieve more equitable outcomes if more people could become curators.
It is because standard adoption can initially level the playing field of access to attention. Instead of one website being able to promote their tracks and build potentially proprietary solutions, with EIP-4973, we have a primitive that can express bidirectional agreements between curator and artist.
And sure, we could implement contracts where the curator is in charge of administering the listing. But I think that’s an unwise design, given how reproducible content is curated nowadays. Rather, if the authors and the curators mutually agreed on which tracks end up on what lists - I believe this would carry a higher signal when compared to curator-only feeds.
Additionally, by making the curation infrastructure usable by anyone, a greater degree of competition would improve outcomes and reduce the risk of a single party monopolizing.
Wide-scale adoption of this standard would incentivize indexers and other NFT infrastructure providers to implement its interfaces and make the on-chain data symbolizing publicly-visible agreements broadly available.
If you’re deep in the traditional music industry, you probably know how complicated moral rights can get - and here’s a standard that can potentially solve some of this domain’s questions.
So how would this end up looking? Here’s a sketch:
Similar to https://presentmaterial.xyz’s on-chain curation contract, we should come up with a standard agreement JSON template that the curator and artist can collaboratively sign.
The active part in the agreement (who sends the transaction), would then upload the agreement on a network like IPFS, where the JSON’s context-addressability is guaranteed
They’d send over the agreement to the passive party where it gets signed
Once the signature is back at the active part: They can start etching the agreement on-chain. The smart contract and the Ethereum consensus algorithm check the validity of both parties’ signatures, and if they’re valid, the Account-bound token gets emitted, and an event Transfer(address from, address to, uint256 tokenId) is sent.
Now, it’d be great if, additionally, a “curation release signal” could be emitted that clarifies to music NFT indexers when a new song is released. And that could happen after having reached an agreement between the artist and curator.
Remember, minting an NFT is not laying claim to license your work permissively. An artist retains all copyright, and so technically speaking, unless there’s a specific agreement put in place, reproduction of a music NFT is simply a legal grey zone many seem to tolerate for now.
Hence this whole essay on chainifying two parties’ agreement - Since the string tokenURI's content would detail the conditions under which curator and artist have decided to collaborate to release the NFT.
For the curator, there’s no clarity on whether they’re allowed to reproduce the artist’s song on their site. And for the artist, there’s transparency regarding what can be done with their work and what can’t.
So that’s it, that’s why EIP-4973 Account-bound tokens could drive curation in the music NFT industry. Anyways, this is a very long post, so I’d now like to start concluding it.
How EIP-4973 can be used for music NFT curation
In this post, we’re documenting the problems of the emerging music NFT industry and how the aggregation of music NFT supply creates suboptimal outcomes for independent artists.
Our thesis is that well-curated media content is useful to anyone but that it can also easily lead to power abuse.
To combat this potential negativity and to “break the curation market,” our thesis is that the commoditization of infrastructure can help level the playing field. And specifically, it means that by mainstreaming consensual content curation, a new ecosystem of dApps could emerge that serves curators and artists alike.
EIP-4973 Account-bound tokens are the basis for expressing consensual agreements on-chain. Their lack of permissions in minting makes them ideal to be applied broadly and in a true peer to peer fashion.
we should further diverge from the classic Soulbound tokens meme and pave our own path
With, e.g. using EIP-4973 for consensual on-chain agreements, I think we have a valid and extendable use case
Areas where we’d need more improvement: An agreement can either be directional or most of the time, an agreement reflects the will of a minimum of two parties. Hence it’d make more sense to emit a token to both parties in an agreement rather than just one. Similar to how when a contract is signed, both parties get a copy
Excellent write-up. Hopefully Web3 can also solve the issue where Web2 tech platform owners make curators work for them for nothing, whilst they accumulate the value created.
EIP-4973 allows for mutually agreed, peer-to-peer minting - without implicitly determined power distributions
You can make a surprising discovery about EIP-20 and EIP-721’s functioning when you notice that they’re entirely unusable without at least once conceptually invoking a minting functionality. Now, whether a user does it via calling the often provisioned function _mint(...) function or by manually setting account balances via the constructor doesn’t matter. And surprisingly, minting by itself is suspiciously absent from the Ethereum Improvement standardization Process. Isn’t this odd: No EIP-20 token or EIP-721 contract would be functional today hadn’t at least one of their implementers decided to implement and call a non-standardized functionality and minted tokens to some addresses. And sadly, this comes with the obvious consequence of power aggregation and distribution unfairness. However, for the sake of this post and to make it a little more emotional, I want to rather say: leaving the minting function of EIP-20 and EIP-721 non-canonicalized is a failure in implementing a truly peer-to-peer system. What do I mean by that?
Building peer-to-peer systems
If you’ve ever built networked systems, you probably understand an obvious way to encode power into a distributed system: The client-server model. Any frontend+backend app is essentially that: It’s fundamentally not peer-to-peer and instead drastically elevates the server in the power hierarchy over clients. This is not only the case for clients coming into existence by downloading and executing server-feed code .e.g., in a browser (compare to, e.g., a smartphone app), it becomes especially apparent when only a server can decide which users are rightfully logged in and can read certain tables in the database. I say that the hierarchy in a web app is fundamentally not peer-to-peer as in most implementations, the server controls the client entirely, and since we’d even go as far as saying that the client could manage the server, then we’d consider it an attack vector.
Client-server architectures
Now: If you’ve ever played around with peer-to-peer libraries - which I recommend - as a client-and-server developer, you’ll soon realize feeling stuck. A sense of hyper normalization has set in, and you’re staring at the screen: Uhm, how… do I build anything without immediately encoding power?
See, already by implementing a chat client that broadcasts a user’s messages and receives other users’ texts - moderating the network’s state is very different from a single server backing up all chat history.
In the practical case of a user broadcasting messages with unwanted content to others, albeit all users being individually capable of deleting them from their storage, the messages would remain untouched and replicable for any user implementing a non-message-deletion policy in their chat client.
So contrast the above to the traditional client and server model, where the client literally spawns from downloading whatever the server delivers: In that case, it’s rather likely the client didn’t store any chat message history at all. But not only that, additionally, the server could implement privileging certain clients over others. Clearly, it’d then also mean that the server could implement logic that allowed an administrator to act on behalf of the community to delete messages containing unwanted content - and unless client users implemented their own software clients, they’d have to show whatever the server delivered. And generally: They’d probably have a hard time upgrading their authority to that of the server.
Consider this: You could technically build a Twitter client that’d only show you things you explicitly want to see, but your filtered view is ultimately dependent on what Twitter would deliver to you in the first place. And all of this to highlight my initial point: Namely that we rarely “just” build peer-to-peer systems. In fact, when given the opportunity, the anxiety for opportunity makes us want to flee back to more familiar architectures.
EIP-20 and EIP-721’s permissioned minting
At this stage, it is important to highlight again that EIP-20 and EIP-721 have sadly shied away from canonicalizing and mandating the minting function to be publicly accessible - and sadly, this has led to many bad results. Famously in the ICO craze - with the reckless selling of PFPs and with the rise of questionable DeFi Ponzi scheme platforms that likely all implemented some sort of founder’s and early investors privilege to flip the value along the adoption curve. If null is the billion-dollar mistake, then what tragedy is the failure to canonicalize the EIP-20 minting function?
But despite all of the above criticism, I don’t want to purely paint a negative picture as to me this can now also be a moment of opportunity and a chance to course correct.
The Soulbound tokens meme is a chance for a clean-sheet design
With DeSoc and comparable philosophical ideas regarding the implementation of social power in blockchain data structures, I think with the emergence of a new token model like Soulbound tokens, we’re now in a spot where the time and will could be in our favor. And so I want to take this moment to point out interesting directions that peer-to-peer token emission through, e.g., EIP-4973’s function give(...) and function take(...) could go. In fact, a really great example that gets my imagination running wild is the countless examples of Stephen Wolfram’s cellular automata, that from simple rules, can spawn seemingly impossible structures. Convince yourselves:
And so this is where I’d like to propose heading towards the minting functions for EIP-4973. I know: for now, it must seem intimidating and unfamiliar that anyone is capable of minting a new token from an EIP-4973 contract. Anyone and with any tokenURI.
But it is also important to realize that Account-bound tokens in this implementation are hence fundamentally incompatible with the permissioned structure of classic EIP-20 and EIP-721 contracts that often put this functionality into the hands of a few privileged.
I also think that we may not even have many use cases where true p2p minting could make a difference either - but with continuing to develop this standard, I think we could end up in a spot where the implementer is capable of defining a cellular automaton-ish rule set that describes the relationship between a token holder’s social power and their reproducibility in that, e.g., DAO founders can invite new members, but members can’t.
Conclusion
In this post, I’ve highlighted the caveats that come from EIP-20 and EIP-721’s failure to define canonical minting functions with descriptive automata rule sets. I’ve defined peer-to-peer as a power hierarchy between computer systems in the context of distributed execution, and I’ve shown how client-server architectures and the prevalence of the web made us all hypernormalized into writing backend and frontend code. But I’m reflecting my criticism and I’m seeing it as a chance to improve the current systems by experimenting further with flattening the distributed systems architectures, e.g. by building smart contracts that treat all users as equally. My vision: an EIP-4973 standard that allows the implementers to define automata reproduction rules to implement social hierarchies interpretable, simulatable, and predicatable to all.
I’ve spent years working on competing solutions to Account bound tokens - namely verifiable credentials with decentralized identifiers where I’ve been an editor of the verifiable credential spec and have audited numerous did methods as an editor of the did spec registries. I definitely have a bias here, but I’m not opposed to this architecture. It seems to align well with the way many other ETH based dApps have approached this problem, but I do have two major issues with this approach.
First off, I’m genuinely surprised that there’s not been one mention of attaching PII to an account on chain in this thread nor in the EIP itself. What sort of privacy nightmare are we trying to create here or am I missing something?
2nd, the primary debate around transferability is a red herring problem in my opinion that’s only occurring because Ethereum still hasn’t decoupled the address identifier (e.g. the way an account is identified) from the cryptographic key authentication material (e.g. the actually public key used to verify a signature). This would be solved if account abstraction was completed so that proper key rotation can occur at the account layer on chain via an authorization to update and revoke keys. Then the account just becomes a simple identifier of an on chain persona.
I’d really hope that more consideration comes into play here around privacy before this ships or you’ll find yourself setting the digital credential space back 5 years or being a massive target by the other competing solutions in the digital credential space who’ve thought this through.
As always: Privacy and linking PII is definitely a problem but always one of the blockchain and not an interface standard, so I’d be happy if people could not make me or co-authors personally responsible for that. Thanks! In 2015 I thought I was funny, encoded my application to a job to Bitcoin addresses, and sent it as transaction. It is still out there, and back then, SBTs didn’t exist, so please direct your criticism correctly to those working on blockchain governance and ensuring its immutability.
You may be able to convince yourself of that truth, but is that really how you’re going to feel in 10 years? Creating technology doesn’t absolve us of a social responsibility in my opinion. I used to believe that and even wrote a blog post as such. I know I’m wrong now. That holds true based on the people I’ve spoken with as well. Every person who I’ve spoke with that contributed to the development of web cookies considers it a failure because they didn’t consider privacy. They at least have an excuse that privacy was a second order problem that hadn’t even been realized when they made it. We can’t say the same about this today.
Secondly, if you do believe that this is something that dApps developers should be considering but is out of scope why isn’t there a mention of that in the first place anywhere in this thread or discussion? This will inevitably leads implementers to believe that it’s acceptable or that developers are somehow meant to assume this knowledge.
This isn’t a hard problem to solve either. At the very least just link to data off chain and put an authz check up so that the data isn’t being published publicly and there’s a basic consent check being made. At least than we’re halfway supporting GDPR because right now nothing about this is GDPR compliant and dApp developers will get called into question by regulators as soon as this gets deployed widely.
I understand your concern given the standard’s broad popularity. For sure, we have a responsibility here and I’m not denying that privacy is a big issue in the blockchain space. In the early days of the RTWOT, I contributed to multiple papers that probably later informed the final design of the DID and VC spec. I’m named a contributor and whatever. I’m generally very friendly to this group of people, and I really respect their work. EIP-4973 is not stepping on VC’s toes, those standards are complementary. If anything, VC contributors should be concerned about EIP-712 being directly competing with what they’re trying to do.
But frankly, over the last few months, I’ve become very disappointed with the way the VC group behaves themselves - especially since they unrightfully shit on the entire work of someone like me that literally develops a standard for an MMORPG game mechanic in their free time. And I mean really shit as, e.g., a popular person compares Soulbound tokens to herpes, etc. And so I also think that your cookie example is extremely misleading here: I am not working for an extractive ad tech company that develops browsers to track their users to harvest data to serve them better ads. And I also don’t own a significant share of interest tokens that would lead me to do that. I’m also not saying you did that or the cookie developers. But now we’re here, and it’s not an individual’s fault IMO, but the set up of those ad tech giants.
I have also worked with many companies over the years, and I have always advocated for my jurisdiction’s privacy and data protection laws. I have had a significant impact on other’s data, and many people can be thankful to me that their PII isn’t stored on-chain because I opened my mouth.
In all coms channels of this standard, I have always tried to teach people about not keeping PII on-chain. But if you follow my social media, you can see that people rather like to follow users that compare SBTs to the herpes virus, so my reach is limited, sadly.
But again: It really doesn’t matter what functions you use to encode PII to store it on Ethereum. It will make no difference if it comes from an EIP-20 token, EIP-721 token, or Unicode string. It is obviously a very bad situation, but for real nothing, I can truly influence in this thread specifically.
See, the ERC standards track is only about defining a class interface of a Solidity contract object: we can’t even properly enforce implementing certain behaviors (e.g. check sleepminting attacks for EIP-721). Sure I can use strong normative language, but ultimately we’re going to have to rely on the common sense of developers here to know what’s right and what isn’t.
Again, you have a reasonable request, and you deserve to be heard. Universally, not all information stored on Ethereum should be easily accessible and the Ethereum Magicians can be a venue to discuss solutions! But not in this thread.
So to me, unless you have specific use case examples where a user’s contextual integrity is at risk with the Solidity interface outlined here, I think in this conversation, it is out of scope. But of course, if you have one, feel free to share it, and we can solve the problem.
If you want to write a section in the EIP about not storing PII, I’ll merge it and make you a co-author. We have an interpretation of the sovereign identity principles here: What are Account-bound tokens?
Yeah absolutely, and any implementer can do that by reverse-proxying the access to the tokenURI resource.
Woah, the hostility isn’t needed, but I understand where it’s coming from if you’ve been attacked in that way. I don’t condone behavior like that since it’s not conducive to a collaborative environment. Let’s keep this on topic and focused on the development of the EIP. I’ll commit to that and will address a few of the comments here before I go back to discussing the original topic at hand.
But frankly, over the last few months, I’ve become very disappointed with the way the VC group behaves themselves - especially since they unrightfully shit on the entire work of someone like me that literally develops a standard for an MMORPG game mechanic in their free time. And I mean really shit as, e.g., a popular person compares Soulbound tokens to herpes, etc.
I’d suggest directing your personal attacks or character defenses at them then. I’ve not personally attacked you, I’ve critiqued your work as is expected in these forums. However, I can understand how my comments above could be read that way and I apologize especially given the history you’ve encountered. That was not my intention. I don’t personally know you so it would be unreasonable for me to make any sort of assertions about your character. Furthermore, while I do associate myself with that group and have participated as a member I do not endorse every statement of the WG nor it’s members. Please do not associate it as such as that’s an unfair assumption.
I am not working for an extractive ad tech company that develops browsers to track their users to harvest data to serve them better ads. And I also don’t own a significant share of interest tokens that would lead me to do that.
Full disclosure from my end, I own no cryptocurrencies currently and the primary portion of my tokens purchased previously have been BTC and ETH. I have owned other tokens back in 2017 when speculating including BAT, but I sold them before I began working for the company. Furthermore, the purpose of my statements were not to state that you’ve somehow used cookies maliciously, but rather to point out that, as developers, we still maintain a social responsibility for the tools we build and we should be doing our best to contribute where we can. The same could be said for any technology including technology I’ve worked on such as Covid passes that have directly led to social unrest throughout the world. I accept the responsibility that I indirectly contributed to that and am using that knowledge to improve how I build systems in the future.
I have also worked with many companies over the years, and I have always advocated for my jurisdiction’s privacy and data protection laws. I have had a significant impact on other’s data, and many people can be thankful to me that their PII isn’t stored on-chain because I opened my mouth.
In all coms channels of this standard, I have always tried to teach people about not keeping PII on-chain.
Thank you, I was not aware of this as I’ve not been on Twitter for the past 3 years nor have I seen your work previously. My impression of you comes only from reading this thread and this EIP since that is what I was trying to critique.
Now that we’ve addressed those concerns, I’ll focus back on the topic at hand.
It really doesn’t matter what functions you use to encode PII to store it on Ethereum. It will make no difference if it comes from an EIP-20 token, EIP-721 token, or Unicode string. It is obviously a very bad situation, but for real nothing, I can truly influence in this thread specifically.
I’d argue a nuance here that we do have the ability to influence if we don’t have the ability to outright deny when developing standards. This is why the VC spec has spent so much time authoring a privacy section on many of these topics. Even if the implementers choose to outright ignore normative sections we can still encourage particular behavior (such as publishing PII on the chain) via authoring particular sections on this topic. It sounds like you’re in favor of this as well. I’d be happy to contribute a privacy considerations section to the EIP and will do my research of that link provided.
On quick glance, I think we’ll probably need to debate the principles and considerations here a bit to improve this, but that’s ok. As long as we know we’re trying to achieve something that’s doing so and also pointing the developers in the right direction I’m sure we’re generally going to find some consensus on the topic and get some insightful information added to enhance the EIP.
Yeah absolutely, and any implementer can do that by reverse-proxying the access to the tokenURI resource.
Sounds like there’s some recommendations you’ve got here that we could non normatively include as notes to point people in the right direction. One thing I’ve learned is that if we provide examples and good notes than most developers imitate that code and read those things to treat documents like this as gospel truth. Even just updating the assets document could go a long way to pointing developers in the right direction without the need to normatively define these things because most developers don’t read the full document anyways.
I’m sure we can find a good solution here, and I wanted to raise these two major concerns here to make sure we’re taking this to the best direction. I’m happy to help contribute to this and offer what I’ve learned through the years of debate. I’m not the enemy just a developer who wants to see good solutions that are useful built just like you (I assume).
@TimDaub here’s an initial PR to kick off the authoring of a privacy considerations section. It’s all non-normative at this point and really just briefly glazes over many of these issues which could turn into much larger more detail solutions of their own, but it at least gets us a starting point to iterate on. Hopefully, this isn’t too far off from your thinking on this work and if it is let’s continue to discuss and find some consensus about what a privacy by design solution might look like for ABTs.
I agree with the blog post’s idea that values and view points can change over time. I also like the idea of trust being a more specific application of risk. But where I’d disagree is on the premise of framing tech as possibly neutral. Or rather, that a single human being is capable of fully reflected neutrality.
E.g. there are people falsely claiming their work to be more neutral than others. But this cannot be true. There are cultures on this planet, and generally view points, anyone can reach that are entire incompatible with what certain people would call neutral. Even if, for years, you’d “succeed” in creating “neutral” technology, every new day someone could come out of the wood work and present a view point putting in question your seemingly neutral position. So for me the attempt at purposefully building neutral technology won’t work.
Within this specification and other work, I’ve adopted problem-driven development, meaning we check the technical vision etc. at the door and iterate on actual problems in the actual context. And then we solve them iteratively.
But where I’d disagree is on the premise of framing tech as possibly neutral. Or rather, that a single human being is capable of fully reflected neutrality.
That’s the exact issue I’ve come to realize was incorrect at the time of writing the post. I’m glad we see it the same way!
Within this specification and other work, I’ve adopted problem-driven development, meaning we check the technical vision etc. at the door and iterate on actual problems in the actual context. And then we solve them iteratively.
I’m happy to stay focused on the problem, but without a vision for where we see this going and how we see it being used we may introduce unintended consequences that would be valuable to address from the outset.
For example, if this was truly only intended to be used for your single use case of games there’s not likely to be a problem with privacy at all since that use case hardly links the PII of the person to the avatar being represented in the game. However, we both know given the landscape of digital credentials and the external activity outside the Ethereum community that’s unlikely to occur so it’s useful for us to address these concerns (like we’re doing in that PR I’ve linked).
Anyways, I find that this would be an interesting discussion to continue, but I don’t think this is the right place to continue the discussion. Instead we could move it to a different thread and keep this focused on the specific development considerations of EIP-4973.
IMO we can keep it here and you should point out specific problems as you have a good eye for privacy issues. E.g. @rsquare from Otterspace is implementing the standard for DAO voting and they have a demo live. So you two could get in touch, you observe issues in their approach. And if those issues are back tracable to the standard interface we make the changes to the document.
but a document we should co author @kdenhartog is basically an EIP informal document of an interpretation of the ten self sovereign identity principles specifically for Ethereum, similar to how I did it in my blog post. @Sal could also be interested in moderating this I imagine
Yeah I need to dig into that a bit more. Right now, I’ve not even done proper justice to playing around with the contract interface and evaluating how it can be used or abused so far so I’ll take a look at Otterspace to see what I can learn from this a bit more.
but a document we should co author @kdenhartog is basically an EIP informal document of an interpretation of the ten self sovereign identity principles specifically for Ethereum, similar to how I did it in my blog post. @Sal could also be interested in moderating this I imagine
I’m keen that seems like something that would be useful to describe some principles of design for dApp architectures.
yes, collaborating on an interpretation of these principles applied to dApps would really propell the space forward in a posititive direction and ultimately a standards doc like eip-4973 would profit by being able to reference and inform decisions axiomatically from it.
Just a quick note to every person who ever develops any sort of identity-related tech from this moment until the end of human history (a purposefully large net) – pay attention to these words.
Everything I see (excluding this, perhaps) seems almost designed on purpose to create a massive privacy nightmare in the future.
I understand those general concerns about privacy as data generally isn’t deletable on blockchains, but I’d also like to stress that there are widely cited academic publications, most notably H. Nissenbaum’s “Privacy as contextual integrity,” that build an entire framework for specifically evaluating uses cases based on their privacy where pre-existing norms are considered and it is checked whether those norms are challenged.
Hence, through this lens, generally saying: “Using SBTs/cookies is a bad idea for privacy,” is arguably not reasonable as the underlying reasons for a certain flavor of privacy are culturally specific. E.g., cookies, when not being used as third-party tracking devices to spy on users for the sake of data mining their shopping preferences, are a completely fine tool for web developers, e.g. for implementing sessions.
In fact, I’ve used cookies many times in my career, and I’ve never “accidentally” data mined my users’ data and sold their data to advertisers! It’s not only a design question - it’s also about a person’s integrity and responsibility!
It’s vital when using cookies, SBTs, ABTs, or any other technology, especially when we’re dealing with PII, to understand how to evaluate the software in Nissenbaum’s contextual integrity framework.
If this is done appropriately and with a good faith, then I don’t see any problems with developers using cookies, SBTs, or ABTs.
references
1: Nissenbaum, Helen. “Privacy as contextual integrity.” Wash. L. Rev. 79 (2004): 119.
