# 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 management tool.

`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
```

## Delete stuff 🔥

You'll need to log in first:

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

You can archive all your account statuses:

```
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
```

It is **HIGHLY RECOMMENDED** to pass `--dry/-d` as a dry run before actually
deleting stuff or real. This lets `blurp` tell you what it will actually do
before doing it. Avoid heartache, always `--dry`.

You can use `--weeks/-w` to supply a value for "number of weeks". If you need
to send less requests, say, 1 request every 3 seconds, you can pass `-r 3`. See
`--help` for more.

> 🔴 **DANGER ZONE** 🔴

## 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` would easily get you [rate
  limited](https://docs.gotosocial.org/en/latest/api/ratelimiting/) by your own
  instance due to the high volume of delete requests that are sent. To avoid
  this, we send 1 request every second which avoids limits in the default
  settings. If you have different defaults, pass `--rate/-r`.

* `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. See the [media
  caching docs](https://docs.gotosocial.org/en/latest/admin/media_caching/) for
  more.

* "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` (`GoToSocial Help`
  chat 💝)

* "... 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` (`GoToSocial
  Help` chat 💝)

* 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.

* 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 more strict rate limiting (`--rate/-r`).

## 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>
