From 5cc6ba2fb5b9db382cb8f95eaa5fb60bee8f5ffc Mon Sep 17 00:00:00 2001
From: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com>
Date: Fri, 22 May 2026 09:08:43 -0700
Subject: [PATCH] Update typo

---
 standards/application/rpi.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/standards/application/rpi.md b/standards/application/rpi.md
index 7a4f71f..8616d4e 100644
--- a/standards/application/rpi.md
+++ b/standards/application/rpi.md
@@ -22,7 +22,7 @@ However it is up to developers to solve 2 outstanding problems:
 
 Existing solutions fall into two categories based on how messages are delivered to clients.
 
-Centrally routed solutions require the sender's identity in order to deliver messages to their intended destination. Clients in these systems only receive their share of the traffic, which is trivial for them to attempt decryption on every message. These applications avoid the issue entirely, by forfeiting some degree of recipient/conversation privacy. 
+Centrally routed solutions require the recipient's identity in order to deliver messages to their intended destination. Clients in these systems only receive their share of the traffic, which is trivial for them to attempt decryption on every message. These applications avoid the issue entirely, by forfeiting some degree of recipient/conversation privacy. 
 
 Peer-to-peer broadcast routed solutions which maintain recipient privacy also sacrifice performance. Approaches include attempting decryption on all messages received to determine if this payload is of interest. Dividing the broadcast domains into discrete bins can help reduce the processing load, however only to a point. Each broadcast bin must maintain enough traffic to maintain k-anonymity, else the solution matches the centralized approach.