docs: moaaaar docs - delete, better fedizen, etc.
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
decentral1se 2024-08-03 15:18:12 +02:00
parent 3843a8688e
commit 2250a705aa
Signed by: decentral1se
GPG Key ID: 03789458B3D0C410

View File

@ -4,9 +4,7 @@
> 🚧 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 ™
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
@ -17,14 +15,42 @@ curl https://git.coopcloud.tech/decentral1se/blurp/raw/branch/main/blurp -o blur
chmod +x blurp
```
## Important notes
## 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.
* `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:
```