From e1fe193cfbd666904f1c205e4491b681f3302e6e Mon Sep 17 00:00:00 2001 From: Jeremy Klein Date: Fri, 14 Feb 2025 00:00:24 -0800 Subject: [PATCH] Accept suggestion Co-authored-by: Roland <33993199+rolznz@users.noreply.github.com> --- 47.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/47.md b/47.md index ca1e0c44..63811378 100644 --- a/47.md +++ b/47.md @@ -603,7 +603,7 @@ If the **wallet service** does not support the specified encryption scheme, it w As described above in the [Notifications](#notifications) section, if a **wallet service** supports both nip04 and nip44, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. If the **wallet service** only supports nip44, it should only publish kind 23197 events. -The **client** should check the `encryption` tag in the `info` event to determine which encryption schemes the **wallet service** supports, and listen to the appropriate notification event. Clients that support both nip04 and nip44 can choose to only listen to 23197 events for simplicity. +The **client** should check the `encryption` tag in the `info` event to determine which encryption schemes the **wallet service** supports, and listen to the appropriate notification event. ## Using a dedicated relay This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.