LIP-21 - Dealing with Squatterd Profiles #48
Conversation
|
|
Thank you for providing these ideas. My numbered remarks refer to the same number in your outline. Also the remarks don't mean that you should provide the solution; I don't have them either.
In this model only the legitimate person/project seems to be able to report. But if this person/project never joins Lens, their profile lived on forever and may open doors to scams and false information.
The biggest problem seems to be the type of proof and to run this in a decentralized way. Also proofs for people and projects might be different. Maybe we could easily proof Hayden Adams is actually him, but how can we proof Uniswap to be legitimate if it isn't reported by Hayden (i.e. we'd need to know employees, DAO members,... and they'd need to proof their identity). |
|
Thanks @seliqui for creating the LIP and opening the discussion on the topic. Just to confirm, we are mainly referring to Squatted Handles? Given profiles are simply connections while Handles are usually representative brands |
|
Yes, I guess its handles. I've mixed this up as well. |
|
@EthWarrior I think it's raised for squatted handles. WEN illustratuons btw handle and profile in a ELI5 style? I think 95% of users are not aware of the concept even after reading https://docs.lens.xyz/docs/profile , FAQ part is needed, which would largely facilatate such discussions in LIPs afterwards. Regarding what seliqui has proposed. My concern is the underlying issue of decentralization. Given that the handle is registered in a permissonless way. If Lens does not withhold handles of the brand names at first, they should be considered FCFS to the public (like ENS). Even the profiles belonging to the handle are not active on Lens, the owner is regarded to have incentives to sell them at a profit sometime in the future. If the Even the handle is abused like scams or spreading intentional false information, it should be frozen but not automatically transferred to another account. My unthoughtful opinion is
|
|
@hjjlxm to simplify the differences between handles and profiles for the next iteration of Lens Protocol, we are highly considering combining handles and profiles together, where handle is simply a name for the profile that can be changed. My take around the handle squatting is that if users could for long-term vision get a free profile and then pay for a unique handle a annual fee (OGs could be except from the fee during a long grace period). ENS has been able to collect some decent fees https://dune.com/steakhouse/ens-steakhouse Handle is an unique sought after property, so would expect some markets evolve. Similarly I think down the line apps should be able to also create their own unique namespaces with Lens if there is demand. Curious to hear some thoughts on above. |
|
I'm in favor of addressing this issue and most (bunt not all) of the proposal. I agree that there should be infrastructure to report squatting / impersonation / wallet compromise (possibly as an extension of #46 ) and infrastructure to more easily facilitate handle transfer (possibly through open actions). I have a pretty hardline opinion on the final suggestion though that I don't think that Lens protocol should ever revoke ownership of a profile. One of the core value propositions of Lens is the ability to "own your digital roots". I think it's a dangerous precedent if Lens community uses force majeure to modify or revoke an onchain agreement, since the same justification could be used for censorship. My suggestion for ways to extend this system without revoking handle ownership is for Lens apps and search infrastructure to have deeper integrations with other forms of identity and attestations such as ENS and Ethereum Attestation Service (similar to comments I made on #32). I don't think a Lens handle should define who someone is on Lens, I think it should be one of many forms of identity that apps and users can use to make informed decisions about whether a Lens Profile represents a person/brand that is shared across other platforms. |
|
While unfortunately I do not have an elaborate solution on squatters, I do have an opinion on how its handled. I'll start by riffing off the suggestions: A handle gets reported as being squatted/impersonating The Reporter needs to provide proof to be the valid owner/project and provide a predifined collateral. This is probably a solution that could be done at the app level, but I don't agree with the ability for an entity to say they own an @handle and I don't think they should be able to shadow ban someone for using the same handle. If the Squatter doesn't go do through the dashboard process (for example they squatted the handle but aren't active on lens), after a specified period (maybe 30 days) the handle gets transferred automatically to the verified reporter and the reporter gets the collateral back. The squatter still holds a lens handle with an addition (like _x). I am very much against this - NEVER should the protocol transfer a handle without a signature from the private key and there should be no ability to do so or else its all for none. As for a solution, I would suggest "Premium/Intuitional handle that can have the same @ they want and comes up 1st on apps which goes for a larger price/streamed price and must be verified by a governance accepted decentralized identity service." Online impersonation is going to be a problem in the future with or without squatters, so maybe this is a more prudent solution. I also agree with @defispartan 's comments, @EthWarrior 's comments, I disagree with @hjjlxm 's comments on freezing at the protocol level. In summary, I think there should either, or both be measures taken only at the app layer, or a separate chain of handles that are without the same guarantees as regular handles. |
|
I think the issue is impersonation (i.e. using the same handle, picture and/or display name than another person), as it can be used to cause harm (like scamming people). But I don't see an issue on somebody owning a particular handle, even if this handle is usually linked to a different person in other platforms. This being said, even when I acknowledge the harm of impersonation, I don't think a handle nor a profile should be able to be taken from a certain user. I think this goes against Lens' values and the ethos we are promoting. I think this should be addressed, as others already mentioned, at the application/client level. Each application can have their own way to moderate this, or multiple apps could cooperate to create a registry where they can share harmful profiles. If the latter happens, this LIP can lead the development of some standard for that. |
|
@donosonaumczuk I completely agree. I think it would be interesting to hear debate on a more optional Lens creation ability for corporate/traditional entities. Maker DAO's latest plan seems to be using this dual-purpose structure for RWA and decentralized DAI. It's definitely a thing to watch - maybe in the future Lens could adopt a similar system where a string of Lens profiles are interoperable with the protocol, but can give a corporation a squatted handle on a more centralized and less censorship resistant Lens Profile without touching or impeding on the values instilled in Lens Protocol. Thoughts @defispartan @seliqui @carstenpoetter @EthWarrior? |
title: Squatterd Profiles
description: Lip-21 opens the discussion for finding an (intermediate) solution on how to handle squatted profiles
author: seliqui (@seliqui)
status: Draft
type: Protocol
created: (2024-03-16)
Abstract
Finding a solution on how to deal with squatted profiles.
Without having at least something in place, known brands will be hestitant to onboard to Lens if their handle has been squatted (or even worse, actively impersonating them), without any option to file a complaint and resolve the problem.
Motivation
Especially after Lens came permissionless, it became more obvious that there's no solution in place on how to deal with handles that have been squatted - or even worse, actively impersonate a known project/brand. Having a "Lens-Wide Verification Process" in place as proposed in LIP-9 would help, but not resolve the problem.
To kickstart the discussion, I'll propose this approach:
Consider these steps as a ground for discussion, not a fully thought through approach.
Until there's something in place like the Cultivator DAO, an intermediate solution needs to be found.
And even afterwards, the DAO also needs some way on how to deal with the issue.
Specification and Rationale
The discussion is WIP. No Specification or Rationale can/should be made at this point.
Copyright
Copyright and related rights waived via CC0.