docs: moaaaar docs - delete, better fedizen, etc.
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
parent
3843a8688e
commit
2250a705aa
36
README.md
36
README.md
@ -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:
|
||||
|
||||
```
|
||||
|
Loading…
x
Reference in New Issue
Block a user