diff --git a/README.md b/README.md
index 2bdbf15..b2f3964 100644
--- a/README.md
+++ b/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:
 
 ```