Support Deleting Tweets

[IstoraMandiri]

What’s missing?

The ability to delete existing tweets.

Why?

Currently the only way to delete a published tweet is for the owner of the account to remove it.

If a twitter account is maintained primarily by a twitter-together repo, there should be a way to delete tweets from this repo, in case there's a mistake or a retraction needed.

How?

To maintain a record of deletions, perhaps a field to flag .tweet files with deleted: true, or deleted: [tweet url].

[gr2m]

I feel this falls outside of the scope of this action. But I'm happy to leave the issue open and to see if there is broader interest. Personally, I didn't run into the need to delete a tweet once. And if it came to it, I'd login into the account directly and delete it, instead of using the action.

[MattIPv4]

My concern here would be less with scope, but more with a conventional way to represent this. What feels conventional would be that the action detects a .tweet file being deleted, but .tweet files don't keep track of the tweet they produced.

[IstoraMandiri]

One way to implement this is to include a new delete option in FrontMatter. Instead of modifying an existing .tweet, contributors would just add a new .tweet with just following content.

---
delete: https://twitter.com/xxx 
---

This both preserves history and means the action can hook into the same "git added a file" trigger without having to look for updates to existing tweets each time the action runs.

Users can come up with their own naming schemes such as:

221004-[delete]-my-tweet.tweet
221004-my-tweet.tweet
221005-hello.tweet

or

hello.tweet
my-tweet.tweet
my-tweet-delete.tweet

[MattIPv4]

I agree that adding a frontmatter property to delete tweets would work, but I fear this does not feel like the canonical solution in the land of git, where files are versioned controlled. As an end user, my default would be to expect to be able to delete a tweet file, and it'd delete the tweet.

[IstoraMandiri]

If the action relied only deleting the file, how would it know which tweet to delete, given there is no reference to a Tweet ID?

[MattIPv4]

Yes, that was the exact dilemma I posed 4 comments above.

[IstoraMandiri]

I don't see the dilemma; if the canonical git land solution just isn't possible, shouldn't it be ruled out?

[MattIPv4]

I never said it wasn't possible, and I don't think it is impossible. There are ways in which one could track the associated tweet ID with a tweet file.

[IstoraMandiri]

In what ways might it be tracked?

[MattIPv4]

You could lean on artifacts to store tweet IDs (though there'd be a theoretical 90 day limit if there were no activity), or the action could push through a follow-up commit that associates the ID once tweeted.

[IstoraMandiri]

... or the action could push through a follow-up commit that associates the ID once tweeted.

This makes a lot of sense, and would also help keep track of published tweets.

Something like adding a comment or additional field to the .tweet's Front Matter?

Or, probably less ideally, stored in some kind of separate key-value store?

[MattIPv4]

Yah, I would envision this probably just pushing a new id property into the .tweet file frontmatter once published (or storing kv data via artifacts, but this seems problematic due to the retention etc.)

[IstoraMandiri]

A couple of considerations with this approach though.

Can actions publish directly to a protected branch, or would this additional commit need to go through review itself?

How can a deletion be re-triggered if something goes wrong on the github action side or twitter glitches out during the action, since the file is already deleted?

[MattIPv4]

Can actions publish directly to a protected branch, or would this additional commit need to go through review itself?

Having read through https://github.com/orgs/community/discussions/25305, it looks like Actions cannot be configured to bypass branch protection, which sucks.

I think the closest we'd be able to get is the action opening a PR to add the ID in once the tweet has been sent, and a human could then merge that as they see fit (though we could probably add a setting to allow direct pushing for folks that aren't using branch protection rules).

How can a deletion be re-triggered if something goes wrong on the github action side or twitter glitches out during the action, since the file is already deleted?

Re-running the action run.

[IstoraMandiri]

I think the closest we'd be able to get is the action opening a PR to add the ID in once the tweet has been sent, and a human could then merge that as they see fit (though we could probably add a setting to allow direct pushing for folks that aren't using branch protection rules).

While possible, this is less than perfect from a maintenance POV, especially if more than one approval is required.

In any case, for audibility, I can imagine that many projects may want to retain a clear history of which tweets have been made in the past, even if deleted, just by glancing at the directory structure rather than the whole git commit history. Seemingly this cannot be achieved with a pure canonical git approach.

Another potentially easier to implement and use solution, that mimics a familiar pattern, is to have a trash or deleted-tweets folder. In a single commit, users could move tweets they want to delete into this folder, by doing so gets picked up by the action, which can then read the id field, which was added in the same commit to tell the action which tweet to delete. The tweets folder remains in sync, and the trash folder keeps a record of deleted tweets.