[DRAFT] Given a direct (non-Tor) connection, Quiet iOS syncs new messages in less than 1 second

[holmesworcester]

Our product goal is that important messages are visible in less than 1 second after the user opens the app. Based on user feedback, it is acceptable to add an always-on, non-Tor node to each community to achieve this goal. Our first research question:

Given a libp2p/OrbitDB connection to a fixed IP address without Tor, can Quiet iOS return to the foreground and sync and display messages to the user in less than 1 second?

This means:

1. Backend is already running or we can start it in less than a few hundred ms
2. We can sync and display the most recent 10-100 messages in the remaining time

If the answer is that we cannot do this in less than 1 second, what is the best we can do, and what are the bottlenecks?

[leblowl]

Makes sense to me!

[holmesworcester]

@vinkabuki @siepra - I'm especially interested in your feedback here. What do we already know about how long it takes for the backend to come alive when the user brings the app back to the foreground?

[siepra]

afaik backend usually starts in 1-2 seconds

[holmesworcester]

Does the size of the community affect this? Is 1-2 seconds the number for our test community?

[holmesworcester]

Another question: does "backend usually starts in 1-2 seconds" mean all of backend, i.e. libp2p and orbitdb? Can we get message data from orbitdb in 1-2 seconds? @siepra

This question matters for our sprint planing because:

• We will be 99% sure that #2070 is also possible, if this experiment is successful, because it must be faster to import data stored locally than to sync it from the network. Then #2070 will just be about how we do it.
• If "backend starts in 1-2 seconds" includes being able to retrieve and add data to OrbitDB locally, we will also be 99% that #2070 is possible. Do we already know this? If so, #2070 is maybe not worth focusing on.
• Is the "1-2 seconds" number true on all devices we care about? What about an iPhone from 4 years ago e.g. iPhone 11 or 12?

[holmesworcester]

We dropped this when we switched to a relay approach, but today Lucas & Wiktor's comments relayed by Lucas convinced me that this experiment is still worth doing first, even if we are ultimately pursuing a relay approach, because it is an easier way to get an upper-bound on orbitdb syncing times, and will result more quickly in something we can test and play with.

[holmesworcester]

@leblowl can you paste your notes here when you get a chance?

[leblowl]

I've played around with this and it looks like when the app is suspended, the backend syncs messages in around a second, but it looks like the frontend doesn't display the messages for up to around 7 seconds sometimes. Sometimes it displays messages in a second, but sometimes it takes longer. So it looks like perhaps the frontend isn't always connecting to the backend quickly or something. I'm not sure.