FIP: Application Identifiers

[varunsrin]

Problem

Apps can publish messages on behalf of users by asking them to approve a Signer, which is a public key that they control. The current process has a few limitations:

1. When approving the signer, the user has no trustworthy information about the app requesting the signer.
2. After the signer is approved, the rest of the network has no trustworthy information about the app using the signer.

If it were possible to know the identify of the application that a signer was assigned to, we can now create reputation systems for applications. This helps users and other apps on the network easily identify and avoid malicious applications.

Proposal

• Apps may register an fid and establish an identity including a name, profile picture and other information.
• When requesting a signer, apps create an EIP-712 signature that contains userFid, appFid and signerPubKey and sends it to the user's wallet application
• When requesting signer approval, the user's wallet application can verify the signature and then display metadata about the application to the user, so that they know who they're authorizing with the signer.
• When publishing the signer on-chain, the user's wallet applicaiton includes this signature in the metadata field.
• Hubs should listen to and store this metadata.

Metadata

The metadata field must have the following information:

• A type byte, set to 1 for now
• The fid of the application, which is necessary to validate the signature
• The EIP-712 signature

Additional Notes

• When doing the mainnet migration, Warpcast should request a signer and set all this correctly

[cboscolo]

One concern I have of this FIP is how it might impact anonymity when using apps for direct casts. (e2ee private messaging) If direct casts could be tracked to the the app, there would be hesitancy for users to try it because the anonymity would set would shrink to that app's users.

[varunsrin]

as proposed, if you want the key to be anonymous you don't have to set the metadata

[sds]

Given we are going to migrate to L2 soon, perhaps we should make the metadata field required and define its own protobuf to store this information?

This way we can more gracefully evolve its use over time, and encourage its use.

Can always have the default create a "plaintext" metadata field which is just raw text, defaulting to empty. This way apps can still "opt-in" to the stronger verification.

Do we currently have a limit on how long the metadata can be for an on-chain signer?

[varunsrin]

1. is there a benefit to using protobufs here versus a more common serialization form that doesn't require libraries?
2. we could require it, but since we can't validate it's correctness on chain, you could just put dummy data in there - so i think it's better to give people the optionality to not set anything instead of having a bunch of dummy data that everyone has to read.
3. there's no limit right now, but that might be a good thing to add in, since L2 storage is very cheap

[varunsrin]

we should probably validate the metadata somehow

[horsefacts]

After discussion with @varunsrin, @sds, @sanjayprabhu, and @deodad, I think validating metadata signatures onchain in KeyRegistry._add rather than emitting metadata in an event for offchain validation is a good approach. It has a few benefits:

• Prevents the accidental addition of garbage metadata.
• Prevents the intentional addition of misleading metadata.
• Prevents pre-populating keys for unimplemented schemes.
• Prevents emitting onchain events that are later ignored by hubs, keeping the onchain event history and hub history in sync.

We can preserve flexibility to introduce future metadata types with different fields or validation schemes by delegating validation to a contract with a defined interface.

Here's a draft Solidity spec for onchain metadata validation:

// Interface for all metadata validators
interface IMetadataValidator {
    function validate(
        uint256 userFid,
        bytes memory signerKey,
        bytes memory metadata
    ) external returns (bool);
}

// Concrete contract for Type 1, App ID specific metadata
contract AppIdMetadataValidator is Signatures, EIP712 {
    // Custom struct for this metadata type.
    struct AppId {
        uint256 appFid;
        address appSigner;
        bytes signature;
    }

    constructor() EIP712("Farcaster MetadataValidator", "1") {}

    // EIP-712 typehash for this metadata type
    bytes32 constant _SIGNER_METADATA_TYPEHASH =
        keccak256("AppId(uint256 userFid,uint256 appFid,bytes signerPubKey)");

    function validate(
        uint256 userFid,
        bytes memory signerKey,
        bytes memory metadataBytes
    ) external returns (bool) {
        // Decode context specific metadata for this metadata type
        AppId memory appId = abi.decode(metadataBytes, (AppId));

        // Verify that the signer owns the appFid
        if (IdRegistry.idOf(appId.appSigner) != appId.appFid)
            revert("Signer must own app FID");

        // Verify signature over userFid, appFid, signerKey
        return
            IdRegistry.verifyFidSignature(
                appId.appSigner,
                appId.appFid,
                _hashTypedDataV4(
                    keccak256(
                        abi.encode(
                            _SIGNER_METADATA_TYPEHASH,
                            userFid,
                            metadata.appFid,
                            signerKey
                        )
                    )
                ),
                sig
            );
    }
}

// Update KeyRegistry to 1) register validators and 2) call the registered
// validator when metadata is present.
contract KeyRegistry {
    struct Metadata {
        uint8 typeId;
        bytes metadata;
    }

    mapping(uint8 typeId => IMetadataValidator) public validators;

    function _add(
        uint256 fid,
        uint32 scheme,
        bytes calldata key,
        Metadata calldata metadata
    ) internal {
        KeyData storage keyData = keys[fid][key];
        if (keyData.state != KeyState.NULL) revert InvalidState();

        IMetadataValidator validator = validators[metadata.typeId];
        if (validator == IMetadataValidator(0)) revert("Invalid typeId");
        bool isValid = validator.validate(fid, key, metadata.metadata);
        if (!isValid) revert("Invalid metadata");

        keyData.state = KeyState.ADDED;
        keyData.scheme = scheme;
        emit Add(fid, scheme, key, key, metadata);
    }

    function setValidator(
        uint8 _type,
        IMetadataValidator _validator
    ) external onlyOwner {
        type[type] = _validator;
    }
}

