FIP: Edit Casts using a Bitemporal Strategy

[christopherwxyz]

FIP: Edit Casts using a Bitemporal Strategy

Title: Edit Casts using a Bitemporal Strategy
Type: Implementation FIP
Authors: @christopherwxyz

Abstract

This FIP suggests a way to "edit" Casts without actually changing the original Cast. We'll use a bitemporal strategy to introduce a "Superseding Cast" that acts as an update or edit to an existing Cast.

Problem

Once data is added to the network, it's permanent. Traditional systems can edit or modify data directly, but we can't do that here. That's why we need a creative way to "edit" Casts. A bitemporal strategy allows us to create new Casts that serve as updates to existing ones.

Specification

What's Bitemporal?

Bitemporal data keeps track of two kinds of time:

• Valid Time: When is this data true in the real world?
• Transaction Time: When did this data get added to the network?

Changes to Cast CRDT

New Type of Message: SupersedingCastAdd

We're introducing a new message type called SupersedingCastAdd. This message will have:

1. original_cast_hash: The identity of the Cast a signer wants to update.
2. new_data: The updated information or data.
3. valid_from: When does this update start being valid?
4. valid_to: When does this update stop being valid? (This is optional; with a valid_to, then no successful "edit" will settle as an update, and succeeding Superseding Casts will be rejected.)

Rationale

Other approaches, like directly updating Casts or using versioning, break the immutability principle. The bitemporal strategy respects the existing rules and adds the flexibility to update Casts, including within only a specific timeframe.

Release

1. Implement and test the SupersedingCastAdd type.
2. Roll out the feature in a minor update.
3. Educate client developers through documentation and tutorials.

Rules to Check:

• The person sending the message (m.signer) must be an allowed signer for that Cast.
• The SupersedingCastAdd is only valid if an original Cast with the original_cast_hash exists. We do not want to accept Superseding Casts if the network has pruned it from state. Therefore, operators may prune Superseding Casts along with the original cast as part of garbage collection or similar hub maintenance.
• Without a valid_to, there cannot be another future respected superseding cast. This could be useful for ensuring a more permanent message if the caster's keys are compromised.
• A message's valid_from may not occur before the original message timestamp. Hubs should reject messages that precede the original.
• Succeeding Superseding Casts must point to the latest Superseding Cast.

What If Two Updates Conflict?

If two SupersedingCastAdd messages conflict:

1. Keep the one with the earlier timestamp. We do not want clients to show the same edit twice.
2. If they're both at the same time, keep the one that comes first when you sort them alphabetically.

How to Find These Casts

When you look up a Cast, you should get the latest SupersedingCastAdd along with the original Cast. This shows the full history of that Cast.

Will This Work With Old Specifications?

Yes, older implementations that don't use this new feature will still work but won't recognize the "edit" messages.

What's Next?

1. Ensure that it is fast to look up a Cast and its updates.
2. Figure out when to remove prune updates to save space or when the original cast is pruned.

Sample Messages in JSON Format

Original Cast Message

{
  "type": "CastAdd",
  "hash": "abc123",
  "data": {
    "content": "Hello, world!",
    "timestamp": "2023-09-02T12:34:56Z"
  },
  "signer": "user1"
}

Superseding Cast Message

{
  "type": "SupersedingCastAdd",
  "hash": "xyz789",
  "data": {
    "original_cast_hash": "abc123",
    "new_data": "Hello, updated world!",
    "valid_from": "2023-09-03T12:00:00Z",
    "valid_to": "2023-09-04T12:00:00Z"
  },
  "signer": "user1"
}

Another Superseding Cast Message (Conflict)

{
  "type": "SupersedingCastAdd",
  "hash": "lmn456",
  "data": {
    "original_cast_hash": "abc123",
    "new_data": "Hello, another updated world!",
    "valid_from": "2023-09-03T12:01:00Z"
  },
  "signer": "user1"
}

Handling Conflicts

