# blurp

[![Build Status](https://build.coopcloud.tech/api/badges/decentral1se/blurp/status.svg?ref=refs/heads/main)](https://build.coopcloud.tech/decentral1se/blurp)

> 🚧 Status: **ALPHA SOFTWARE** 🚧

A [GoToSocial](https://docs.gotosocial.org) status deletion tool. Given that this can completely destroy your status history, I'm not sure I really recommend it. However, it does Work For Me ™ `blurp` might be useful to you while we're waiting for [`#1442`](https://github.com/superseriousbusiness/gotosocial/issues/1442) to get implemented.

## Install

It's ~ 3 MB in size. Only `linux/amd64` is supported atm.

```
curl https://git.coopcloud.tech/decentral1se/blurp/raw/branch/main/blurp -o blurp
chmod +x blurp
```

## Field notes on how deletion works in GoToSocial

> 🟡 How this exactly works seems to depend both on a shifting development sands
> of GtS (**ALPHA SOFTWARE** etc.) but also how other Fediverse softwares deal
> with deletion (e.g. [Mastodon](https://oisaur.com/@renchap/112882201793431045),
> also shifting sands). This is a best-effort explanation and might quickly be
> out of date. Help welcome! 🟡

* `blurp delete` will get you rate limited by your own instance. I temporarily solved this by [turning off rate limiting](https://docs.gotosocial.org/en/latest/api/ratelimiting/#can-i-configure-the-rate-limit-can-i-just-turn-it-off), running the command and then turning rate limiting back on again. I could probably implement some backoff in the code but this is just easier.

* `blurp delete` will remove statuses but not media attachments *immediately*
  for **local media**. Remote media is removed immediately. Unattached local
  media is removed the next time the media cleaning job runs.

> if your post gets boosted or otherwise transmitted to a server yours doesn't
> know about and then you delete, you'll only send deletes to servers yours
> knows about, so copies of your post will remain on those other third party
> servers. so you can't rely on a delete reaching everywhere your post has gone
> even if you assume that servers will honour delete requests. but nonetheless,
> a best effort to remote delete will happen - `sentynel`

> and more servers should do what we do, which is when we attempt to refresh a
> status but found out it has been deleted we remove it - `kim`

* There is (afaict) an ongoing plan to implement "status tombstones" in GtS so
  that when a deleted status is requested, it will return `410 gone` and then
  the requester will know it is time to delete any local copies.

## Delete stuff 🔥

> 🟡 Be aware, "delete requests" will be sent to followers when you delete your
> statuses. This means you can end up spamming your fellow fedizens. It might
> be nice to run `blurp` at some "less busy" time period (but yanno, timezones,
> so 🤷) and or consider some form of rate limiting (**TODO**:
> [`#3`](https://git.coopcloud.tech/decentral1se/blurp/issues/3) 🙃) 🟡

You'll need to log in first:

```
blurp login -u foo@bar.zone
```

You might want to archive stuff locally before deleting *all the things*:

```
blurp archive
```

See `./archive` for every status (favourited, pinned, boosted, bookmarked etc.)
connected with your account. All media attachments are downloaded alongside the
status. Status content is dumped as a JSON file.

> 🔴 **DANGER ZONE** 🔴

To delete all statuses older than *2 weeks*:

```
blurp delete
```

> 🔴 **DANGER ZONE** 🔴

## ACK

Made possible by the good work of [slurp](https://github.com/VyrCossont/slurp).

# License

<a href="https://git.coopcloud.tech/decentral1se/blurp/src/branch/main/LICENSE">
  <img src="https://www.gnu.org/graphics/agplv3-with-text-162x68.png" />
</a>
