Feed Ordering

Order by event claimed time, observed time, do we need both in different circumstances

For the invalidator and the notification system, we should sort by observed time

In the Feed UI, the user probably wants to sort based on claimed time. We already use the claimed time for presentation, but the order may be wrong for new nodes.

We will introduce a `sort=ClaimedTime` parameter for the user's feed

Eric and Julio will talk about pagination direction and token. Keeping Burdi in the loop to lower CPU consumption of activity API

Web Discovery Pattern

Profiles are not going to all the sites they need to

https://github.com/seed-hypermedia/seed/issues/629

Do we need to call discovery in some non-gateway sites?

We can cover up this issue from the user by creating a special API endpoint for the collaborators tab, which will improve perceived performance.

We will bring discovery to the web so the collaborators page and others will automatically related content on the network.

Deprecate Discovery OR Subscription

If one of these is slow, then lets use just the one!

The subscription API is no longer necessary. It can look at the signed data to see what the user wants to keep up to date. Basically, subscription should be automatic behavior by the daemon.

The discover API should support fine-grained addressing.

Query Client Normalization

Really high priority for Profile Normalization. Right now they are scattered throughout.

The invalidation is very crude right now- most events lead to a widespread invalidation.

Our current behavior results in a performance penalty (not clear how bad).

Inherent tradeoffs here, we should support both workflows of loading dependent data alongside queries, or not doing that.

Eric working on normalizing profiles. Comments are probably next.

Moving away From RQ to @shm/reactive??

It is coherent but a VERY intensive change