Definitions
Full Node
Our current desktop app behaves this way. It doesn't display any content to the user that has not been validated.
One bad behavior of a full node, is that it often shows the old content of a document or a site while the newer content is still being validated.
Light Node
The content is loaded from a trusted node and displayed immediately, even though the node has not validated every blob.
Currently our web frontend behaves like a light node because it uses the server for all p2p data syncing and validation.
"Light node" could be a mode for the desktop app.
Problem
Let's say a first-time user opens the app and tries to load a document which requires a lot of data.
Take the DevSHM homepage for example, which shows all the recent documents on the site. To be properly displayed on a full node, this page must load effectively the whole change timeline for every doc on the site, plus all the authors. This results in a very slow load time.
But meanwhile, we know what server has this content! Because the user probably typed the https URL into the address bar. So we could resolve the peer ID and get the latest content directly from that peer. Even if they type a hm URL, we just need to load the profile, then reference the siteURL and we can connect directly to an authoritative server for that site.
Solution
Allow the desktop app to operate as a "Light node". This can be an option in the app settings.
Even if the app is configured as a full node, we should use the light node workflow for initial loading of content so the app feels fast. Then load the full data in the background.
Do you like what you are reading?. Subscribe to receive updates.
Unsubscribe anytime