u/Dellis251984

I would love to see a first-class way to branch, collapse, revisit, and optionally promote side conversations inside an LLM chat.

Right now, most chat interfaces treat conversations as one long linear timeline. That works for simple Q&A, but it breaks down when using an LLM for real projects, research, learning, or planning.

Human thought is not always linear, and neither is human conversation. When working through a main topic, random but useful side questions naturally come up, just as they do in real-life conversations. Someone may be explaining something, then one word or idea sparks a side discussion. After exploring that side topic, someone eventually says, “but to get back to your question,” and the conversation returns to the original point.

That is essentially a real-life digression being collapsed.

LLM chats should support that same natural flow without turning the main conversation into a giant messy scroll.

For example, I may be working on a Street Sweeper app project involving ESP32 boards. While discussing hardware, I might suddenly want to better understand flash memory, RAM, ROM, or why old video game cartridge files are called ROMs. That side topic is interesting and useful, but it is not directly part of the main Street Sweeper project. It should not permanently clutter the main conversation.

My request is a button that lets users “Digress” or “Fork” from a specific point in a conversation.

The digression would open as a side branch where I can explore the random thought, ask follow-up questions, and learn what I need. When I am done, I can collapse that branch and return to the main conversation, keeping the main thread clean and focused.

Later, I should be able to reopen that collapsed digression. If the side topic becomes important enough, I should also be able to promote it into a brand-new conversation. That way, a small curiosity can grow into its own full chat without forcing me to scroll back through the original project conversation or manually copy and paste everything.

Possible actions:

Main thread = source of truth

Digress = branch off from a specific point

Collapse = hide the side branch and return to the main topic

Reopen = revisit the side topic later

Promote to new chat = turn the digression into its own conversation

Attach to project = optionally save that branch as part of a larger project workspace

This would make LLM conversations feel less like endless scrolling text and more like organized thinking. It would help users keep serious project chats clean while still allowing natural curiosity, learning, and exploration.

I personally like the word “Digress” because that is exactly what the user is doing. In normal speech, people say “but I digress” when they go off-topic and then return to the point. This feature would turn that natural behavior into a clear UI pattern.

Chat is currently designed like a straight line, but thought and conversation often behave more like a tree. LLM interfaces should support that.

Final Update:

Out of respect for the rules, I’m not going to keep reposting this topic. This is my second time bringing it up, so this will be my last update unless something meaningful comes from it.

After reading the comments, I think the core point is pretty simple:

A filter is not drivers trying to control everything. A filter is a matching tool.

If a driver already knows they will never take a certain store or certain order type, showing that driver those offers over and over does not help Walmart, the customer, or the driver. It just creates noise.

And when there is too much noise, drivers start ignoring notifications.

That is bad for everyone.

Right now, rejecting offers is already a manual filter. The only difference is that the driver has to keep stopping what they are doing, looking at the phone, and rejecting something they already knew they did not want.

A basic store filter and order type filter would make the app more efficient.

It could help Walmart get offers in front of drivers who are more likely to accept them.
It could help drivers spend less time sorting through offers they already know they will not take.
It could help customers get orders accepted faster.

The filters could also be adjustable. Drivers could turn them on, turn them off, or clear them depending on where they are and what they are willing to do that day.

People can say “Walmart will never do it,” and maybe they are right. But that is not really an argument against the idea. Companies improve apps based on feedback all the time.

Doing nothing guarantees nothing changes.

That is my final thought on it.
----------------------------------------------------------------------------------------------------------------------------
Update #2:
For the people that don't seem to understand. Rejecting an order essentially is a Filter. You are telling Walmart "Not interested" so that they can push it to someone else.

The fact there are people disagreeing with this filters concept here blows my mind.

It would benefit the whole machine (Walmart, The Customer, The Spark Driver) just to not show The Spark Driver offers they will never entertain.

----------------------------------------------------------------------------------------------------------------------------
Update**: I think some people are misunderstanding what is meant by filters.**

"Filters" is not saying drivers should be able to control everything. "Filters" is saying Spark should have better matching.

Spark already has different offer types. Some offers are sent directly to a driver with a timer, and others are sent more broadly. So if an offer is shown to a driver who already knows they will not take that store or order type, that is wasted time for everyone.

Basic filters would help the system show offers to drivers who are more likely to accept them.

That benefits Walmart because offers could be matched faster instead of being ignored, declined, or passed around.

It benefits drivers because we would not have to stare at our phones sorting through offers from stores or order types we already know we are not going to take.

It benefits customers because their orders could be accepted faster by drivers who actually want that store or type of trip.

For example, if I had a store filter turned on, I would pay more attention to my Spark notifications because I would know the app is only alerting me about stores I’m actually willing to deliver from. Right now, when the app sends too much noise, drivers start ignoring notifications because most of them are not relevant.

That is bad app design.

Filters are not about being lazy or picky. They are about reducing noise, improving matching, and making the platform work better for Walmart, drivers, and customers.

----------------------------------------------------------------------------------------------------------------------------

Hello, I’m looking for other Spark drivers who feel the same frustration and would be willing to help push for a basic app improvement.

I want us to take our time and our phones back from Walmart Spark.

Surely I’m not the only one who feels this strongly. Most drivers have specific stores they prefer to deliver from and specific types of offers they are willing to accept. Many of us also have other jobs, families, hobbies, responsibilities, and lives outside of staring at our phones waiting for a decent offer.

There should be basic filters in the Spark app.

At minimum, Spark should let drivers filter offers by:

Store
We should be able to select which stores in our zone we want to receive offers from and deselect the stores we do not want to deliver from.

Order Type
We should be able to filter by offer type, such as Express Shopping, Shopping, Grocery Delivery, Grocery + GMD, Pharmacy, Alcohol, bulky items, etc.

The fact that Spark can consume so much of our phone time from the moment we hit “Spark Now” until we finally accept an order is ridiculous. A lot of that time is wasted by offers we would never accept in the first place and that could easily be filtered out.

To be clear, I’m only talking about basic filters for store and order type. I am not talking about changing how offers are created, where customers live, or which customers appear in the app.

Drivers should not be able to freely filter out specific customers. If there is a real issue with a customer, that should go through Spark’s proper support process.

What I am asking for is simple: basic filters for store and order type.

These filters would save drivers time, reduce frustration, and probably even help Spark by getting offers to the drivers who actually want them.

If you enjoy delivering for Walmart Spark but feel strongly about this issue too, please like, comment, and share this post so we can get more drivers talking about it. If enough of us speak up in a coordinated way, maybe we can actually get Spark support, or Walmart itself, to take this seriously.