Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
holmesworcester opened this issue Nov 14, 2023 · 8 comments

Comments

@holmesworcester
Copy link
Contributor

holmesworcester commented Nov 14, 2023

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?

@holmesworcester holmesworcester converted this from a draft issue Nov 14, 2023
@holmesworcester holmesworcester changed the title Given a direct (non-Tor) connection, Quiet iOS syncs new messages in less than 1 second [DRAFT] Given a direct (non-Tor) connection, Quiet iOS syncs new messages in less than 1 second Nov 14, 2023
@leblowl
Copy link
Collaborator

leblowl commented Nov 16, 2023

Makes sense to me!

@holmesworcester
Copy link
Contributor Author

holmesworcester commented Nov 16, 2023

@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
Copy link
Contributor

siepra commented Nov 17, 2023

afaik backend usually starts in 1-2 seconds

@holmesworcester
Copy link
Contributor Author

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

@holmesworcester
Copy link
Contributor Author

holmesworcester commented Nov 21, 2023

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:

@holmesworcester
Copy link
Contributor Author

holmesworcester commented Dec 1, 2023

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
Copy link
Contributor Author

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

@leblowl
Copy link
Collaborator

leblowl commented Jan 4, 2024

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.

@siepra siepra removed this from Quiet Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants