Metadata for rooms

[y4my4my4m]

Feature Request

Add metadata to rooms in the same manner that socket.data functions.

Purpose

I want to add some data related to the status/features of a room. I'm creating rooms where one socket is the "owner" of the room, however that user might change, they might reconnect/disconnect. Logically it is better to separate that logic and apply it to the room itself rather than a socket within the room.

Concept

const rooms = io.of("/").adapter.rooms;

const myRoom = rooms.find((room) => {
   return room.data.customVariable = "myCustomValue";
});

console.log(`you've just found your specialRoom ${myRoom}`);

Would also need to be able to set data to it in the same manner we can define socket.data.whatever = {}

[y4my4my4m]

@darrachequesne apologies if this has been previously discussed, I tried to search for a recent conversation but could not find anything like this.

What do you think?

[darrachequesne]

Thanks for opening this :+1: I don't think this has been discussed before.

What would be the benefits of implementing it in the library, instead of in your own application? Do you have some specific features in mind?

[y4my4my4m]

Thank you for your prompt response, @darrachequesne.

I believe the addition of custom metadata to rooms can provide various benefits, both for the library and individual applications. Let me elaborate on these points.

1. Flexibility and Scalability: Having metadata attached directly to rooms can provide greater flexibility and scalability. This feature would enable developers to create more complex, dynamic applications that can adapt in real time to changes in room status or attributes. It would make the room entity more robust and versatile, not just a collection of sockets, but an entity with its own properties and characteristics.

2. Separation of Concerns: By associating metadata with rooms, we are effectively separating concerns - attributes and data related to the room are tied to the room itself, not to specific sockets within that room. This enhances maintainability and readability of the code.

3. Efficiency: Searching for a room based on its metadata could be more efficient and intuitive than searching through all sockets and their data.

Use Cases

1. Chat App

In a chat application, room metadata could store data such as the topic of discussion, last active time, or a pinned message.

const chatRoom = rooms.find((room) => {
   return room.data.topic == "MyTopic";
});

2. Collaborative Workspace/Meeting

In a collaborative workspace or meeting, room metadata could hold the status of a task or project. This could be useful in real-time tracking and updating the state of collaborative efforts.

const projectRoom = rooms.find((room) => {
   return room.data.meetingStatus == "in progress";
});

3. Games

In multiplayer gaming scenarios, where rooms represent game sessions, we could use metadata to store game-related data, like the current score, game state, or the game level. This would eliminate the need for maintaining separate data structures.

const gameRoom = rooms.find((room) => {
   return room.data.currentLevel == "53. Factory Stage";
});

Conclusion

An external user could see a list of rooms and filter by status/type/etc. I can see this be useful even for admin.socket.io's dashboard.

The ability to add custom metadata to rooms would increase the flexibility, scalability, and maintainability of socket.io applications, making it an even more powerful tool for real-time application development. It would allow developers to create more nuanced, dynamic interactions and behaviours, and could open up new possibilities for application features and functionality.

What would be the benefits of implementing it in the library, instead of in your own application?

In more complex applications where redis-adapter is used for example, implenting it in your own application would mean establishing another server/client connection, then manually managing room connections/disconnections and figuring out when rooms are empty to flush the data. Effectively managing the rooms existance in parallel with socket.io.

While it's doable, it seems more like a (prone to bugs) hacky workaround than a proper approach. Having it as a feature within the socket.io ecosystem seems like it would simply be a good extra feature to have.

I know that socket.io is already a very flexible and adaptable tool. However, by adding this feature, we're only expanding its horizon further while having no immediate drawbacks (beyond development cost). I hope this clarifies the benefits and potential use cases of the proposed feature.

Looking forward to hearing your thoughts on this.

[GeneralPancakeMSTR]

Is this why I'm having this problem?

[y4my4my4m]

@GeneralPancakeMSTR

Is this why I'm having this problem?

No

[GeneralPancakeMSTR]

@GeneralPancakeMSTR

Is this why I'm having this problem?

No

That's a very helpful response. Any idea what could be causing my problem?

[y4my4my4m]

@GeneralPancakeMSTR

Is this why I'm having this problem?

No

That's a very helpful response. Any idea what could be causing my problem?

@GeneralPancakeMSTR Make a thread for your own problem, why are you hijacking this one?

[GeneralPancakeMSTR]

@GeneralPancakeMSTR

Is this why I'm having this problem?

No

That's a very helpful response. Any idea what could be causing my problem?

@GeneralPancakeMSTR Make a thread for your own problem, why are you hijacking this one?

I'm not hijacking this thread, I asked a reasonable question and got a rude response. Learn some manners.

[y4my4my4m]

@GeneralPancakeMSTR Make a thread for your own problem, why are you hijacking this one?

I'm not hijacking this thread, I asked a reasonable question and got a rude response. Learn some manners.

"No" is not a rude response.

[marforon]

We also came to the conclusion that we need some metadata for rooms, it would make our work much easier. The only solution around is to manually store these data. I strongly support this idea and we would be grateful for its implementation.