diff --git a/app-guide.gmi b/app-guide.gmi
index eaa46e4..e520d9c 100644
--- a/app-guide.gmi
+++ b/app-guide.gmi
@@ -469,15 +469,21 @@ When it comes to destructive actions, a common pattern is to ask the user for co
 
 ## 5.2 Rate limits
 
-A spammer or prankter could write a simple script to issue a large number of Gemini requests using one or more accounts they've created in your application. Such scripts can be foiled by URLs that contain unique or random elements. However, more sophisticated scripts could parse the returned pages and extract URLs with access tokens, emulating a legitimate client. Therefore, rate limiting is the final line of defense against automated attacks.
+A spammer or prankter could write a simple script to issue a large number of Gemini requests using one or more accounts they've created in your application. Such scripts can be foiled by URLs that contain unique or random elements. However, more sophisticated scripts could parse the returned pages and extract URLs with access tokens, emulating a legitimate client. Therefore, rate limiting is a necessary defense against automated attacks.
 
 A malicious user could create 10000 unique accounts using a script in a short period of time. Consider appropriate site-wide or per-user rate limits on certain actions that modify application state, at least to create or delete accounts/objects/items, taking into account that Geminispace is relatively quiet so the limits do not have to be very high.
 
+Check if your Gemini server provides rate limiting suitable for your application. However, when it comes to the server, it most likely has been implemented with the goal of remaining responsive under heavy load to serve as many requests as possible, instead of trying to prevent malice. You may find that implementing a more adaptive rate limit is necessary. For example, only certain actions in your application might warrant strict rate limiting while most pages can be served with the server's generic, more generous limits. Appropriate limits may also depend on the type of user account, with "trusted" users (e.g., administrators) having unlimited access. 
+
+(Suggested actions to limit: user registration, posting content)
+
 (Notes about implementing limits.)
 
+=> https://en.wikipedia.org/wiki/Leaky_bucket Leaky bucket (algorithm)
+
 ## 5.3 Administration
 
-* Your application should have sufficient admin tools for cleaning up messes caused by malicious users. For example, a way to quickly and easily delete 10000 accounts that were created by a scripted attack, without having to roll the database back to an earlier backup copy.
+* Your application should have sufficient admin tools for cleaning up messes caused by malicious users. For example, a way to quickly and easily delete thousands of accounts that were created by a scripted attack, without having to roll the database back to an earlier backup copy.
 
 # 6. Internals