Managing Deleted Records

[ngerakines]

I want to determine best practices for managing deleted posts and references. Currently, on Smoke Signal, an event has an AT-URI, and RSVPs reference the AT-URI and CID as strong references. This allows users to show that they RSVP'd to an event or, more importantly, a version of the event at a time.

In practice, I strongly discourage events from being deleted. Even a canceled, postponed, or flop should exist as a record and for historical purposes. That said, there are very practical reasons to delete those records.

My current thought is that an event record is actually a union of two types: an event definition or a tombstone definition.

Is there any reason not to implement this type of union structure? Are there any relevant lessons from your development of the post-lexicon?

[DavidBuchanan314]

I proposed something a bit like this way back, to make threads containing deleted posts easier to navigate. But in retrospect I think it's more complexity than it's worth.

What do you concretely gain from leaving a tombstone, as opposed to just nothing? In the my thread example, the purpose of the tombstone would have been to maintain the reference to the parent post.

[ngerakines]

I think that my goal is to improve the overall user experience of having someone RSVP to an event that has been deleted vs one that is just "gone".

In this case, gone can mean a few things:

• The event was deleted
• There was an intake error and the real event couldn't be processed
• The event existed at one point but was deleted
• The event was moderated

I'm trying to reduce the room for interpretation by the user and offer some explanation as to why the thing they RSVP'd to isn't there.

[bnewbold]

Seems like it could be an app-by-app thing. For bsky, we wanted deleted posts to bias towards "just gone" with fewer traces, though references from other repos persist.

For smokesignal, doing a state field on events which can have "cancelled" and even "deleted" as an explicit state would make sense to me? Or maybe "tombstone" as the name of state to reduce confusion from a record which has actually just been deleted.

You'll pragmatically have to support the situation of an event record being "just gone" even if your app never takes that action: i'd expect that there will be general-purpose atproto repo cleanup apps which will let folks create/update/delete records in a generic way, and some folks might just delete random old records that they can't remember the utility of; for precedent of this, there are a lot of "social media scrubber" apps that people use when elected to office or whatever.

A union of two types would be one way to get at this. It would feel to me like a layer of abstraction/indirection on the record themselves I wouldn't love. On the other hand, it would make it easier to make more fields "required" even if the event is "tombstoned", which could be good for schema design.

[ngerakines]

Yeah, currently, the record attribute only supports object types. To support that, a lexicon change would be necessary.

Personally, I think this is really appealing and also comes in clutch for versioning and backward compatibility

{
  "lexicon": 1,
  "id": "events.smokesignal.calendar.event",
  "defs": {
    "main": {
      "type": "record",
      "description": "Record containing a Smoke Signal event.",
      "key": "tid",
      "record": {
        "type": "union",
        "refs": [
          "events.smokesignal.calendar.event#v3",
          "events.smokesignal.calendar.tombstone"
        ]
      }
    },
    "v3": {
      "type": "object",
      "required": [],
      "properties": {}
    }
  }
}

[tom-sherman]

I like the simplicity of deletes in their current form and would vote against complicating them in this way.

The practical benefits to user experience can be implemented at the AppView level, I don't see the benefits of representing this in the data model.

[bnewbold]

I don't think it is a blocker in this particular case, but as a side-point, an important philosophy/value we try to stick to is making it possible for independent folks to set up a new AppView (for whatever lexicons) at a later point in time which 1) backfills all existing public data in the network and 2) comes as close as possible to having the same behaviors/appearance as any existing AppViews.

The app.bsky lexicons/appview isn't perfect about this. "Invalid future timestamps" aren't re-written to sortAt if the future timestamp is no longer in the future. I think there might be subtleties around ordering of likes or ordering of follows. "Nullified" labels might not be recorded as such. And private/preference state (like notification status) is a different beast. But overall a backfilled appview should mostly be inter-changable with an old one; we have actually replaced our production appviews with backfilled instances more than once and it seems like basically nobody noticed.

This is most a political-economy thing of wanting it to be possible for "new entrants" to come in on an equal footing, without large degradation to user experience. It is partially a resiliency and operational thing, where it is nice to not have old state be too "precious".

I think giving good ergonomics around deleted events maybe doesn't hinge on this line of argument, and we don't want to create additional burdens on independent devs, or be too prescriptive (it is an open protocol, use it as you think is best!), but you are both thoughtful and might be interested in this perspective.