I believe that a view of hypermedia state can have at most two of the following 3 properties.
Correct
Decentralized
Fast
Huh?
Correct and Decentralized
This is how our application works today. We can get the data from any peer (fully decentralized) and we validate for correctness before showing it to the user. This is great, but it sacrifices speed and the application feels slow when loading a heavy screen for the first time in the desktop app.
Decentralized and Fast
In theory we could get the exact content for a view from anybody! And show it to the user immediately. But whoops, that content might not be accurate and we cannot validate it without loading all of the underlying data, which cannot be done fast.
Correct and Fast
If you have an authoritative server for a given piece of content, you can trust it to be correct. And it can be fast because it already has done the full validation for you, and it only needs to serve the exact view you are looking for.
This is a compromise of decentralization, because this only works if the content's server is online, accessible, and performing.
The Best Compromise
I believe the best compromise is to use "Correct+Fast" for the first load, which requires a central server for the resource. This does not fundamentally sacrifice on our decentralization principle because any site can self-host. But, for a given piece of content at a given time, there is only one centralized authoritative node.
Then, in the background of a node who has the compute+network+storage resources to do so, we will use the "Correct+Decentralized" approach. And we will also use the "Correct+Decentralized" approach if the authoritative server is down.
Do you like what you are reading?. Subscribe to receive updates.
Unsubscribe anytime