In this case, the message with hash lmn456 will not supersede the one with hash xyz789 since it has a newer valid_from timestamp.

Additionally, the lmn456 cast is not a permanent "edit", as it lacks a valid_to timestamp.

Conclusion

This bitemporal strategy lets us "edit" Casts while keeping the original data untouched. It makes our system more flexible without breaking any of the existing cast rules.

[haardikk21]

I'm a fan of the idea of having an Edit option available on FC. A couple thoughts:

1. I believe the conflict resolution should be the other way around. Since lmn456 and xyz789 are both attempting to update the same original cast, the "earlier" one should get priority rather than the "newer" one. Chronologically a newer edit (lmn456) must have original_cast_hash = xyz789.

2. Are edits considered full casts by themselves? With the move to mainnet - one "storage slot" on Farcaster gives you the ability to post a certain amount of casts before you have to purchase another storage slot. Since edits are going to take up ~the same space as a new cast on the hubs, either they should be treated as a cast themselves or have a reasonably low limit (though this is less desirable from a Hub POV) on how many times a cast can be edited

[christopherwxyz]

1. Agreed. I revised the language regarding earlier.
2. Edits are casts, but messaged differently. We want it to consumer equivalent amount of space within the network as it is displayed equivalent to a cast.

[vrypan]

What about reactions and replies? If I'm not mistaken, they reference the CastId of the "replaced" cast. How should clients handle them?

What if the original cast is deleted after SupersedingCastAdd has been sent? How is this case handled?

[christopherwxyz]

1. Reactions and replies should remain with the original cast address. The client should retain the original cast address, and edits should replace data along the successive lineage of the cast. Perhaps we could sum all reactions and replies to the original cast, and I would appreciate feedback if that's more preferable.
2. In the "Rules to Check":

The SupersedingCastAdd is only valid if an original Cast with the original_cast_hash exists. We do not want to accept Superseding Casts if the network has pruned it from state. Therefore, operators may prune Superseding Casts along with the original cast as part of garbage collection or similar hub maintenance.

[varunsrin]

Reactions and replies should remain with the original cast address

i think this is undesirable . how do you handle the case where you say "i love cookies" and then edit it to "i love $something_offensive". now all these reactions are endorsements of your new position.

in general, editing text change change semantics and that should break all relationships or you have trust problems by default that clients now have to go and solve.

[varunsrin]

You can built an Edit Cast feature at the client level by simply deleting and re-adding a new cast under the hood. To the user, this would look identical to the edit functionality offered on Twitter and other social networks.

It's a little more noisy (add + delete + add) but achieves the same user experience without increasing the complexity of the set logic.

[christopherwxyz]

Clients may offer an edit experience today, yes. However, in this strategy, no deletions are needed, and a Superseding Cast provides a superior experience at cost of some logic and client orientation.

Additionally, a bitemporal strategy permits clients to "complete" edits after a period of client time. For example, you have 1 hour to edit casts, after which the cast is permanent. If a caster's identity were compromised under the above model, then a caster's history can easily be understood as unedited should they provide a valid_to to any superseding cast. If we were to assume an add/delete/add standard, then anyone could "revert" an edit by an add/delete/add/delete/add.

[varunsrin]

hmm, my take is that this is a lot of complexity for a feature that is already supported by the current design. i'm not sure what actual user or developer benefits this change brings.

a Superseding Cast provides a superior experience at cost of some logic and client orientation.

can you elaborate more on what is better about the experience in this case?

For example, you have 1 hour to edit casts, after which the cast is permanent.

anyone can choose a timestamp in the past right? so i'm not sure if you can enforce this

If we were to assume an add/delete/add standard, then anyone could "revert" an edit by an add/delete/add/delete/add.

you can't add the same cast back once deleted, since the crdt ensures that the remove always overwrites the add. you have to make a new cast with a different timestamp and hash to add it back.

[varunsrin]

Closing due to inactivity