Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LIP-6]: Profile Guardian Tied to ERC 6551 Wallet #23

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions LIPs/lip-6.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
title: Profile Guardian Tied to ERC 6551 Wallet
description: This LIP proposes to tie the Profile Guardian to an Ethereum Request for Comment (ERC 6551 wallet allowing users to disable it for individual profiles without affecting others
author: DanIsNearby
status: Draft
type: Protocol
category: Contracts
created: 2023-11-08
---

## Abstract

This LIP suggests a modification to the Lens protocol to associate the Profile Guardian with an ERC 6551 wallet. This change will enable users to disable the Profile Guardian for specific profiles, reducing the risk to individual profiles when needed.

## Motivation

The current implementation of the Profile Guardian in Lens ties it to a user's primary wallet, making it an all-or-nothing security measure. This can be problematic when users wish to disable the guardian for a specific profile temporarily. This LIP aims to address this limitation and enhance the flexibility of the Profile Guardian by associating it with an ERC 6551 wallet.

## Specification

The proposed modification involves linking the Profile Guardian to an ERC 6551 wallet. This association will allow users to manage the guardian on a per-profile basis, providing more granular control over their security settings.
Copy link
Member

@cesarenaldi cesarenaldi Nov 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please expand (even in reply to this comment for now) some practical examples of how this might look like?

Just by reading this I would assume you are hinting at a bespoke ERC 6551 that is somewhat Lens Profile aware.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what i understand the Lens profile now is a ERC 6551 and can be used as a wallet store followers store NFTS etc same way as ORB stores their community nfts inside i was thinking of linking the guardian to that entity rather to the wallet holding the profile

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were considering having ProfileGuardian as a whole modular system, that will allow different levels of protection:

  • Protecting Wallet as a whole (as it is now)
  • Protecting Collection as a whole
  • Protecting Individual NFT in a Collection

With the latter overriding the former.

I think this LIP might be a special particular case of this system above. I think we don't need to particularly focus on 6551, as focusing on protecting an individual tokenID is basically the same thing, even if it is not 6551 (please correct me if I'm wrong)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 6551 was just an example of how it can be taken care of basically i mean that it would be to unprotect on of the acounts not all of them


## Rationale

The rationale behind this change is to improve the user experience and security of the Lens protocol. By enabling users to disable the Profile Guardian for individual profiles while keeping it active for others, we provide a more adaptable security solution.

No specific alternate designs or related work are mentioned at this time.

## Backwards Compatibility

No backward compatibility issues have been identified with this proposal.

## Security Considerations

The security implications of this change should be thoroughly discussed. Potential concerns, risks, and implementation-specific guidance must be addressed to ensure the safety of this feature. Further security discussions are required before finalizing this proposal.

## Copyright

Copyright and related rights waived via CC0.