multiplayerpiano-server-snippets

These are snippets of code given over the years of the official server's (closed source) code.

This documentation is second-level official. That means we are not Brandon but we have reviewed previous official material (in some cases, no longer/never available to the public) to find this information.

Snippet info

The snippet in databaseUserPull.js might not be from the official server, but it was written by Brandon.

Complete files folder

All complete files that are from the server that have been found are in this folder.

Proven facts

• The original server has a static folder with the hosted site files inside it. The folders sounds and .well-known have unknown contents and were not given out, possibly along with other unknown files.
• The original server used Express to host files.
  • The sounds folder may have been another express route, given that these files were not included in the original sounds folder.
• The original server has RateLimit.js.
• The original server was hosted on Linode for roughly $20.00 per month.
• The original server utilizes killall node or equivalent measures to balance other processes.
• The original server has more than one script (duh).
• Brandon wrote the code in a way that refers to live user data as a "participant", usually p for short.
• The original server has undocumented channel settings.
  • lyrical notes (boolean)
    • This was meant to enable the piano "singing" the last chat message the user sent.
    • This was never completed.
  • owner_id (string)
    • This setting was used, but it was not changeable by the users in the room by normal means.
    • This setting would allow the participant with the _id of the setting's value to grab the crown by simply joining the room.
  • no cussing (boolean)
    • This setting was used and users could enable it, but the feature was not fully implemented. The only effects this had were a banner similar to crownsolo that reads 'This room is set to "no cussing."' and there was no extra filter that this setting enabled.
• The original server utilized prototypes instead of classes.
• The original server used mongodb
  • The user data is stored separately from participant sessions (p.user) and is transformed when sent to clients.
    • _id (string): This one is the hash of the user's connection, usually an encrypted IPv4. It is always 24 characters long.
    • name (string): This is the user's name.
    • color (string): This is the color of the user.
    • flags
      • This property would allow certain settings to be applied.
        • Known settings
          • volume (number): This key is not proven. This is the volume of the user's incoming notes. This was supposedly used to mess with overplayers in the lobby.
          • chat_curse_1 (number): This key is proven. This is enabled by spooky.js. It changes the user's incoming chat messages by replacing every vowel with the letter 'o'.
          • chat_curse_2 (number): This key is proven. This is enabled by spooky.js. It changes the user's incoming chat messages to complete gibberish.
          • freeze_name (number): This key is proven. This is enabled by spooky.js. It freezes the user's name, making it impossible to change it. This may have been the cause of the database issues in 2020, where all participant documents were affected and the decision to wipe the database was made.
          • cant_chat (number): This key is proven. This is not known to be enabled at all. It stops the user from chatting at all.
• The original server had no way to change the user's color without admin privileges.
  • At some point, color changing was enabled, but it caused issues when users were copying other users' names and colors, so Brandon disabled it.
• The original server blocked the chat messages "AMIGHTYWIND" and "CHECKLYHQ", supposedly functioning alongside .toLowerCase().split(' ').join('').match().
• The original server was modified by jacored (the new owner from China) and all semicolons were removed. This causes immense pain to many eyeballs.
• The original server sent the message data to certain clients. The means necessary to receive this message are unknown, but there is concrete speculation.
  • The following message is sent in spooky.js: client.sendArray([{m: "subscribe to admin stream", password: password, interval_ms: 10000000}]);
    • This message would possibly let the user receive the data message from the server.
    • Oddly enough, this message is not sent through admin message and instead accepts a password.
    • The following proven properties of the message contain info about the server.
      • channelManager (object): This is an object that represents the server's internal channel structure.
        • channels (Array<Channel>): This is an array of channel data.
          • _id (string): The name of the channel.
          • participants (Array<Participant>): This participant data is unlike any other data received by the client. The participants have their own (currently unknown) properties that appear to be a superset of the client participants.
            • user (Client-side participant?): This property (probably?) contains data that is usually sent to users.
              • _id (string): Participant ID
              • name (string): Participant username
              • color (string): Participant color
• The original server accepted admin messages with a password.
  • The password was usually read from a *.txt file in some of Brandon's other scripts, so we don't have the password.
  • Admin messages could deal with user data.
    • user_flag: This message changes user flags on the server.
      • _id (string): The ID of the participant to modify.
      • key (string): The key of the flag to modify.
      • value (number?): The new value of the flag.
    • color: This message changes a participant's color.
      • _id (string): The ID of the participant to modify.
      • color (string): The new color (in hex).
  • There are unknown admin messages that handled IP and proxy bans.
• A class called ProxyScraper was once responsible for banning many proxies at once to keep the site's spam to a minimum (that didn't turn out too well by 2019)
• Brandon used to add pages and pages of proxies to the proxy banlist himself using an admin message
• ProxyScraper used the "proxy-lists" module
• The original server had dynamic rate limits.
  • Sometimes, users refer to this as quotas, but that terminology is only used with the note quota.
  • The cursor rate limit was 20 FPS.