Local-first initiative

[maackle]

In #3221, I proposed to remove the notion of "joining the network". The basic reasoning is that "joining the network" is an abstract, fuzzy notion that can't be concretely determined. The real concrete things are connections to peers, but it's not straightforward to define how many peers you have to be connected to in order to be "online".

Moreover, we had apps set up to remain in a disabled state if the network could not be "joined". The reason for this was to try to ensure a good "online" experience for apps upon starting up, to avoid the confusion of an app which can't receive new data, and instead is timing out all of its requests, since it expects to be "online" but actually isn't. In 0.3.x, something shifted so that network join errors were much more prevalent, making this experience very common.

This safeguard is not robust or realistic though, because I might lose my ability to talk to peers at any time, not just at app startup. Apps need to be responsive to changing network conditions and should not assume they they are always-online. So that's what this discussion is about: what features and patterns do we need to empower apps to be respond to changing network conditions, and how do we best get there?

It's not enough to differentiate between an "offline" and an "online" state, in terms of internet connection or ability to see some "beacon". For instance, in a small network where only myself and one other node are connected, if my internet connection dies, it will be indistinguishable from if my counterpart turns off their laptop -- in both cases it will appear my connection to "the network" was severed, and in both cases the app should respond accordingly.

Namely, when I have limited or zero network availability, the app UI should display some indication of this, and potentially disable certain features. Offline functionality can continue to work, like viewing local and cached data and potentially even committing new data to your chain (with the caveat that it won't be published and potentially won't be able to pass validation).

What's needed

In my mind, there are a few things that need to be in place for this kind of robust local-first experience:

1. the ability to detect network conditions so that UI can be updated
2. the ability to query only local data, when we know we can't get data from the network
3. more robust ways of attempting to fetch data from the network that doesn't suffer the hit of long network timeouts in case there is an undetected change in network conditions

1 is something that needs to be added to Holochain: probably something like an enhanced NetworkInfo, which is already available in limited form over the App Interface

2 is available in limited form through things like GetStrategy::Content, but it's not super well-defined, is not available for get_links, and in the wild it seems to be rarely used. These sorts of patterns could be expanded upon.

