From 62362ef31eb235cfc7b2a391645a63fdbd47b1a9 Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Mon, 26 Oct 2020 15:52:08 -0400 Subject: [PATCH] Add more detail about the differences between this design and light client protocol Co-authored-by: Henry de Valence --- book/src/dev/rfcs/xxxx-zebra-client.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/book/src/dev/rfcs/xxxx-zebra-client.md b/book/src/dev/rfcs/xxxx-zebra-client.md index 1e3bb4a2..5233201a 100644 --- a/book/src/dev/rfcs/xxxx-zebra-client.md +++ b/book/src/dev/rfcs/xxxx-zebra-client.md @@ -200,9 +200,15 @@ Supporting a wallet assumes risk. Effort required to implement wallet functiona - we need to provide basic functionality within zebra's trust boundary, rather than forcing users to additionally trust 3p software - there are great 3p wallets, we want to integrate with them, just don't want to rely on them -- light client protocol +- What about the light client protocol? - does not address this use case, has different trust model (private lookup, no scanning) - - + - we want our first client that interacts with zebrad to not have a long + startup time, which a lightclient implementation would require + - zebra-cli should be within the same trust and privacy boundary as the + zebrad node it is interacting with + - light client protocol as currently implemented requires stack assumptions + such as protobufs and a hardcoded lightserver to talk to + # Unresolved questions [unresolved-questions]: #unresolved-questions