Thanks @zooko for taking the time to answer in such details.
About #1, FYI ywallet and Zingo can spend the existing notes before syncing (if they were not spent from a different device of course)
It won’t be a recent anchor but the protocol accepts it.
#2 is where the difference with SbS will be more visible. You prioritize the case when the user just received a shielded note and wants to spend it, vs catching up a wallet that hasn’t been opened for a while?
Thanks.
Update! The bad news is the final release of ECC SDK 2.0 isn’t out yet because we found one bug that would have violated our 4th requirement.
The good news is:
All three of our wallet partners (not counting Unannounced Secret Mystery Partner) are actively testing the release candidates and giving us issue reports! So the Release Candidate process is actually working and helping us find issues before the final release instead of after.
We’re testing internally, including using a quick and dirty version of the Zashi beta. Reach out to me if you want to help with that, and if what you like doing is finding bugs in beta software and giving nice detailed bug reports 
.
That one bug we found is now fixed, there are no more known issues that would block the final release, and we’ve put out new release candidates: Release Zcash IOS SDK release 2.0.0-rc.3 · zcash/ZcashLightClientKit · GitHub (iOS) and Release Zcash Android SDK release v2.0.0-rc.2 · zcash/zcash-android-wallet-sdk · GitHub (Android).
#1179 and #1180 done (the last week of August).
#730 and #899 #936 #908 completed
Rest of the mobile code – code complete Friday 2023-09-08 excluding acceptance testing
Fix bug (#963) discovered during acceptance testing
Code review of mobile code changes, release SDK 2.0 Release Candidate Wednesday 2023-09-13
fix bugs from RC, release RC 2 Monday 2023-09-18
fix bugs from RC 2, release RC 3 Wednesday 2023-09-20
☐ Acceptance testing complete by Monday 2023-09-25. Release SDK 2.0 Final! (* Assuming no more showstopper bugs discovered!)
☐ Ask Nighthawk, Edge, and Unstoppable to make announcements of their intentions: next week
As always, please hug your friendly neighborhood ECC developer! Unless you are a total jerk, in which case please stay away from them, thanks. 
This is quite worrisome to hear, to be honest, as the last two times Zooko pushed similar “grandiose announcements,” they turned out to mainly serve as frames for even more grandiose pump & dumps (i.e., “Halo 2 is coming on January 3rd, Halo 2 is coming on January 3rd, Halo 2 is coming on January 3rd” and once the price had 3x’d, “Halo 2 is not coming on January 3rd for no technical reason whatsoever, we just did not feel like launching it on the announced date any more,” followed by an obvious monster dump, and then a few months later with “the identity of John Dobbertin is going to be revealed and it will blow your mind who it is, the identity of John Dobbertin is going to be revealed and it will blow your mind who it is, the identity of John Dobbertin is going to be revealed and it will blow your mind who it is” only to be followed by yet another very obvious monster dump).
I hope Zodlers will be much more cautious this time around.
The difference between these approaches and SDK 2.0’s Spend-before-Sync is that we ensure the anchor is recent, maximising the privacy set of the spent notes. Implementing this was a significant part of the SDK 2.0 engineering work.
The Spend-before-Sync prioritizes these two cases roughly equivalently:
This is because the process of making existing notes spendable with a recent anchor involves scanning blocks at the chain tip. We could make existing notes spendable faster by splitting these apart, but the added technical complexity is not currently justified; it’s something we’ll keep an eye on as SDK 2.0 is deployed and we get wider feedback from more users.
Prioritised below these two is “catch up with chain history”; as new notes are discovered there, they become spendable with a recent anchor on a similar timescale to existing notes.
The difference in the privacy set is the notes that were created between these two anchors?
If someone were to measure the performance of these use cases, what would you consider an objective test setup?
While I agree in general that “big announcements” are typically lackluster:
I do think this one is very interesting for a change:
nice job to the ECC for this one.
It was also a nice job that ECC did with Halo 2, but what I was warning against are the monster (and in my humble opinion, blatantly manufactured) pump & dumps that usually (or is it “literally every single time”?) take place whenever “ECC and/or friends” release this type of “flamboyant” news.
“Once is happenstance. Twice is coincidence. Three times is enemy action” and all that, you know? 
Awesome! This will be huge.
This is very good news because it can help drive usage of shielded ZEC. We have incredible technology and it’s (unfortunately) been hard to use. This Brave partnership is exactly a step in the right direction. Bravo ECC 
nice!!!
More than anything, I hope that this partnership illustrates how important having Business Development positions in an ecosystem is and that this community votes to fund an organization that is going to work on partnerships like this since ECC has stated it is no longer a focus for them and eliminated that work.
I encourage everyone to remember how to felt today when they saw this announcement and should the dev fund continue, ensure an organization is funded to work on projects like Brave.
2 posts were split to a new topic: Help requested getting Ecosystem ID
Today, ECC is announcing the the updated mobile SDK 2.0 for both iOS and Android developers! 
You can get the code from:
This was the last remaining deliverable in our efforts to mitigate third-party wallet performance issues — and one of a bundle of releases that included two updates to zcashd and a new version of lightwalletd.
Super-special thanks to our engineers who have put in countless late nights and weekends over the last year, and especially the last few months. We are also grateful for our wallet partners — Edge, Unstoppable, and Nighthawk. Thanks especially to Edge for conversations about usability that helped inspire these ideas and others, and thanks especially to Nighthawk for testing the release candidates of SDK 2.0 and reporting a lot of issues before the final release.
The major component of this release is the Spend before Sync (SbS) capability. This feature enables a wallet user to spend funds as they are discovered without having to wait for a complete chain sync. The result is a faster and more robust user experience.
In addition to SbS, this release includes a number of performance-related improvements, stability enhancements, and bug fixes, providing a solid foundation for developing future Zcash-supported applications and systems.
Nighthawk, Unstoppable, and Edge are currently working to implement the SDKs, and as soon as we know that users of those wallets are able to access their ZEC funds, ECC can — finally — exit emergency mode.
#1179 and #1180 done (the last week of August). #730 and #899 #936 #908 completed Rest of the mobile code – code complete Friday 2023-09-08 excluding acceptance testing Fix bug (#963) discovered during acceptance testing Code review of mobile code changes, release SDK 2.0 Release Candidate Wednesday 2023-09-13 fix bugs from RC, release RC 2 Monday 2023-09-18 fix bugs from RC 2, release RC 3 Wednesday 2023-09-20 Acceptance testing complete by Monday 2023-09-25. Release SDK 2.0 Final!Good news! Congratulations to everyone involved in achieving this important milestone.
Great news!
the system of using memories for private messages is incredible
Spend before Sync (SbS) is workin on Nighthawk beta and its way better den I even anticipated!
