Hey! I'm going to try to answer your questions here.

Regarding the question about how many requests a server can handle per second, there is no one-size-fits-all answer. It depends on the underlying server and how it handles requests. The CVM transport is not the bottleneck here. This means that the server's ability to handle requests depends on how it is designed and whether it is optimized to handle a large number of requests per second.

On the other hand, regarding the question of stale computations, it is indeed impractical to recalculate all metrics all the time. In the case of Relatr, we cache these computations and set a TTL so that all computations are only done once and invalidated once the TTL expires. In the example of rapidly scrolling through a feed, there should be no problem handling it. However, it is not the most ideal use case for the current architecture of Relatr, as it implies sending a request and receiving a response. If the events are already published on relays, you just need to craft a specific filter for them and fetch them.

As you mentioned, there are no perfect solutions, and we are still refining Relatr. We will definitely keep trusted assertions in mind to see how we can integrate them into our current model

Further considering the pull vs. request/response (req/res) models, it is true that using already published trust assertion data can be convenient and easy to query with appropriate filters. However, one issue is that not all profiles are scored. For instance, a service provider might start publishing a large number of trust assertions, but the set will never be fully complete because it is dynamic, and it's impossible to anticipate which users need to be scored. Consider the example of a nostr feed we discussed: each profile should be complemented with trusted assertions. But what if one of the profiles in the feed doesn't have any trust assertion attached? In that case, the only solution is to request the trust computation from the service provider.

We believe this might be the right balance. Relatr could publish trust assertion events for profiles that have already been computed and still rely on the req/res flow. In this scenario, a client could operate by first fetching already published trust assertions, and if a profile lacks one, request it. The advantage of this approach is that it can be perfectly integrated with the current Relatr model, as for each request, an event can be published. This way, client developers can choose to just fetch, fetch and request, or just request trust assertions.