[varunsrin]

this proposal looks great, i think its worth merging into the onchain signers proposal

[Hmac512]

I've identified a few key considerations:

Lack of Differentiation in Association Types

There exists a challenge in distinguishing between these two distinct scenarios:

1. When an app exercises custodial control over a delegate signer.
2. When a user maintains non-custodial control over a delegate signer.

The importance of scenario 2 becomes evident in building confidence for an app that provides a non-custodial client. To illustrate, if a vulnerability arises in the direct cast mechanism of a specific client, it remains valuable to associate the app's reputation with its non-custodial mode. This way, other casters can readily identify and avoid signers connected to the client.

Irrevocability of Associations for Apps

A significant constraint emerges regarding an app's ability to retract such associations autonomously. Specifically, an app lacks the means to dissolve this association without obtaining userFid's consent. Consequently, the app is unable to rotate the signers employed for its users' FIDs.

Consider a scenario analogous to popular communication platforms like Telegram or Discord. Imagine a userFid reported by moderators for engaging in spam or scams. While the app may desire to ban that userFid, this objective becomes unattainable if the userFid's participation is necessary to disband the association.

App shared storage

One potentially intriguing application for this app-associated signer is found within the concept of a shared storage umbrella. Under this model, the app procures a substantial amount of storage, which is then shared among its users as a communal resource.

However, this setup introduces a dimension to the app's authority in relation to association revocation, particularly if this feature carries significance. A practical instance could be if a userFid decides to terminate their subscription.

These considerations underscore the intricate nature of association dynamics within the described framework.

Potential Implementation through ERC1155:

Just throwing it out there

A plausible approach for implementing the delegated signer functionality, assuming the FID is treated as an NFT, is to consider the use of ERC1155.

In essence, ERC1155 builds upon ERC721 but introduces the concept of sub-NFTs under each NFT (an item owned by a character in a game). These sub-NFTs could effectively symbolize the KeyRegistry entities.

Ownership of a sub-NFT would translate to control over a corresponding signer. Such an arrangement would facilitate a clear distinction between the various forms of delegate signer associations mentioned earlier.

To establish a sub-NFT's ID, the formula keccak256("appFid.userFid") could be employed. This method would offer a straightforward means of authorizing the opposite party to undertake association revocation. By incorporating their FID in the ID construction, they would be granted specific rights to execute designated actions.

[varunsrin]

There exists a challenge in distinguishing between these two distinct scenarios:

When an app exercises custodial control over a delegate signer.
When a user maintains non-custodial control over a delegate signer.

I don't understand the difference between them - if the app custodies the signer, and the user can call the app to produce messages, isn't the user non-custodial?

Consider a scenario analogous to popular communication platforms like Telegram or Discord. Imagine a userFid reported by moderators for engaging in spam or scams. While the app may desire to ban that userFid, this objective becomes unattainable if the userFid's participation is necessary to disband the association.

The app controls the key - in theory, its responsible for anything it produces and can destroy the key at any time. So I think its reasonable to permanently associate the app with the key.

[Hmac512]

I don't understand the difference between them - if the app custodies the signer, and the user can call the app to produce messages, isn't the user non-custodial?

I threw my writing in ChatGPT3 to improve, and I think it made things more confusing.

The Warpcast backend manages the ed25519 key that signs my messages for me, so the app controls the key.

If there was a mode where the ed25519 key was stored on my device, then it would be non-custodial.

These situations are different. There are messages I would never send you over email, but I would over Signal. What I am saying is that in this proposal there isn't a way to distinguish if a signer is controlled by the user or the app.

A app with a non-custodial signer support may still have features like managing my feed, push notifications etc where associating the app w/ the signer could still be valuable to build reputation. Apps might implement non-standard functionality on-top of the forecaster protocol. So this app/signer association could be used a way to check if a signer supports a feature.

Am I correct in assuming the intended purpose of this proposal is for app's backend to control the signers for their users?

The app controls the key - in theory, its responsible for anything it produces and can destroy the key at any time. So I think its reasonable to permanently associate the app with the key.

What if there is a data leak in the app's systems? As it is now the app would have to tell all users to go revoke those signers.

This app/signer association could be used by developers to implement functionality beyond the impetus for this proposal (https://hackernoon.com/affordance-in-software-design-12cc0d9d2721).

Don't underestimate a programmer's ability to find creative ways to consume an API.

Allowing an app to revoke it's on-chain relationship with a signer would yield a more rich landscape of possibilities.

Assuming an app supports non-custodial signers (stored on user devices):

An app might build a special indexer just for its users and what they follow. So If an app wants to ban a user for some reason, it would simplify things if they can revoke the signer on-chain and use the emitted KeyRegistry events much like hubs do.

---

I might be thinking far beyond the scope of this proposal, but just pointing out what I think are limitations.

[Hmac512]

Also with largeBlob storage in passkeys, storing keys on user devices will be much easier.

Also removes the headache of managing a lot of keys for an app.

[varunsrin]

Closing this discussion. App identifiers were added to FIP-7 and finalized.