Datastructure for multi-cast type of message broadcasting - firebase

Question

We are thinking about migrating from Pusher to Firebase. We are having troubling thinking about how Pusher channels would be represented in Firebase.
In Pusher we have a channel per user. So a user might be in a user-1 channel, another might be in a user-2 channel.
Then our backend/server would send a message to both these users via Pusher.trigger(message, ['user-1', 'user-2']).
I think this would usually be done like this:
{
web_page_1: {
user_1: {
messages: [{}, {}, ..],
},
user_2: {
messages: [{}, {}, ..],
},
...
},
web_page_2: {
user_2: {
messages: [{}, {}, ..],
},
user_3: {
messages: [{}, {}, ..],
}
},
....
}
Here the problem is: User 1 and User 2 for the same page might have a lot of messages in common. Is there a way to reduce this duplication, since these messages can get rather large, sending and storing them per user can get expensive. Also User 1 should not be able to read the messages of User 2.
It would be nice to do something like this:
{
web_page_1: {
message_1: {
user_ids: [1,2,3]
content: {},
},
message_2: {
recipient_ids: [3,4,5]
content: {},
}
...
},
web_page_2: {
message_1: {
user_ids: [1,2,3]
content: {},
},
message_2: {
user_ids: [3,4,5]
content: {},
}
},
....
}
But then, how would the security policy be applied such that a message can only be read by the user_ids specified in it.
Any pointers would be really appreciated.

Answer 1

If multi-cast is your use-case and the messages get large, I would indeed split the messages from the users and add message-references to the users like you show.
Root
Users
provider:344923
Name: Akshay Rawat
Messages
1: true
2: true
3: true
provider:209103
Name: Frank van Puffelen
Messages
1: true
Messages
1: It's a beautiful day
2: The sun is shining
3: I feel good, I feel good
4: And nothing's gonna stop me now
In the above data you can see that you and I are users. The provider:... is our uid, but can be anything that allows you to identify the current user. You've received messages 1, 2 and 3, while I have only received message 3. Neither of us has received message 4.
I took the Web_page level out to simplify things a bit. If you really need that level, you can add it back. The basic approach will remain the same.
You security rules can then use these message-references to see if the use can read a specific message:
{
"rules": {
"Messages": {
"$message_id": {
".read": "root.child('Users/'+auth.uid+'/Messages').hasChild($message_id)"
}
}
}
This rule defines the security for any child under messages (identified by $message_id). We grant read access if the $message_id is references as a message for the current user (auth.uid).