Regarding the alias name Limit in Multiplayer Games

Ashley, isn't this interesting? Wouldn't you prefer to see Construct have this kind of crypto-integrated multiplayer game, rather than me having to set up my own Signal server and losing loyalty over it?

I don't see why you have to put that information in the alias. You could just send it as a message instead.

Hi Ashley

Since I want the game to be completely decentralized, the game's data and settings rely on the distribution of data between users in a decentralized way. Private and voting-based information...etc (like determining a character's attributes) will be verified by users' signatures by crypto private key. Through person-to-person interaction and data accumulation, decentralized interaction is achieved. The client's WSS connection is limited, and players need to synchronize with delay to reach a consensus(group by group). Since our multiplayer games (WSS server) do not have a registration mechanism, players cannot always get a consistent alias from the signal server. The most effective and verifiable way to asynchronously track other players is by using a public key as an alias name(#PubKey&random word). Other players can then use the signal server to identify the owner of the public key and verify their private key through a P2P connection. This is why I hope to extend the alias length, so that users can instead find the target player from the signal server as needed to play the game, no need to maintain connections with everyone else in the world to fulfill "ONLINE GAME".

I still don't see why you can't just send a message. Send what the alias would be when someone joins. That sounds like problem solved to me.

Let me explain my online game connection mechanism clearly. Initially, each player host a room by themselves, independently broadcasting their messages in a one-way manner Host. Players then join other hosts' rooms to receive information in a one-way manner. The method is to open multiple iframes as receivers, transmitting and receiving messages via web storage, and sending the received messages back to the main page(logic C3). This is the communication structure designed for C3. Since players are not in the same room, but each player hosts a room as a broadcaster, if the room name and the visitor alias are both the public key, for information containing the public key is the most suitable and simplest. The user directly connects to the target via the signaling server, and the host directly knows the "reverse lookup" address via the visitor's alias. This avoids the need for a two-way public key exchange in the ideal one-way communication environment and prevents public keys in the message records from becoming useless information, as they cannot be directly used as a valid lookup address. You just need to allow the room and alias names to have a longer length. I will bring you a decentralized multi-player environment based on C3, not just a small game with dozens of people. It will be a global asynchronous consensus game environment. This simple change will help and there’s no reason to reject it. Allowing a longer length doesn’t cause harm, like other developers' local length limitations are easy to address, also even when a regular text object is too long, there will be no issue. I hope you can make this issue more flexible and agree with my heartfelt request. Please don’t respond to me in that overly formal british corporate manner, like those fallen old companies.

It sounds like you have a use case that is significantly different to what the Multiplayer feature was designed for. Suppose someone came along with some complicated use case that, for whatever reason, involved a base64-encoded WebP image of their profile picture that had to be set as their alias. Should we increase the alias length to something like 64 KB to allow that use case? I think the answer is one of "work around it", "you shouldn't do that" or "it's not designed for that". Perhaps in your case you'd be better off using the WebSocket object and running your own custom service.

The user directly connects to the target via the signaling server, and the host directly knows the "reverse lookup" address via the visitor's alias. This avoids the need for a two-way public key exchange in the ideal one-way communication environment and prevents public keys in the message records from becoming useless information, as they cannot be directly used as a valid lookup address. You just need to allow the room and alias names to have a longer length.

What exactly is wrong with a quick "two-way" communication, simply to send the public key? By initially connecting, it's essentially like a two-way connection anyway. Then simply sending one message (also verifying the connection is 100% ready). Most designs of networked system have a "handshake" message.

Is it a security thing? Efficiency? I can't think of a valid reason why you can't just "Send message". Messages can be like 256kb (and they're compressed so can be even bigger). Connect, peer sends 1 message, host sends 1 message, end connection. Done. What's the problem?

Why am I even thinking to assist, you're extremely rude. I don't know what it is about crypto that often attracts such self-righteous personalities. Instead of being so stubborn with your design, work with what you have, especially when you are indeed doing something C3 was not designed for.

EDIT: Instead of relying on a company's signalling server whom you clearly seem to have disdain for, you can buy it yourself and host it on your own server, change alias limits or whatever (Whether that is an intentional setting Scirra chose for their public signalling server, or if it's a hard limitation within WebRTC, who knows). construct.net/en/game-assets/tools/multiplayer-signalling-server-2