Profile Attestation NFT

Here is an example of the hack:
image

image

1 Like

This was being done and I let opensea know, as well as reporting those items that did it. I let the 100kclub and 10kclub know of this scheme and advised to confirm on ENS.

1 Like

Seems like it’d be much easier to solve this by just changing the preview the metadata service generates to put the ENS name underneath the profile image instead of overlayed on top of it, right?

1 Like

There is another hack which this won’t fix, misspellings with pictures. A good example would be tyranosaurus.eth with a picture of a Tyrannosaurus. The picture helps to validate the misspelling, and will inevitably lead to people buying misspellings. I think the only solution is to remove images from domain listing, and create verified profile attestation NFTs.

1 Like

I mean, at a certain point you can’t protect people from just being careless lol

I think I’m as lost as @nick.eth , why would attestations solve this case? Wouldn’t it be trivial for me to copy/paste the JPEG, create a new NFT I do actually own that has the same image, and have a “valid” PFP NFT with the misspelled name?

Additionally, why couldn’t I do the same thing with the “l” fake ENS name letter image? The user would now have to make sure it’s the right ENS name and the legit NFT collection with the correct contract address, wouldn’t they? When in reality, all they really have to check today is looking at the actual ENS name and seeing if it’s the right one they want versus just looking at the image.

@AvsA’s idea here is pretty interesting and may be related:

2 Likes

@Premm.eth do you have examples of such attack happening in the wild or is just theoretical? While I think your point about ndia.eth and gloo.eth are clever, I’m not sure they’d be enough to fool someone as the actual name is always visible on marketplaces. It seems it would only affect someone who did absolutely no checks when buying a name, maybe just took a glance at the preview and clicked buy.

Avatars are a very popular feature and I wouldn’t take it down based on a theoretical attack that isn’t a real problem at the moment.

If the problem is to verify that an NFT truly belongs to the user, and it’s a verified collection, I think the other proposal above highlighted by @serenae solves the problem better than any NFT attestation.

7 Likes

ProAts are very similar to Lens protocol profiles, and they could be made to be compatible with Lens protocol or other distributed social graphs. It is also possible to change the profile standards as needed and allow users to upgrade their profiles without changes to the underlying assets.

/**
 * @notice A struct containing profile data.
 *
 * @param pubCount The number of publications made to this profile.
 * @param followNFT The address of the followNFT associated with this profile, can be empty..
 * @param followModule The address of the current follow module in use by this profile, can be empty.
 * @param handle The profile's associated handle.
 * @param uri The URI to be displayed for the profile NFT.
 */
struct ProfileStruct {
    uint256 pubCount;
    address followNFT;
    address followModule;
    string handle;
    string uri;
}

ProAts could be managed by a DAO or multiple DAOs. It is inevitable that there will be client facing social media apps that decide only to include safe verified profiles into their client side applications. A DAO that manages their own members profiles is able to decide which type of profiles can and cannot be created. Web3 Social media apps could choose to include all the members of a trusted profile DAO, therefore decentralizing the problem of verified social media handles. There may be client facing apps that allow for any profile image, including spoof NFT avatars and fake ENS names with hidden characters, but these type of apps will probably not be the most popular.

I expect the social profile which includes a “handle” and a “uri” to become a standard. ProAts build upon this standard and include additional features including lending or delegating a profile to a mobile wallet or third party, verified NFTs, and ENS names.

ENS names will become very valuable assets in the future, and for this reason, marketplaces will continue to limit what can be done with an ENS name within a marketplace. I expect that this will include not showing avatar images. I could of course be wrong about this, and I also love avatar images, but I do think that it will be necessary at some point the in the future to abstract profiles away from the underlying ENS name asset.

2 Likes

Ok, but now is this a solution to an exploit, or a feature you think would be cool? @AvsA gave a pretty compelling challenge to reasoning that seems to have been ignored.

I haven’t seen anything in this thread yet that creates a strong argument for why attestations are necessary as an anointed ENS project.

1 Like

Here is a good example of what should be avoided.

https://blog.veefriends.com/how-to-make-a-mobile-wallet-for-your-veecon-ticket-fc042d3fbba1

With a profile attestation it would be possible to add tickets to that profile that are stored in a vault, but are attached to the user.

The other reason it makes sense to use a profile system is that it is possible to change a .eth name and still maintain the same profile data.

A ProAt can have a controller address, which can be a hot wallet. For ticketed events it would be possible to show when the controller address was updated, and if it was updated during the event, deny entry. This would prevent already admitted users from changing the controller address of their ProAt to their friend’s address to get other people in the door as well.

What an event may want to avoid is NFT holders selling or renting access to their events, but this is already possible using collateral. If someone provides enough collateral, then it is possible to lend the NFT to anyone, getting them into an event, even if they are really not owners of the NFT membership pass. Later if the membership pass is not returned then the lender would keep the collateral.

