[Feature-Request]: Enhanced LSP26 Follower System

[Heisenburgirs]

Describe the desired feature:

Enhanced LSP26 Follower System

This change introduces several new features to the LSP26 Follower System, providing users with greater control over their Universal Profile and social interactions. These enhancements aim to address common issues in social networks and create a more user-controlled environment.

New Features

1. Private Account Mode

Users can now set their account to private, requiring approval for new follow requests.

2. Follower Removal

Account owners can now remove followers from their list.

3. Blocking

Users can block other accounts, preventing them from following and potentially interacting in other ways.

4. Unblocking

Blocked accounts can be unblocked, allowing normal interactions to resume.

What was changed?

Here's list of new functions, internal functions, errors, constants, events and state variables introduced in this PR.

New functions introduced in the LSP26 interface & contract:

setRequiresApproval
respondToFollowRequest
respondToFollowRequestBatch
removeFollower
removeFollowerBatch
blockAddress
blockBatch
unblockAddress
unblockBatch
isApprovalRequired
isBlocked
pendingRequestCount
getPendingFollowRequests
blockedCount
getBlockedAddresses

New internal functions in the LSP26 contract:

_createFollowRequest
_addFollower
_removeFollower
_block
_unblock

New errors:

LSP26CannotRemoveSelf
LSP26CannotBlockSelf
LSP26BlockedFromFollowing
LSP26CannotUnblockSelf
LSP26UserBlocked
LSP26AlreadyBlocked
LSP26NotBlocked
LSP26NoFollowRequestPending
LSP26FollowRequestAlreadyPending

New constants:

_TYPEID_LSP26_REMOVE_FOLLOWER
_TYPEID_LSP26_BLOCK
_TYPEID_LSP26_UNBLOCK
_TYPEID_LSP26_REQUIRES_APPROVAL_SET
_TYPEID_LSP26_FOLLOW_REQUEST_SENT
_TYPEID_LSP26_FOLLOW_REQUEST_APPROVED
_TYPEID_LSP26_FOLLOW_REQUEST_REJECTED

New events:

RemovedFollower
Block
Unblock
RequiresApprovalSet
FollowRequestSent
FollowRequestApproved
FollowRequestRejected

New state variables:

_requiresApproval
_pendingFollowRequests
_blockedAddresses

Testing and Quality Assurance

We've run our new features through Remix. So far, everything's working as intended, which is great news. But we know how crucial thorough testing is in smart contract development.

Moving forward:

1. LSP26FollowerSystem.test.ts needs to be updated to test new functionalities.
2. There might be edge cases - or use cases - that we haven't thought of before. Needs more investigating.
3. We need to ensure smooth integration with other LSP standards, particularly LSP1 to make sure nothing reverts.

We'd really appreciate input from the community on additional test scenarios. Fresh perspectives often uncover things we might have missed.

Rationale

These new features address several key issues:

1. Spam Prevention: By allowing users to remove followers and block accounts, we reduce the impact of bot accounts and spam followers.

2. Privacy Control: Private account mode gives users the ability to curate their follower list, ensuring that only approved accounts can follow them.

3. Content Filtering: Blocking functionality can be used by dApps to filter content, allowing users to avoid seeing posts or interactions from blocked accounts.

4. Enhanced Security: These features provide a foundation for more secure interactions. For example, blocking could be integrated with LSP1 to prevent unwanted token transfers or contract interactions from blocked Universal Profiles.

5. Flexible Implementation: While these features provide powerful tools for user control, they are implemented in a way that allows dApps to utilize them flexibly, potentially creating more nuanced social experiences.

Impact

I believe these new features make the LSP26 Follower System more robust and open up possibilities for more nuanced use cases. The idea for these enhancements came from looking at the current implementation of LSP26 and seeing the issues that users faced with botted accounts or otherwise.

For example - as mentioned earlier - the blocking feature could be used in conjunction with token transfers. Imagine a scenario where you don't want to receive tokens from a specific Universal Profile - blocking could be integrated with LSP1 to prevent such unwanted transfers.

These additions give users more control over their social interactions within the LUKSO ecosystem. They're not just abstract concepts; they address practical concerns like spam followers, unwanted interactions, and privacy control.

While there's always room for further improvements, I think these changes represent a solid step towards a more user-centric and flexible follower system for Universal Profiles. They provide a foundation that developers can build upon to create safer and more customizable social experiences in their dApps.

Thanks for reading! Let me know your thoughts

Code example that solves the feature:

New Features

1. Private Account Mode

Example:

// Set account to private
followerSystem.setRequiresApproval(true);

// Approve a follow request
followerSystem.respondToFollowRequest(requesterAddress, true);

// Reject a follow request
followerSystem.respondToFollowRequest(requesterAddress, false);

2. Follower Removal

Example:

// Remove a single follower
followerSystem.removeFollower(followerAddress);

// Remove multiple followers
followerSystem.removeFollowerBatch([follower1, follower2, follower3]);

3. Blocking

Example:

// Block a single address
followerSystem.blockAddress(addressToBlock);

// Block multiple addresses
followerSystem.blockBatch([address1, address2, address3]);

4. Unblocking

Example:

// Unblock a single address
followerSystem.unblockAddress(addressToUnblock);

// Unblock multiple addresses
followerSystem.unblockBatch([address1, address2, address3]);

Link to Github repository containing the changes - https://github.com/Heisenburgirs/lsp-smart-contracts/tree/sub