I was just going through the project, really great work. But when I try to run the same locally it works fine sometimes and in some cases, i get the following error while creating the room

room.js:507 Uncaught TypeError: Cannot convert undefined or null to object
at Function.keys ()
at Gun. (room.js:507)
at Object.val (gun.js:1837)
at gun.js:1831

This leads other participants to be unable to join the room. Can I get any help regarding the same?

Simple Room Rules

• Room creator or owner should be the only active speaker in his room, and cannot be removed. (speaker)
• Room participants are read-only by default. They should not offer webrtc audio, just receive it from SFU like a podcast. (mute)
• Room participants can request a 'speaker' status from one of the Ops in the room to become speakers (request)
• Room creator can 'accept requests' of others to become speakers and negotiate two-way audio. (co-speaker)
• Room speakers explicitly muted by a creator/owner loose all rights and become read-only (mute)
• Room speaker can mute themselves without loosing rights. Nobody can unmute anyone from an audio standpoint.
• Room creator can lock or destroy the room at any moment. When the creator exits, the room and all peers are destroyed.

Bonus Features

• Implement speaker screensharing to the room, only one allowed, full screen broadcasting mode.
• Implement automute speakers after silence-idle time in audio analyzer
• Implement ban/kick anonymous users (using fingerprint.js)

The distributed client-side room management logic is very basic and prone to distributed failures (split brain, abandoned peer objects, nulls, etc)

We need to redesign it to fully leverage the potential and provide a stable approach for room permission management.

During beta, channels are owned by their creating browser fingerprint which can terminate/lock them. Since we have no user authentication this is quite ephemeral to the same session and assuming all rooms will be wiped when the last participant leaves. A potential idea is to add an option for rooms to be self governed by the current majority using a quoroom approach - where the mob can act as an admin effectively. An organized anarchy?

• force-muting or kicking out someone? vote.
• renaming or terminating the channel? vote.

Ideas?