1 Like

If the ENS name is transferred, you don’t need attestations to easily show that to the ticket checker at an event. Any UI can easily lookup the controller address and see if it matches an original address. But really, it seems it’d be simpler if the ticket was attached to a wallet and non-transferrable, for the use-case outlined.

I’m not sure any of the use-cases you’ve outlined are actually the use-case for attestations. Usually, attestations are actually about proving some attribute without revealing the underlying data. It’s about privacy.

But at the very least, I’m still lost on why we’re talking about this in the context of ENS :man_shrugging: Maybe I’ve missed something, though!

1 Like

I was going to write a longer response, but then this news came out today. Yep, it’s a ProAt!

https://blockworks.co/coinbase-to-take-defi-first-approach-with-its-app-and-wallet/

Tackling Web3 identity

Chatterjee said that the cumbersome use of long wallet addresses — the public key which, on Ethereum, begins with 0x — remains a barrier to adoption. To reduce complexity, the Coinbase Wallet will allow a user to claim an Ethereum Name Service (ENS) address for free. ENS is just one of several services Coinbase plans to integrate, a spokesperson told Blockworks, to address problems around Web3 identity.

To alleviate privacy concerns, Coinbase proposes to become a secure provider of know your customer (KYC) verification, which can be passed on to third-party dApps while maintaining user privacy, using zero-knowledge proofs (ZKP). To do that, the wallet will let developers access an open ZKP SDK, which should provide verification for required data — such as meeting a minimum age requirement — without revealing a user’s specific details.

1 Like

Right… they are planning to use ZK proofs for KYC to maintain privacy. That bit is entirely unrelated to the part about ENS. I’ll exit this thread now cause I’m a little lost on what we’re talking about at this point :sweat_smile:

2 Likes

The possibilities are really endless, but the basic idea is that the ENS domain its self with the avatar image will not be the user profile of the future. It is necessary to build a layer on top of Avatar NFTs and ENS user names, to create verified profiles. This is exactly what Coinbase is doing, and exactly what I was talking about. I think there could be a decentralized version of this, so basically a profile DAO. It would do the same thing, offer verified profiles with features, including attestations.

2 Likes

A user identity is just their ENS name, not a combination of Avatar + ENS. You don’t need to verify they own their avatar NFT for anything important. If a platform allows for unnormalized names, it is a broken implementation. It seems best to spend time on normalization and display standards for unicode ENS names, so that platforms can handle any confusing chars in a consistent way. I think a custom typeface that distinguishes confusables might be helpful, available in standard font formats as well as via metadata SVG.

I’ve seen the issue of “my token is in my vault/other wallet” come up more often, and I think it could be addressed by having the vault owner maintain a list of active hot wallets, like some kind of family plan. It could be done with additional TXT records on their ENS name, just like multiple A records are valid in DNS.

In the example of tickets, the platform should track which ticket/token IDs have already been used for access. It would be a security bug if the owner could move the token to another wallet and still gain access.

We are working on a novel PFP for 10K Club that lets users combine their “number” ENS and an avatar NFT. The PFP contract verifies ownership of both items when initially set, but the ongoing ownership verification will be handled by the metadata server, which renders a composition image of both number and avatar. We hope to support NFTs across multiple wallets by using custom TXT records that indicate additional wallet(s) to be considered for ownership verification. Any additional wallets would require a reciprocal (reverse) TXT record in their primary ENS, and all these records must include a signature.

1 Like

Saw this today:
https://claim.lens.xyz/claim

Wider access will be rolled out soon to all ENS domain owners. In the
meantime, take a walk through the garden and see what’s been built on Lens.

Things are starting to really move in this space, the race is on between lens and coinbase to create the number one Web3 profile. Anyone know of any other Web3 profile services?

Looks like ENS is at the center of both projects.

This looks like it could be used to sell complex profiles, including ENS names, Avatar NFTs, NFT tickets and membership passes in a single transaction.

Hello @Premm.eth

Personally thinking about; when someone set up a new avatar; they want to see only image, without any additional logo, text as domain name, or background.

On other side; secondary marketplaces need to implement better UI design practices;

• Smaller avatar size
• Character count
• Font with slashed zero
• Font with clear difference between the number 1, and lowercase letter L
• Domain expiration date
• Clear warning if domain contains non-ASCII characters

Someone who can get in touch with secondary marketplaces like OpenSea, LooksRare, X2Y2 and recommend above mentioned practices? Thanks.

I think you are possibly confusing the avatar text record with the image of the ENS domain (as an NFT) itself?

The ENS metadata service dynamically creates the representation of the ENS token for secondary marketplaces and galleries by rendering the standard ENS overlay on top of the image linked via the avatar text record.

So the place to change the font to fix named issues (slashed zero, 1, l (lowercase L), I (capital I) etc. confusion would be the metadata service itself: https://github.com/ensdomains/ens-metadata-service