Keeping clients GUI responsive

Nodes
1

We are currently facing a small problem on the clients part. Displaying tabs or windows can take a long time because requesting the network is not simple. We generally have to do one request, compute, do another request to complete the informations, compute again… Which can take quite a long time.
This is a problem since UI freezes is a really bad bclients behavour.

To fix it, two posibilities exists :

  • High-level API on ucoin nodes, which do all the searches and calculations for clients
  • Unsynchronized clients, which refresh data in the background continuously

The first choice is probable the easiest for client developers. A bit harder for cgeek, but not that much I guess. The only problem is that it imply that nodes can be overloaded. Also, It means everytime we think of a new feature for clients, we have to ask an API for that.

The second one is the hardest for clients developers, especially about the separation on models/ui. But it is the most powerful and flexible. The bigger problem I see, is that joining a project using massively unsyncronized API is way harder than joining a project only working with synchronized calls.

What is your opinion about it ?

2

My opinion is in favour of an high-level API, to do calculation on server side.

Why ?

  • If we do the hard work on the client side, to handle calculation, we have to repeat this hard work by the number of clients in different languages. This is not efficient. If the hard work is done on the server side. It is done only once !

  • Servers are (by definition) at the service of the clients (not the other way). So servers should serve everything the clients need. Furthermore, servers are sized to handle the amount of all informations in the blockchain, which will increase as time goes by. Clients are not interested in all the informations, only a part.

  • Now days, clients should be the lightest possible to be able to run on low battery and cpu devices.
    A wallet is a thing that must be portable, should be in a pocket, and work everywhere…

3

“Server” is not the better word, in our case, we should rather speak of peers or nodes of the network. Those are not necessarily sized as company servers, and may just be Raspberry Pis.

In other words, the 1st solution does not allow to handle everyone’s data, all the time. However, I understand your point with solution 2. I would not select this option either.

I would instead propose you a 3rd solution: third party services. The whole point is to consider that a peer should not have the responsibility to both be the guarantor of blockchain’s coherence & security, store all transactions of any existin wallet over 180 years, make the coffee, wake you up every morning and save koalas from possible extinction. Responsibility of peers should be limited to blockchain’s coherence & feeding. Period. Higher level services should be something else, somewhere else.

Also, I imagine without difficulty future companies of free money world that would propose such services with awesome & advanced features (not sure about koalas).

But since we are not there yet, I would propose to introduce the concept of “service peers”. The idea is that any peer may also enable a service feature in addition to computation of new blocks, whose point would be to expose services that clients typically need such as:

  • retrieve sent & received transactions for one or multiple wallets
  • retrieve detailed informations about a member (memberships, identity, expired & active links with other members, …)
  • search for informations out of blockchain, just like what /wot/lookup currently do (this feature is gonna be very costly in the future, it should not be enabled by default on any node)
  • …

With this solution, a peer could have for example a /wallet/[pubkey] method that would return all informations about a wallet like its sent & received transactions. But the owner of the peer could parameterize it in order to return results only for some wallets, like those he owns, his friend’s or family’s.

Also, you should have in mind that screesn like “Community > Members” won’t scale with 10k members for example. Not only because of requests, but because of data flow.

So we have both problematics to work on :slight_smile: what do you think of it?

4

The 3rd solution is indeed a good solution. But if we have to get our personnal information on a specific node, then cutecoin won’t be the client to do so.
Cutecoin has been designed to work with a decentralized network. And I think it’s necessary to be able to manage our wallets without 3rd tier services. Cutecoin would be the first generation, getting informations directly from BMA, locally. Not the fastest, but the decentralized one.
With ucoin service apis, it would be better to develop a totaly new client. It would get informations from a personal or company node, where registering or configuration would need to be done first. These clients would mostly target mobile platforms, thought.

About the Members tab, it’s obviously designed for our small community. It should change in the future for sure ! It will probably become research window.

5

Looking at Bitcoin: it has an average of 1 transaction/second currently. So, roughly 600 transactions a block, every 10 minutes. I guess this is something uCoin peers can handle for indexing transactions.

At least, we can probably be satisifed of having a full database management by peers until we reach Bitcoin’s level of usage. Other solution can be found until then.

What else than transactions loading can take time cutecoin and other clients?