3 is open territory. It could take the form of pub/sub, where we subscribe to data and then simply never get notified if we're offline, rather than blocking and waiting for data which may never come. It could also look like an adaptation of 2, where local get calls could trigger an async network request for the data and then send a signal when the data is ready to be re-queried through another local get. Either way, this seems to involve some sort of push-based model, but I'm not sure. The motivation is, when 1 fails and causes us to misjudge the network conditions (i.e. we think some peers are there but they really aren't), it would be nice to have a way of attempting to get stuff from the network that doesn't fail spectacularly when we misjudge (like a 60 second timeout).

I don't want this to be the definitive guide to what's needed but I want to get the ball rolling and seed the conversation with some initial directions to look in, and reflect some things some of us have already talked about. Other views welcome.

How to get there

Currently the only feasible option for getting data in most situations involves making blocking calls out to the network with 60 second timeouts. If full-on pub/sub turns out to be the best solution, we still want to provide a more gradual migration so that app devs don't have to suddenly change their entire data transfer paradigm overnight. This seems to fall under category 2 above.

There are already some front-end solutions to the local data fetching problem that are in general use, like @guillemcordoba's readable stores and tanstack/query (thanks @mattyg for the links). Since those kinds of patterns work well it would be nice to have Holochain work well as a backend to those patterns (currently a lot of solutions involve frequent polling, which is not ideal for performance).

Working Group

There is a lot to decide here, both short-term and long-term, and I imagine this discussion could be the start of a working group to address these questions. Whoever is interested and has bandwidth can help identify patterns and techniques and help write specs and maybe even PRs. These decisions have a large impact on app devs and of course Holochain users, and the decisions should come from those most affected. If there comes to be a time of high activity on this we could even have some regular meetings to keep the feedback loops tighter.

[maackle]

Wrote some thoughts here on ways to move towards local-first (must be a logged-in HackMD user to view): https://hackmd.io/BEH4VnnYTwacPo6zd_qp5w

[guillemcordoba]

I see in the docs that there is talk about marking zome calls as read only so that they can be re-run when there is new data that was understood as relevant to that zome function, and then return the result to the UI, so that the UI always has "the latest result for all these gets". If I understand correctly, the purpose of this is to move all the "query aggregator code" to the backend. With "query aggregator code" here I mean that code that, for a given non-content addressable query, filters, sorts and does some preprocessing to the query to return the relevant pieces of information. Let's play with a forum happ toy example:

User Story: I want to see a list of all the posts within the app, sorted by "last created first".
Entry Design: I'm going to have a global anchor that will have links to all the posts' action hashes to which I issue get_links queries.

The "query aggregator code" here would be the piece of code that from a list of links, returns the list of action hashes for all the posts that I need to get to render the UI, in the form of Fn: (links: Vec<Link>) -> Vec<ActionHash>. In this case, it would probably sort the links by creation time, and return only the 10 first hashes from that.

The "query aggregator code" can live in either the UI or the backend. I see the effort to have subscription like zome calls backed by the intention to have it be in the backend. In my experience, this code is better suited to be in UI. Here is an example of why.

Imagine we have the all-posts element in the same UI as the create-post element. Whenever I create a post, I want the list of posts to be updated immediately (I just went through a round in which that was not immediate and the feedback from @zippy and users was clear in that it needed to be immediate to feel good as a UX).

So... I think if we have the query aggregator code in the backend, that presents two problems:

1. The subscribed zome function won't re-run immediately after I call create_post, so the UI will have to wait until the link is published, validated, and signaled from the authorities for those links.
2. Even if we add the ability of "whenever a new link of the subscribed to query is created, re-run that zome function", the zome function will still do the get_links, which won't return that new link for the little while that it takes to be received and validated.

I know we may be talking about sub-second intervals here, but it's what actually matters to have UIs feel good... It needs to feel alive.

My current solution to this is holochain-based UI query aggregator code. This store maintains a list of the alive links for a given base and link type, by polling and listening to signals emitted in post-commit (these could be system-level signals), both CreateLink and DeleteLink signals are important and need to be listened to.

I'm actually also finding that waiting for the signal to return is too slow. It takes just a little bit of time from the end of the zome call until the signal is received (maybe 300ms), and specially in mobile that time is seen by the user as "oh that didn't do anything - oh wait it did". I think what I'll need to do with this is have the UI await to receive the signal before actually resolving the create_X Promise. I already had to do this with create_commit in syn since that is relaxed and that means that the ActionHash returned in the create_commit zome function may not be valid anymore, I can only trust the ActionHash signaled in post-commit in that situation.

I guess what I'm trying to say is that implementing the zome call subscription pattern adds a lot of complexity and magic that not all apps would necessary want in the same way, and it doesn't solve these issues. So I would be quite reluctant to go that path, at least from my experience and from where I'm standing right now...

@mattyg I would be interested in knowing your experience in building UIs around this and what motivates you to want to move this logic to the backend.

Happy that this is being talked about at the moment. It'll be exciting to be able to code real-time UIs in holochain really easily.

[mattyg]

I see in the docs that there is talk about marking zome calls as read only so that they can be re-run when there is new data that was understood as relevant to that zome function, and then return the result to the UI, so that the UI always has "the latest result for all these gets".

I think this would only be achievable through pub-sub networking. I don't totally have my head around it. I think in general the thinking is pub-sub has to be an "add-on" feature, not replace the current pull-based networking.

I don't think option 1 in the hackmd is nearly this ambitious. It's more like a better thought-out version of GetOptions. With GetOptions currently we can either (1) return local data if it exists and otherwise try to fetch from the network or (2) fetch from the network and return local data if we don't get a response.

I think the current limitations of GetOptions are:

1. it can't be applied to get_links or get_link_details
2. it doesn't have an option to immediately return the local data, but then still do a network request (just not wait for it to finish). If it did support this option, then maybe it would be nice for it to also emit a signal when the network request does finish.
3. it is applied to the individual get* request, (specified in zome function at compile time), rather than being applied to the zome call as a whole (specified at runtime and applied to all the get* requests within it where relevant).

So the potential improvements are:

1. Apply to get_links and get_link_details
2. Option to return the local data, then send a network request (and maybe emit the response)
3. Apply to all requests within a zome call, at runtime, rather than a single get request at compile time

But honestly it's a good question -- how would this actually improve the store pattern you're using? And if the delay to hit the holochain cache is unacceptably slow, so we have to use localstorage anyway, then whats the point?

I guess this is how these changes would affect your store pattern:

• If you already have data cached in localstorage: UX is the same
• If you don't have data cached in localstorage, and don't have data cached in the conductor: UX is the same
• If you don't have data cached in localstorage, but do have it cached in the conductor: UX would improve
  • You could get cached data immediately with a LocalOnly zome call, then request network data with a NetworkRequest zome call (or effectively do both in one zome call with a NetworkSubscription zome call)
  • You could be in this situation when:
    • you update your happ UI, so the localstorage is wiped (I assume this occurs but not sure)
    • you hit the localstorage 5MB limit and need to purge some data
  • But these situations seem more like edge cases and not important to optimize

So I guess actually this doesn't seem that important and wouldn't really make a UX difference if apps are using localstorage as another cache.

I would love to be able to remove the localstorage cache as a redundant and more limited clone of the conductor cache. I don't know if there's room for performance improvements of conductor cache reads, or if it will never be fast enough due to serialization + wasm + sqlite cost.

If it could be fast enough, then making these changes would let us almost entirely replace the localstorage cache for the same UX of your store pattern (we would still need to save pending actions to localstorage). That would be a nice reduction of the front-end complexity, and let us avoid the localstorage 5mb limit. But again, this feels like an optimization and not a super important change to prioritize.

[maackle]

Hey @guillemcordoba, first of I super super appreciate this kind of feedback, with the real details of what it takes to build good UIs for complex apps. I want to take all of this kind of context into account. And if you have any particular Holochain improvement ideas, I want to read those.

If I understand correctly, the purpose of this is to move all the "query aggregator code" to the backend

The intention of this idea isn't to move more code to the backend, but rather to effectively handle the code that already does "belong" in a coordinator zome. Your example of picking out the ActionHashes from a set of links is just a straightforward mapping from one type to another and I agree that's great to do on the frontend. However, the mere fact that we put get* calls into the HDK at all, rather than making them directly available from the frontend, implies that we wish to bundle together a bunch of data retrievals into a single zome function, with some logic to glue them together, and for those cases, it could be useful to have a read-only designation. @guillemcordoba I'm curious if your querying zome fns tend to include more than one get*, or if they're just wrappers around single get* calls?

(On a personal note, my stance is the exact opposite: I wish we could move more code to the front end. What do you think of this idea? https://hackmd.io/BEH4VnnYTwacPo6zd_qp5w#2b-Remove-gets-from-HDK-altogether)

Whenever I create a post, I want the list of posts to be updated immediately

Reading into your specific UI concern a little more...I might not be getting all the nuance but it sounds like you're mainly talking about the "optimistic update" pattern which is concerned mainly with what happens when the UI operator creates something new. I wouldn't want to change anything you're doing there, I think that's a fine pattern. I'm thinking mainly about discovering all the new data that you didn't author.

For that, you're polling. It depends on which particular idea we're talking about in the doc, but short of full-on pub/sub, yeah, all we can do is reduce the amount of polling. So yes, maybe these ideas wouldn't benefit you very much. It's more for people who are using zome call gets as a primary way of retrieving data in a more traditional REST-like way. Actually, one way to say it is that part of the motivation of these ideas is to nudge people more into the direction of what you're doing: decoupling the network updates from the data retrieval, so that you can have an experience of having access to data regardless of how long it takes to get data from peers, or if you can get data from them at all. The person who this benefits is the one who has been making a zome call which does a bunch of network gets, each of which could experience a 60s timeout, and then waiting for that to come back before updating the UI. Especially when the network is slow or unavailable. Your pattern already provides a buffer against that.

I'm curious about your, and all other front devs', experience, what are the patterns that really work and what should Holochain do differently to support that?

[nphias]

my suggestion would be to offer the additional two modalities and keep the existing default alongside greater front-end control with status signals (health service)

• LocalOnly*
• NetworkBlocking (default)
• NetworkSubscription*
• HealthServiceSubscription (optional)

The NetworkSubscription call would immediately return with a subscription token so you can add callback function logic to the signal response array.

In order to give the end-user more control or generally better UI/UX
The NetworkSubscription option would allow an unsubscribe and cancel option using the token hash

In the case of NetworkBlocking, it would be useful to implement sagas (mostly for holochain-as-a-server usecases).
would it be possible to scrap the 60 second timeout and have an indefinite exponential backoff algo.. eg 2,4,8,16,32 etc..
and then give the client or host call a token to cancel the subsequent network attempt during a backoff period ?
The healthservice could provide a cancel token for each cell

In addition for greater performance you could implement more of a CQRS like pattern.
its a more complex architecture.. but would allow the sequential buffering of multiple writes, segregated from the read channel.
that would be another attribute on callzome (command or query) or create callcommandzome and callqueryzome

its generally a good idea to make all zome functions idempotent and not rely on the client code bouncing etc., the NetworkBlocking option would be better for non-idempotent zome functions of course.

[maackle]

Took a second to understand what you meant about implementing sagas, you mean this right? https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga

I think this is all in the right direction. The more constraints we have on how we interact with data, the more performance and usability gains we can realize.

[mattyg]

Looks like we have a bunch of "network health" related information exposed to the admin api, but not the app api. I made an issue for it here: #3314

I also made another issue to track our "wish list" for additional network data we'd like exposed to the app api: #3315