Feed Rules

First, inspect the feed.rules field to know the current rules configuration.

type FeedRules = {  required: FeedRule;  anyOf: FeedRule;};

The configuration for the built-in rules with one or more parameters is as follows.

Next, update the rules configuration of the Namespace as follows.

import { bigDecimal, evmAddress } from "@lens-protocol/client";import { updateFeedRules } from "@lens-protocol/client/actions";
const result = await updateFeedRules(sessionClient, {  feed: feed.address,  toAdd: {    required: [      {        tokenGatedRule: {          token: {            standard: TokenStandard.Erc20,            currency: evmAddress("0x5678…"),            value: bigDecimal("1.5"), // Token value in its main unit          },        },      },    ],  },});

First, implement the configure function. This function has the purpose of initializing any required state for the rule to work properly.

It receives two parameters, a 32-byte configuration salt (configSalt), and an array of custom parameters as key-value pairs (ruleParams).

The configSalt is there to allow the same rule contract to be used many times, with different configurations, for the same Feed. So, for a given Feed Rule implementation, the pair (Feed Address, Configuration Salt) should identify a rule configuration.

For example, we could want to achieve the restriction "To post on this Feed, you must be a member of Group A or Group B". In that case, instead of writing a whole new contract that receives two groups instead of one, we would just configure the GroupGatedFeedRule rule twice in the same Feed, once for Group A with some configuration salt, and once for Group B with another configuration salt.

The ruleParams is an array of key-value pairs that can be used to pass any custom configuration parameters to the rule. Each key is bytes32, we put the hash of the parameter name there, and each value is bytes, we set the ABI-encoded parameter value there. Given that ruleParams is an array, this allows the rule to define which parameters are optional and which are required, acting accordingly when any of them are not present.

In our example, we need to decode an address parameter, which will represent the Group contract where the account trying to post must belong to. Let's define a storage mapping to store this configuration:

contract GroupGatedFeedRule is IFeedRule {    mapping(address feed => mapping(bytes32 configSalt => address group)) internal _groupGate;}

Now let's code the configure function itself, decoding the required address parameter and storing it in the mapping:

contract GroupGatedFeedRule is IFeedRule {    mapping(address feed => mapping(bytes32 configSalt => address group)) internal _groupGate;
    function configure(bytes32 configSalt, KeyValue[] calldata ruleParams) external override {        address group = address(0);        for (uint256 i = 0; i < ruleParams.length; i++) {            if (ruleParams[i].key == keccak256("lens.param.group")) {                group = abi.decode(ruleParams[i].value, (address));                break;            }        }        // Aims to check if the passed group contract is valid        IGroup(group).isMember(address(this));        _groupGate[msg.sender][configSalt] = group;    }}

Next, implement the processCreatePost function. This function is invoked by the Feed contract every time a Post is trying to be created, so then our custom logic can be applied to shape under which conditions this operation can succeed.

The function receives the configuration salt (configSalt), so we know which configuration to use, the ID the Feed assigned to the Post (postId), the parameters of the Post (postParams, including things like author and contentURI), an array of key-value pairs with the custom parameters passed to the Feed (primitiveParams), and an array of key-value pairs in case the rule requires additional parameters to work (ruleParams).

The function must revert in case of not meeting the requirements imposed by the rule.

Groups follow the IGroup interface, which has the following function to query if an account is a member of the group or not:

function isMember(address account) external view returns (bool);

Now let's code the processCreatePost function taking all the described above into account:

contract GroupGatedFeedRule is IFeedRule {    mapping(address feed => mapping(bytes32 configSalt => address group)) internal _groupGate;
    // . . .
    function processCreatePost(        bytes32 configSalt,        uint256 postId,        CreatePostParams calldata postParams,        KeyValue[] calldata primitiveParams,        KeyValue[] calldata ruleParams    ) external override {        require(IGroup(_groupGate[msg.sender][configSalt]).isMember(postParams.author));    }

Next, implement the processEditPost function. This function is invoked by the Feed contract every time a Post is trying to be edited, so then our custom logic can be applied to shape under which conditions this operation can succeed.

The function receives the configuration salt (configSalt), so we know which configuration to use, the ID the Feed assigned to the Post (postId), the parameters of the Post to edit (postParams), an array of key-value pairs with the custom parameters passed to the Feed (primitiveParams), and an array of key-value pairs in case the rule requires additional parameters to work (ruleParams).

The function must revert in case of not meeting the requirements imposed by the rule. In this case, given that to reach the point of editing a post, the post must have been created before, we can assume that the author of the post met the conditions to create it, and do not impose any restriction on the edit operation. As a good practice, we revert for unimplemented rule functions, as it is safer in case the rule becomes accidentally applied.

contract GroupGatedFeedRule is IFeedRule {
    // . . .
    function processEditPost(        bytes32 configSalt,        uint256 postId,        EditPostParams calldata postParams,        KeyValue[] calldata primitiveParams,        KeyValue[] calldata ruleParams    ) external override {        revert Errors.NotImplemented();    }

Next, implement the processDeletePost function. This function is invoked by the Feed contract every time a Post is trying to be deleted, so then our custom logic can be applied to shape under which conditions this operation can succeed.

The function receives the configuration salt (configSalt), so we know which configuration to use, the ID the Feed assigned to the Post (postId), an array of key-value pairs with the custom parameters passed to the Feed (primitiveParams), and an array of key-value pairs in case the rule requires additional parameters to work (ruleParams).

The function must revert in case of not meeting the requirements imposed by the rule. In this case, given that to reach the point of deleting a post, the post must have been created before, we can assume that the author of the post met the conditions to create it, and do not impose any restriction on the delete operation. As a good practice, we revert for unimplemented rule functions, as it is safer in case the rule becomes accidentally applied.

contract GroupGatedFeedRule is IFeedRule {
    // . . .
    function processDeletePost(        bytes32 configSalt,        uint256 postId,        KeyValue[] calldata primitiveParams,        KeyValue[] calldata ruleParams    ) external override {        revert Errors.NotImplemented();    }

Finally, implement the processPostRuleChanges function. This function is invoked by the Feed contract every time an account makes a change on the Post Rules of a Post it authors, so then our Feed rule can define if this change must be accepted or not.

The function receives the configuration salt (configSalt), so we know which configuration to use, the ID the Feed assigned to the Post which rules are being changed (postId), the array of rules changes (ruleChanges), and an array of key-value pairs in case the rule requires additional parameters to work (ruleParams).

The function must revert in case of not meeting the requirements imposed by the rule. In this case, the rule is not focused on controlling Post Rules changes, so we revert as a good practice to avoid unintended effects on if the rule gets applied accidentally.

contract GroupGatedFeedRule is IFeedRule {
    // . . .
    function processPostRuleChanges(        bytes32 configSalt,        uint256 postId,        RuleChange[] calldata ruleChanges,        KeyValue[] calldata ruleParams    ) external override {        revert Errors.NotImplemented();    }}