Idea: Search and Filter Support for Historical Reviews

[asthasingh011]

Hi @shrsv ,

While exploring LiveReview and git-lrc, I was thinking about how review history might grow over time for active users and teams.

Currently, users can review code and view generated comments, but finding specific historical reviews may become difficult as the number of reviews increases.

One possible improvement could be adding search and filtering capabilities for historical reviews, such as:

• Search by review content or file name
• Filter by severity (Critical, Warning, Info)
• Filter by risk category (Security, Reliability, Technical Debt, etc.)
• Filter by date range

This could help users quickly locate previous findings and identify recurring issues across review sessions.

I wanted to get feedback from maintainers and the community before scoping this into a formal issue.

Would this align with the project's roadmap?

[shrsv]

Hi @asthasingh011 - this is required, but scoping it is a bit harder than it first appears.

Right now - we do store the review data locally, but don't store it at the server side. This means - we can easily have a historical review browser at the local level.

We do not store detailed review data (with code, etc) in the server side due to security and privacy considerations.

We probably need an opt-in mechanism for orgs to accept that if they wish to have org-wide analysis capabilities, then they accept to store their code on the server side.

Finally - if they do opt-in, we can provide a good org-wide beview browser for them.

I'd prefer to look at both a local + cloud browser together because if we implement a local browser in hurry, and later think of the cloud support as a latch-on, we end up with a lower quality product as a whole.

As to the discussion, I recommend looking into some sort of local first data structures, such as CRDT based ones, which then can be synced to postgres if user opts in.

Can you look into this and make a proposal? You can study how local data is stored, how it can be synced to cloud optionally and then provide a coherent UI across local and cloud.

This is a high level proposal. If the task seems too big, we can scope it down later, but I want to get the design right to start with.

[asthasingh011]

Thanks @shrsv for the detailed explanation! That makes sense, especially the privacy considerations around not storing review data on the server by default.

I like the idea of approaching this as a local-first design instead of treating cloud support as an afterthought.

I'll spend some time understanding how review data is currently stored locally, look into local-first approaches (including CRDT-based synchronization), and think through how an optional cloud sync could fit into the existing architecture.

I'll put together a design proposal covering the storage model, sync flow, and a unified UI for both local and cloud history, and then we can scope it down into a concrete implementation if needed.

Thanks for pointing me in the right direction!

[asthasingh011]

hi @shrsv

Initial Design Proposal: Local-First Review History with Optional Cloud Synchronization

Thanks for the detailed explanation. I spent some time thinking about the overall architecture and wanted to share an initial proposal for discussion. This is intended as a starting point and will be refined after exploring the current implementation in more detail.

Goals

• Keep review history local by default to preserve privacy.
• Allow organizations to optionally enable cloud synchronization.
• Provide a single, consistent Review History UI regardless of where the data is stored.
• Support future organization-wide analytics without changing the core user experience.

Proposed Architecture

1. Local Storage (Default)

Store review history locally on the developer's machine.

This allows:

• Offline access.
• No code uploaded by default.
• Fast local browsing.
• Privacy-first behavior.

The Review History page would read from this local store automatically.

2. Optional Cloud Synchronization

Introduce an explicit opt-in setting for organizations.

When enabled:

• Review metadata and review history are synchronized to the cloud.
• Organizations gain shared review history and analytics.
• Individual developers who do not opt in continue using local-only storage.

This keeps the existing privacy guarantees while enabling team-wide collaboration for organizations that choose it.

3. Local-First Synchronization

Rather than treating cloud storage as the primary source of truth, the local database remains authoritative.

Synchronization would be responsible for:

• Uploading newly created reviews.
• Pulling organization updates.
• Handling offline work.
• Resolving synchronization conflicts.

I'll also explore whether a CRDT-based approach is appropriate here or whether a simpler synchronization strategy would better fit the project's requirements.

Unified UI

Instead of separate Local History and Cloud History pages, a single Review History interface could display all reviews.

Possible additions include:

• Search
• Severity filters
• Risk category filters
• Date filters
• Repository filters
• Sync status indicator (Local Only / Synced)

This keeps the user experience consistent while making the storage location largely transparent.

Privacy

Privacy remains the default.

Users who never enable synchronization continue storing review data only on their own machine.

Organizations explicitly opting into cloud synchronization understand that review history will be stored server-side to enable collaboration and analytics.

Suggested Phases

Phase 1

• Understand current storage implementation.
• Design local storage abstraction.

Phase 2

• Build local Review History browser.

Phase 3

• Add optional cloud synchronization.

Phase 4

• Organization-wide review browser and analytics.

This is my initial thinking based on the discussion so far. I'll now study the current implementation to understand how review data is stored today and refine this proposal accordingly before scoping it into an implementation.

[asthasingh011]

Hi! I wanted to share that I'm currently exploring the implementation and refining the proposal based on the existing architecture.

Once I have a more concrete design, I'll post it here for feedback before creating a scoped change request.

Does this approach sound reasonable, or would you prefer a different level of detail in the proposal?

[shrsv]

Hi @asthasingh011 - this is good start! Here are some points of feedback

Individual developers who do not opt in continue using local-only storage.

In this case org policy should supersede individual preference. If the org opts in to have org-wide analytics -- the expectation will be to comply with it. There won't be individual level opt outs in almost every practical scenario.

Rather than treating cloud storage as the primary source of truth, the local database remains authoritative.

There are two cases:

• org-level sync opted in
• org-level sync opted out

When sync is opted out - there is only one copy - so there is no question of conflicts.

But when sync is turned on - this simple rule will not work. This is where you need to get into more details (look into the CRDT part which I mentioned earlier).

For example - for the same commit - there could have been 2 parallel reviews by two colleagues and they could be synced to central. And the analytics must reflect this unified state.

For the same review - we may add annotations, comments, etc either from the cloud side or local and those must be synced as well. We are thinking more of 2-way sync here, rather than 1-way.

Take a look at this library: https://github.com/reearth/ygo

The concrete question could be: "How do we use ygo to represent a local review?"

If we use ygo datastructure to represent a review locally - it becomes future proof, because syncing, etc will become much easier in the later stages. Also, the author claims it is compatible with yjs, so later adding awesome web UIs with 2-way or 3-way sync will become possible.

Concretely I recommend zooming into this particular question and probably get a local prototype of it -- with ygo.

That particular yjs port looks like a fairly new one, there might be more mature alternatives as well (open to suggestions).

[shrsv]

You can probably try the first two examples in order, to understand how ygo works:

1. https://github.com/reearth/ygo/tree/main/examples/peer-sync
2. https://github.com/reearth/ygo/tree/main/examples/http-sync

We are aiming more towards something like in (2) - for an http-sync of yjs/ygo document, I think.

But yes, do check the library out and see if it is feasible to adapt it.

PS: You can see more about the "y ecosystem" here to understand how offline-first sycing works - https://yjs.dev/. We may need combination of yjs and ygo