"Chat View" in Fibery

Ideas & Features
, ,
1

I think this was talked about around different posts in the community, but I couldn’t find it’s own post. If I missed it, please merge, thanks!!

There was scandal with Slack recently, so people might be looking for different solutions. Slack has raised our charges by $195k per year | Hacker News

I think chat can be integrated into Fibery as a new type of View. The current implimentation with Threads does not work as well as it could as it based on comments, and not on database entities. It also doesn’t allow for an easy export of the chat messages.

A “Chat View”, (closest to it now is a mix of feed view and comments, but it would need some adjustment) where you define what Rich Text Field should be the main one, as well as any relationships. You can either set up recursive self-relation, which would allow you to reply however many levels deep (like Reddit), or define two databases, Message and Sub-message, allowing only one level deep replies (like slack).

The database set up (as a Slack Replica) would be: Channel → Message → Reply.

Then you can have a smart folder with your Channels in the sidebar if needed, and on the entity view, you have a Relation View which is with the type “Chat”. The channel can then also have multiple entity views for different things, like in slack:
Screenshot 2025-09-26 at 09.18.53

You can also treat different things AS channels. For example, create different product areas as different channels. One thing to think about is if you’d need a different Messages database per type of channel database (product area, generic channel, client), or if it’s okay to have the messages database have lots of related fields that are unused, not sure, and I think this was what led to using comments, as it solves this issue?

It would look very similar to the current “Comments” UI, with some key differences:

  1. It should allow replies based on the data structure.
  2. Allow for filling of fields before sending.
  3. Allow for unlimited nesting of replies (recursive) if data structure calls for it.
  4. Somehow adding an “Unread” indicator which is different per user, and tracking reads/opens.

Anything else I’m missing?

Happy to explain more details is anything is unclear!

EDIT: This topic is similar: "Conversations" for integrations / Email integration

It starts with a different direction, but goes into a similar direction as this idea later.

2 Likes
2

There is Thread view that is experimental and can be activated. This feature is quite nice but is not developed from my understanding. I see how I could utilize it. For example I could use thread view as mirrored view.

However main problem stays with permissions. If I create thread then everybody see the thread (with almost empty content) even if they don’t have permission to the entity the thread is linked to.

I think when team gets to threads polishing we can expect nothing less than perfection but there is no ETA.

3

Agreed!! But sharing that in my opinion having as a data view instead of using comments (how thread view currently works) would be more beneficial long term. But then it’s not just polishing, but changing how the thread view works.

Because just like you said, permissioning with comments isn’t possible at the moment, while access control on database entries is one of the strongest things Fibery has atm compared to competition.

4

So far I see no real benefits by having real databases behind Thread/Chat View.

  1. It is possible to set permissions on individual entities, so visibility of Thread is just a missing feature we did not do yet, but it can be done for sure. So technically you will be able to create special Database and name it Channels and manage permissions for individual channels if you like, or create Thread for some high level existing database entity, like Team X, and make it visible to Team X members.

  2. We are not going to provide deep nested replies anyway. However, if we want to do it, comments are good enough, since they have nesting, we just do not allow to do it from UI

  3. Unread is also can be added to comments

So in general I don’t see benefits using databases under the hood, maybe I am missing something…

5

All valid points. I will give some examples where comments fall short:

  1. Integration (WhatsApp/Telegram/Insta DM). If we wanted to integrate a chat app into Fibery, it would need to be able to show the messages as a chat, and we can’t integrate messages as comments (i think). I think there is a really use case here for customer support in Fibery. Then comments are not enough.
  2. Better control over access. Using comments, you can control visibility of the entity, but not the visibility of the comments inside. For example, if we want people to see the channel, and press a button to “Request Access”, then the channel admin needs to approve. This is quite simple to build using Fibery Automations and Access Control, but not possible using comments. Adding access control to Comments could solve this though.

Adding unread functionality to databases and entities allows for more flexibility and other use cases outside of just for chat. (Especially when chat permissions fall short)
4. Data export. A big reason people are hating on slack, (and I think this is part of the reason for their api changes) is due to the fact they lock people in. You could advertise that all chat messages are easily exportable as a csv.

I understand you might not see the value of using real databases, but I also don’t understand the value of having it as a fake/hidden database. Is it just because of ease of use? What if it was still a field you can add called “Comments” but it would then create a new database called “{Original Database} Comment”, linked it properly, set up notification automations, and defaulted to “Thread View” in the relation view. Would that solve the ease-of-use issue? Are there other advantages to the current implementation? Genuinely curious.

Thanks for engaging the the discussion and explaining your thoughts! Really appreciate it.

6

I resonate with the “better control over access” point. I think awkwardness comes in with wanting comments to be somewhat straightforward on a basic level (i.e., there’s the comment section; make comments, replies, reactions, etc.) vs. more control over access. In our case, we have internal publications, but we can’t use the comments section of these publications or else those comments would be viewable to those intended to only view the published document. There are some ways around this (like cloning an entity and publishing that one without comments), but it adds some technical complexity that is a bit beyond some people. You also have the issue of not having access to previous comments (if the original working publication is deleted) or a “not as clean” database having several duplicate entities.

7

Sidenote: we went a different approach. A database called “Thread” which gets auto-created when the source entity is created and is linked one-to-one to the entity we don’t want people to see the comments of. Then the “Thread” entity just has a comment field, and we dont give access to the thread field for those who aren’t meant to have access. It’s a few more clicks, but might be better than duplicating data once the team gets used to it.

Not ideal, hence this topic, but a different workaround we used for the same limitation.

1 Like
8

This topic is titled as “Chat View” but seems to have become a discussion about possible technical implementation details. I think it would be better to identify the use case that is to be addressed without focussing on how it might be achieved.

Chat View as a topic sounds like a new type of data view.
Whether the underlying data is an entity from a specific sidebar database, or an entity in the comments ‘database’ (see here) seems beside the point, if this discussion is to be had about how best to display ‘comment entities’.
Similarly, the ability to control who can/can’t see a comment is tangential to any ideas about visualisation of the comments themselves, and seems to be the topic of discussion here.

1 Like
9

This was what I was going for.

I think I disagree with what you’re saying though. Because there is already a sort of Chat view: “Thread View” so its important to explain the way the proposed Chat View would be different to that.

I would say this doesn’t have to just be a discussion just about how the view looks, but also it’s functions and features. No? Maybe I misunderstood.

10

Yes, but ideally the focus should be on needs rather than underlying technical solutions/implementations.
And if/where the topic covers multiple areas of possible improvement, there is a risk that we can’t know which bits people are voting for, and/or it ends up diluting votes for overlapping features that already exist somewhere else in the community.

11

Yes, please give us all the details of where thread view falls short :folded_hands:

12

I see.

So I guess then the clear needs are:

  1. Access control for chats (and messages inside)
  2. Custom control over levels allowed for replies
  3. Add extra fields to chat messages
  4. Unread/Read chats indication
  5. Show database entities in a chat layout for things like Whatsapp / Telegram / Other integrations.
  6. Export all the data from chats.
  7. Multiple “Comment” fields. Different areas to chat about the same thing for different stakeholders

Maybe these things can be added to Comments and the current thread view, this is true. But it feels more aligned with a different view type for database entities than comments+thread view features. Hence this idea specifically, and not an idea to improve the current thread view.

3 Likes
13

Brilliant, and clear :+1:

1 Like
14

Fair enough. I probably get a bit too excited whenever I see comment/thread ideas on this forum! Because our team is so mobile, this seems to be the next area in Fibery that would most improve our workflow.

1 Like
15

I have just started playing with threads and especially on mobile it feels like one of the more streamlined and simple way to get information into Fibery. I can seen an application in both a team setting and a personal setting (maybe a private db) where you use a thread as stream-of-thought note taking tool. Feed view is OK for this but still a bit clunkier to use. The note taking use case would benefit from all of the proposed chat features. I also think it would be helpful to be able to convert a single comment into an entity, so you could easily convert that into an existing db when you are back at a desktop.

EDIT: To clarify, I would generally be in favor ok adding the proposed features to comments, as well as implementing a chat view.