FIP: Signer revokes only impact future messages

[aditiharini]

Title: Signer revokes only impact future messages
Type: Implementation FIP
Authors: @aditi, @sanjay

Abstract

When a signer is revoked, Snapchain currently revokes all messages signed by that signer and rejects any new messages signed by it. We propose updating Snapchain to ONLY reject any new messages signed by that signer. Any messages that were signed by a signer while it's "active" (between when the Add and Remove message came in for it) will remain on the protocol.

Problem

If a user uses multiple clients, then stops using one and revokes its signer, the user loses all data that was produced by that signer. This is only potentially desirable in the case where the signer was malicious, but this is not the common case.

Specification

Snapchain will stop revoking existing messages upon receiving Remove(uint256 indexed fid, bytes indexed key, bytes keyBytes) events from the KeyRegistry.

Currently, the following messages would be processed as follows. Node, messages and events are specified in shorthand.
M1: CastAdd({fid: 1234, text: "hi", signer: X}) -> events: [MergeMessage(M1)]
M2: CastAdd({fid: 1234, text: "bye", signer: Y}) -> events: [MergeMessage(M2)]
M3: SignerRemove({fid: 1234, key: X}) -> events: [RevokeMessage(M1), MergeOnChainEvent(M3)]
M4: CastAdd({fid: 1234, text: "hi again", signer: X}) -> events: [MergeFailure(M4)]

Messages retained: [M2, M3]

With the new change, the same messages would be processed as follows
M1: CastAdd({fid: 1234, text: "hi", signer: X}) -> events: [MergeMessage(M1)]
M2: CastAdd({fid: 1234, text: "bye", signer: Y}) -> events: [MergeMessage(M2)]
M3: SignerRemove({fid: 1234, key: X}) -> events: [MergeOnChainEvent(M3)]
M4: CastAdd({fid: 1234, text: "hi again", signer: X}) -> events: [MergeFailure(M4)]

Messages retained: [M1, M2, M3]

Client-facing impact

Clients who want to take some client-side action (e.g. hide/delete) on all messages associated with a revoked signer will need to query their own DB for all messages associated with the signer when they see a signer revoke on the Snapchain event stream. This is easy to support for clients who use the Shuttle schema.

Rationale

Why not add a separate mechanism for deleting all messages associated with a signer in Snapchain?

This is possible, but adds complexity to the protocol. It’s still possible to delete messages that were signed by a malicious signer with a valid signer.

Why not communicate an event to clients indicating which messages are associated with the revoked signer even if those messages are not removed from the protocol?

This saves some amount of work for clients in querying for messages associated with the signer when it's revoked but

• Our expectation is that most clients do not actually want to remove/hide all messages associated with the revoked signer
• Emitting the existing HUB_EVENT_TYPE_REVOKE_MESSAGE events will be awkward for clients because in all other cases where this event is emitted the client actually wants to delete the associated data. We will need to extend the data model to create a new event type for this specific case.
• Emitting a ton of events every time a signer is revoked is undesirable from a performance perspective for both clients and for Snapchain. If a widely used client gets compromised and tells everyone to revoke their signers, it may cause performance-related issues if we emit an event for every single message that was associated with any of these signers.

Release

This change will be effective as of Snapchain version 0.5.0 which will be released on [date TBD] with changes taking effect one week later. The new logic will apply to signer revokes with block timestamp > [date TBD] on OP Mainnet. For prior signer revokes, there is no way to recover revoked messages and no action will be taken.

[vrypan]

In the example, I would add that the end state is [M2] in the first case and [M1,M2] in the second one.

[aditiharini]

Good point, amended.

[christopherwxyz]

This proposal makes a lot of sense from a UX perspective. The current behavior of revoking all historical messages when a signer is removed is unnecessarily punitive for the common case where users simply want to stop using a particular client (s/o @blockheim).

It also aligns to forward permission primitives where we stop future messages but preserve historic ones. Users shouldn't lose months or years of content just because they've moved away from a specific app or device.

One consideration: would it be worth adding some kind of tombstone on messages or a separate method for the rare cases where users DO want to purge all historical messages from a compromised signer? Users can still delete individual messages with a valid signer if needed, but let's say messages were revoked. A client would want to know which of these were affected originally. It preserves the state but warns clients.

[aditiharini]

Good point. I've added some discussion around this in the Rationale section. Let me know if you have any additional thoughts on this.

[vrypan]

The old system was binary: messages were either signed by a valid signer or not.

The proposed system has (in practice) a signer lifespan: A signer has a start- and end-of-life.

I think it would be a good idea to update the documents to reflect the new concept, that signatures are valid during the signer's lifespan (ie. the blocks where the SIGNER_ADD and the block where the SIGNER_REMOVE were recorded).

[vrypan]

I would actually make this the tldr of the FIP, and rename it to "Signers Lifespan"

[aditiharini]

Any messages that were signed by a signer while it's "active" (between when the Add and Remove message came in for it) will remain on the protocol.

That's a nice framing-- added ^^ to the "Abstract". "Signers Lifespan" feels a bit vague to me as the title because that phrase doesn't make sense before understanding what the change actually is.

[nuconomy]

+1 for the idea.

I have so many signers on my account, I couldn't even tell you what half are anymore. Would like to revoke all to have one or two clean/known signers but don't want to lose legitimate casts.