[SPIKE] UX flow for extending TTL

[sdfcharles]

No description provided.

[sdfcharles]

Seems to be same as #1693

[aristidesstaffieri]

Eng Spike:

There are 2 scenarios where expired data or contracts can affect the UX in Freighter:

• A data entry has expired, and that entry either represents data that Freighter uses in the UI or is an entry that is needed as part of an operation that Freighter supports.
• A contract instance has expired and Freighter relies on that contract.

Right now, we don't have a way to track TTLs for specific entries in order to display the "archived entry" icon. There are a few things we can consider when finding a solution for this data:

• Does this icon and the TTL flow from the asset dropdown encompass both expired data and the contract instances themselves? TTLs for SACs get bumped whenever they are used, inline with the operation. It might be unlikely that users need this flow for more commonly used assets.
• Do we support this workflow for custom tokens? If so, how do we determine which entries to track? Custom tokens could have any storage layout supported by Soroban.

Other considerations:

Should we also prioritize a bump and/or restore workflow for our submit tx flows? It seems more likely that users will need this when they try to submit a transaction and it is rejected due to an entry being archived.

Should we prioritize improving our archived entry related error messages? Right now, users have a hard time understanding that they're transaction has failed due to an expired entry in Freighter. We could add more user friendly error messages for these cases.

Looking up entries using ledger keys on the rpc can be a slow process with several trips to the ledger. We will likely get much better performance from a proper index of this data, and if we decide to implement this check on the asset list, then the latency affects our home page loading time so we may want to be sensitive to this. We could also get similar UX by handling archived entry related errors during balance fetching in a way that informed the client that the entry or contract is archived.

[JakeUrban]

Thanks @aristidesstaffieri, after reading this I'm not sure if we should support extending TTLs, at least right now.

I think we need to step back and ask ourselves why we want to provide users the ability to extend TTLs. I can think of two reasons:

1. We read ledger state in order to display information to the user. If this state was archived, we wouldn't be able to read it and therefore provide it to the user.
   • For example, we currently fetch custom token balance entires using RPC to display the user's balance on the home page.
2. We submit transactions on behalf of our users. If these transactions rely on entires that are archived, the won't be able to submit these transactions without restoring the entries first.
   • For example, we support sending to C... address, and the contract we're sending to or the token contract we need to call could be archived.

On the first point, we already have a solution: we need to index any state Freighter provides to the user off-chain, so we don't rely on the state being live. This is why the wallet backend needs to track account balances. I don't think we use any other ledger state in the UI.

On the second point, I think restoring entires on an as-needed basis might be better than trying to track all entries we may need when submitting transactions for users. Right now, the state we would need to track are custom token balance entires, and token contract entires (for stellar asset and custom token contracts). Tracking these entires is probably doable, however, I can see a future where we integrate with defi protocols, and therefore may need to extend TTLs for entires on that contract. I don't think its practical to track an ever-expanding set of entires that Freighter user's can use when executing transactions.

Given that, I recommend we mark this task as done and create new ones for the two solutions mentioned above: indexing any state needed for read-only purposes and supporting on-demand restoration of any state needed for write (i.e. transaction execution) purposes.

[aristidesstaffieri]

@JakeUrban that sounds good, I def think this needs some more detail.

I made this one for indexing data and this one for the restore & retry action.