Expand use cases for flowy.llink into a lightweight suite of tools #243

Closed
opened 2026-06-03 22:09:22 +00:00 by talksik · 1 comment
talksik commented 2026-06-03 22:09:22 +00:00 (Migrated from github.com)

This could single-handedly compound the power of the product 10x. Because then I would be able to use streams for literally everything: notes, backlog, and comms all being multi-player. We don't necessarily need all sorts of particle types for this product to feel right.

We can make the experience a much more lightweight for idea capture, sharing, and conversation. It's the hybrid of a conversation and artifacts, living and breathing in a new way.

And we could make it so that one could scan images and add captions to images.

The added benefit of only having streams is that conversation can be done in between artifacts being created. And there is no reference to another artifact from a conversation. Sure you can move particles to other streams, but overall, the conversation includes artifacts like text messages which could be fully blown markdown documents. And these are living and breathing instead of just a reference in a chat.

This issue is requesting the following distinct features:

  • Folders can house multiple streams with each stream having its own visibility rules, and folders also having their own super set visibility rules? (Visibility mechanics tbd)
  • Streams having a toggle between list and play view. List view is like a chat but more like a purist / utilitarian table. And this allows using it for things like journal (list of distinct documents instead of a conversation). Play view is more sit back and consume, with easy ability to toggle into the manual list experience so that you can stop on an item and do something with it. List view would also allow dragging things around potentially, unlike a chat.

It's now time to engineer the nested, recursive structure which compounds the power of the product, and allows me to use it for all sorts of things: project management, notes, research, crm, calendar, and more

On top of this, enabling AI within with the context is something people would love to have, they don't want to copy or use in claude.


Areas of the experience

  1. Lightweight issue tracker
  2. View a stream in list view
  3. File storage: folders for files and text that are for reference instead of a stream of conversation
  4. Move items between containers
  5. Calendar view of events (could exist in folders or streams)
  6. Tags can allow horizontal grouping
  7. Table (lightweight google sheets just editing a csv)
  8. CRM contacts (maybe just in a folder)
  9. Filter folder by children particle type

Requirements

Super fast. Lightweight experience.


Questions

Do we implement local-first with a sync server, or keep firestore? We could implement the sync server after implementing all of these features, although we would be falling into deeper technical debt. However, it's not impossible to migrate later.

This could single-handedly compound the power of the product 10x. Because then I would be able to use streams for literally everything: notes, backlog, and comms all being multi-player. We don't necessarily need all sorts of particle types for this product to feel right. We can make the experience a much more _lightweight for idea capture, sharing, and conversation._ It's the hybrid of a conversation and artifacts, living and breathing in a new way. And we could make it so that one could scan images and add captions to images. The added benefit of only having streams is that conversation can be done in between artifacts being created. And there is no reference to another artifact from a conversation. Sure you can move particles to other streams, but overall, the conversation includes artifacts like text messages which could be fully blown markdown documents. And these are living and breathing instead of just a reference in a chat. This issue is requesting the following distinct features: - Folders can house multiple streams with each stream having its own visibility rules, and folders also having their own super set visibility rules? (Visibility mechanics tbd) - Streams having a toggle between list and play view. List view is like a chat but more like a purist / utilitarian table. And this allows using it for things like journal (list of distinct documents instead of a conversation). Play view is more sit back and consume, with easy ability to toggle into the manual list experience so that you can stop on an item and do something with it. List view would also allow dragging things around potentially, unlike a chat. It's now time to engineer the nested, recursive structure which compounds the power of the product, and allows me to use it for all sorts of things: project management, notes, research, crm, calendar, and more On top of this, enabling AI within with the context is something people would love to have, they don't want to copy or use in claude. --- ## Areas of the experience 1. Lightweight issue tracker 2. View a stream in list view 3. File storage: folders for files and text that are for reference instead of a stream of conversation 4. Move items between containers 5. Calendar view of events (could exist in folders or streams) 6. Tags can allow horizontal grouping 7. Table (lightweight google sheets just editing a csv) 8. CRM contacts (maybe just in a folder) 9. Filter folder by children particle type --- ## Requirements Super fast. Lightweight experience. --- ## Questions Do we implement local-first with a sync server, or keep firestore? We could implement the sync server after implementing all of these features, although we would be falling into deeper technical debt. However, it's not impossible to migrate later.
talksik commented 2026-06-12 19:40:28 +00:00 (Migrated from github.com)

From trying to implement folders, recursive structure, I found that we lost the simplicity of using streams (with open / closed flow). It added problems such as auto-play not working for streams within folders.

Moreover, adding events is just not ready. It's asking for implementing calendar and having notifications, a calendar view which aggregates events, where should we place events (folders or streams). This was the case for CRM of contacts as well: people want CRM with custom fields and all sorts of integrations with their communication with customers, not just a "contact record" with some fields like name and email. We have to be careful here. Same goes for issue tracker, with all of the abilities that github provides...just have a simple tasks feature which is more like meeting agenda or action items use case than a full on replacement for something else.

Note: we did experiment on this branch: https://github.com/flowy-live/llink/tree/ecosystem-prototype. Experimenting here helps us reason through the nuances of what really matters.

From trying to implement folders, recursive structure, I found that we lost the simplicity of using streams (with open / closed flow). It added problems such as auto-play not working for streams within folders. Moreover, adding events is just not ready. It's asking for implementing calendar and having notifications, a calendar view which aggregates events, where should we place events (folders or streams). This was the case for CRM of contacts as well: people want CRM with custom fields and all sorts of integrations with their communication with customers, not just a "contact record" with some fields like name and email. We have to be careful here. Same goes for issue tracker, with all of the abilities that github provides...just have a simple tasks feature which is more like meeting agenda or action items use case than a full on replacement for something else. Note: we did experiment on this branch: https://github.com/flowy-live/llink/tree/ecosystem-prototype. Experimenting here helps us reason through the nuances of what really matters.
Sign in to join this conversation.