You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I love the idea of deleting old tweets and likes. After running the cleanup for my Twitter account, I received an email from Keybase.io about a broken proof. The thing is, Keybase depends on a tweet with a special text to establish a (cryptographically) verified link between a Keybase and a Twitter account, see e.g. here: https://twitter.com/bajtos/status/1257653404383555585
I am proposing to add a new sync option allowing users to specify a list of tweet ids to never delete. For example:
I have briefly considered using a special hashtag like #pin to mark tweets to be preserved, but that won't work for Keybase, that requires the tweet to have the exact content provided by the app.
The text was updated successfully, but these errors were encountered:
we just need a good name for the option. keep_statuses sounds like a boolean flag, but it is an array of strings.
Makes sense 👍
Considering that we already have delete_older_statuses, I think either preserve_status_ids or keep_status_ids would be a good name. I think I slightly prefer preserve_status_ids.
I love the idea of deleting old tweets and likes. After running the cleanup for my Twitter account, I received an email from Keybase.io about a broken proof. The thing is, Keybase depends on a tweet with a special text to establish a (cryptographically) verified link between a Keybase and a Twitter account, see e.g. here: https://twitter.com/bajtos/status/1257653404383555585
I am proposing to add a new sync option allowing users to specify a list of tweet ids to never delete. For example:
I have briefly considered using a special hashtag like
#pin
to mark tweets to be preserved, but that won't work for Keybase, that requires the tweet to have the exact content provided by the app.The text was updated successfully, but these errors were encountered: