[Feature] customData on room and message objects

[gileswells]

If there are additional settings that could be stored on the room object for a chat I think that would be beneficial overall. Could be exactly the same as it exists for the user object. This customData could be used for things such as:

• custom display preferences for a specific room
• high priority messages could be denoted in there
• if there are larger chat rooms and moderators / admins need to get a message out we could use customData to set sticky messages or motd. That could be placed in either the room's customData or the message customData or both so it could be applied real time and also when the room is first subscribed to.
• publically "joinable" rooms but use customData to add the pre-requisites to be allowed to join the room.

I'm not saying that these features wouldn't be possible on our end and it would be on us for how we use this customData but having it available to us in this manner might make extending this beyond a basic chat platform easier.

[hamchapman]

Hi @gileswells!

This is something that we've discussed internally as being potentially useful but haven't prioritised it because we weren't completely clear on what the use cases would be.

I've got a few questions about the points you raised as potential use cases

custom display preferences for a specific room

What do you mean by display preferences here? Is it a question of displaying a given room differently in your UI based on some room metadata? Or something else?

high priority messages could be denoted in there

Is this like making certain messages "sticky" or "pinned" in a room? Is this different to the third point you made about sticky messages or motds?

publically "joinable" rooms but use customData to add the pre-requisites to be allowed to join the room

What sort of pre-requisites would you like to be able to enforce when determining whether or not a user should be able to join a public room? Are they things that are difficult or impossible to encode into a set of roles & permissions with the current authorisation system we have?

Thanks a lot for the thoughtful feedback!

[gileswells]

All of these use cases could be done with a local database on an app. My thought here it to have Chatkit allow for some arbitrary storage so that there is no need for a local database beyond storing the user_id in our database. In the end my thought is that why can't Chatkit be infinitely extensible in a way that just allows us as the developers to set a room setting, or a message flag on the items themselves without needing their own persistent storage.

custom display preferences for a specific room

So if there was an app out there that wanted to allow for different things to be set like background photos or things like that. Like I see your platform as being able to expand and be extensible in most places and for instance if this ever went onto a virtual school platform the teacher might want to be able to add custom display properties for that specific room.

high priority messages could be denoted in there

Basically the same thing BUT this I think has the best argument for inclusion. If I was to add any of these flags to a message, based on it's id, in a local database I would need to have my newMessage handler on the subscription make an AJAX call to my app every single time a message is received to see if there are any flags on it. New Message? Is it high priority? Is it sticky? Is it an admin message? (yes these would all be in one ajax request) If those flags came directly with the message itself then it would be much more efficient on my app's end. 99.9% of messages wouldn't have anything but it would be immediately useful.

publically "joinable" rooms but use customData to add the pre-requisites to be allowed to join the room

This could be something like if there was a room that only allows people that are a certain membership level it would have to be public for someone to see it but then room:join would be disallowed and you'd have to let _superuser add them on the back end.

[gileswells]

My main point is not that it's known what these would be used for. That's up to the individual developers to take this extensibility and bend it to their whim.

[teminer]

Thanks for the great feedback, @gileswells! I've added some investigation items in our backlog for these.

[gildebrand]

I'll add in and request this feature as well. We need it to send custom messages with actions attached to them. We would like to attach meta data to a message object containing some ID numbers and action type.

[gileswells]

@gildebrand This is something we're going to be needing as well. Our future plans need the ability to attach other elements of the app to a message like an attachment only it's not a file. Being able to pass something like this through a message and then handle it in the onNewMessage handler would be huge.

{ projectId: 1, status: "pending-approval", action: "show-approval-buttons" }

[gileswells]

@teminer any word on those investigation items?

[teminer]

@gileswells @gildebrand This is something we are now definitely committed to doing, however since we just had some significant refactors (and a few more incoming for reliability purposes), it hasn't been prioritized quite yet. (Generally, I'm not a fan of adding new features during refactors nor when trying to fix anything wrt reliability as it can muddy the triage waters)

When we add it to an iteration, I'll update here.

[teminer]

(btw I'm linking this issue to our ticket so whomever implements it can reach out to you for Qs when the time comes)

[harrisrobin]

I also found us needing this.

Our use case is sort of like airbnb. We have a page that displays rooms (conversations). You can think of the conversation as being about a specific listing(home) and in our conversation we want to show information about that specific listing. We could have put that information in the room but instead were having to do unecessary database calls when we could have actually just handled this with chatkit because for us a room is only useful in the context of a listing, so that data can coexist forever.

[eveevans]

Same case for Us, We call it context. Each conversation is related to a specific topic on our App, so we did a dirty name convention on rooms, to store our polymorfic id association, and call it on our App each time a room is opened.

Room's custom data will be very usefull and flexible.

[teminer]

Hey All - Just to update you on this feature request, we have determined a design and spec'd out the work, but need to prioritize a few GDPR requirements ahead of it. That said, as soon as the GDPR work is done, we will be jumping on this. The team is quite keen on getting it implemented for you all! :)

Thanks for all the feedback, keep it coming!

[gileswells]

Damn that GDPR...

[gildebrand]

@teminer do you have an ETA on when the customData feature will be available on rooms an messages? 😄

[teminer]

@gildebrand It depends how quickly we are able to get through GDPR requirements. In the next month for sure, as it will be the next thing we pick up.

[gildebrand]

That sounds great @teminer!

To be able to have custom data I made a horrible workaround; try to parse every incoming message as JSON, and if it's a JSON object, treat it as customData. Works until the users start sending JSON. Or well, we aren't in production yet so hopefully we can implement a better solution before going into production 😄

[teminer]

@gildebrand (and everyone) I want to provide you an update here... so we finished all the GDPR work but had a few live incidents and discovered some issues along the way and we are addressing those before adding any new features. We want to make sure the core functionalities are reliable and scalable to meet the quality bar Pusher is known for ASAP.

While this does mean customData will be a bit delayed, we are still committed to delivering it to you - we just want to deliver you a higher quality core chat product first. Please feel free to reach out to me if you have any questions or feedback.

[senky]

+1 for this, really waiting for it!

[ciaoamigo]

time?

[mdpye]

Custom data is now available on rooms in all SDKs.

It works similarly to custom data on users, but with the added bonus that updates to it are propagated in real time via RoomUpdated events, same as when a room name or privacy is updated.

Messages won't be getting custom data, but something more flexible instead. In the next version of the backend APIs, messages are made up of an arbitrary number of parts of different types. Some parts text, some parts links, some parts images etc, what goes in them is really up to you. That means that you can add custom part types and custom data within them, no nead for a custom data field.

Because it's more flexible and a significantly bigger change, this is not quite ready yet. We hope to provide it by the end of the year.

[bogdand92]

@mdpye Hi! What about this?

Messages won't be getting custom data, but something more flexible instead. In the next version of the backend APIs, messages are made up of an arbitrary number of parts of different types. Some parts text, some parts links, some parts images etc, what goes in them is really up to you. That means that you can add custom part types and custom data within them, no nead for a custom data field.

[GlebkaF]

@mdpye Hey! We are looking forward to this feature. Any news? Expected delivery time?

Messages won't be getting custom data, but something more flexible instead. In the next version of the backend APIs, messages are made up of an arbitrary number of parts of different types. Some parts text, some parts links, some parts images etc, what goes in them is really up to you. That means that you can add custom part types and custom data within them, no nead for a custom data field.

[mdpye]

Very soon!

[mdpye]

Sneak peek: https://github.com/pusher/chatkit-client-js/tree/api-v3

[callum-oakley]

Rooms and messages both now support custom data.