RPC Refactoring

[MathJud]

trafficstars

The RPC communication between libqaul & and the UI shall be made better.

• [ ] users list
  • get all users
  • only get newer users afterwards
  • make special list of online users
• [ ] chat conversations
  • request latest conversion with index & offset

Questions

• Where is the problem by merging the online users & the existing users together
• Until which number of users does this make sense?
• chat overview
• what could be made better there?
• only subscribe to new message

Future Ideas

• Make messages subscribable
  • we need an authentication system with sessions for this feature
• Notifications: Subscribe to Notifications for all new stuff

[brenodt]

Questions of my own

1. When you say that "users list" should yield all users the first time, and only new users afterwards, would that mean that each libqaul response would need to be cached locally - so as to not lose any users that were previously fetched?

Responses

Regarding questions that aren't struck-through, I wasn't entirely sure what's being asked - apologies for that. Would you please elaborate?

• ~Where is the problem by merging the online users & the existing users together~
• Until which number of users does this make sense?
• chat overview
• what could be made better there?
• only subscribe to new message

Where is the problem by merging the online users & the existing users together

If I understood correctly, you're referring to the way that it is currently implemented. If so, the main issue we have is in determining what the actual connection status is for a given user in the frontend.

TL;DR We don't have a clear cut way of asserting if a user is online or not, which means we need to deduce from available data. From a frontend standpoint, the best solution would be to have the connectivity field in the Users protobuf (rust/libqaul/router/users.proto:32) be the only source of user connection status.

Overview:

• User data comes from two different modules: Users and Router.
• The former has no connection status information, whilst the latter has a connection table

  in reality there is a connectivity field in the Users protobuf (rust/libqaul/router/users.proto:32), but as I recall it wasn't connected to any logic in the library

• When we poll the users data, we fetch responses from both modules. One with empty connection data and one with (possible) non-empty data, and then merge them locally to reflect on a single List of Users

This means that, when we're updating an existing User, we assume that having connection data precedes not having it, due to one of the messages never having it. Otherwise the connection status flickers to online/offline (depending on what the last message was).