Add check from worlds for validate-player-authenticity
M
Matias Pentreath
Hey both,
Providing some context, the /comms/peers and /comms/islands endpoints were initially developed to troubleshoot communication protocol implementation in Genesis City and to observe how user clusters were formed. Attempts were made to remove these debug endpoints due to privacy concerns, as they could potentially be exploited for stalking and harassment by tracking users globally. However, the community repurposed these endpoints for various projects, leading to the rejection of a poll aimed at their removal.
The Worlds project, introduced later, operates as a central service and, distinct from the Catalyst, did not need to adhere to the same APIs and protocols. Building on past experiences, these endpoints were intentionally excluded. Currently, there exists an endpoint that reveals the quantity of users per realm at https://worlds-content-server.decentraland.org/live-data. However, it lacks the list of wallets associated with each realm.
To address this requirement perhaps we can augment this endpoint by adding an array containing the list of wallets. This would enable to identify the presence of a specific wallet within a realm by utilizing only the realm name but we would explicitly expose the list of wallets per worlds.
M
Matias Pentreath
I discussed the idea of adding addresses with the team, and due to the absence of an archipelago service in Worlds, there are associated costs. This addition would necessitate requests to LiveKit Cloud to verify participants in each room/island/realm, and caching this information for an extended period is not feasible. Another option considered was creating an endpoint that, given an address and a realm, would return true or false based on the participant's presence. However, this presents a similar situation.
A plausible solution be leveraging the signedFetch performed by the client, as the metadata should contain all the necessary information automatically added by the client. Or an alternative, if the scene has a server with a websocket connection, it might be more straightforward and cost-effective to request information about the user from that server.
Nicolas Earnshaw
Hey Quora, thanks for posting this
Please give me a little bit more context of what this would require. The idea is to update this example so that it also serves for checking player authenticity in scenes deployed to worlds?
I haven't tested this in a real scenario, but I believe that should be quite possible with just checking the "realm" field.
The code of the server here even has a function that handles that:
It could be exposed in a more straight forward way that doesn't require digging in so much, but it would actually be a fairly simple thing to do. PRs are more than welcome in this repo if you'd like to take a stab at exposing that in a friendlier way.
Quorra
Nicolas Earnshaw
Hi Nico, thanks for your reply.
I tried modifying it but ran into a problem. Could you please update this example.
In the checkPlayer function (https://github.com/decentraland/sdk7-goerli-plaza/blob/ff7a999f2473f1314f5f6045905c11c50cc457a2/validate-player-authenticity/server/src/security/verifyOnMap.ts), I need to get the player's data from Catalyst Server.
For example: https://peer.decentral.io/comms/peers.
But I did not find a similar API in the Worlds Server (https://github.com/decentraland/worlds-content-server/blob/main/src/controllers/routes.ts)
Is the checkPlayer function necessary?
Nicolas Earnshaw
Quorra
Matias Pentreath would it make sense to add that same API for verifying players in the worlds server?
the checkPlayer function is certainly not necessary tho, it validates that the player is in specific coordinates. In the context of a world, that really doesn't mean much, as any number of worlds could use the same coordinate numbers.
What really matters in the context of a world is that the player is in the correct Realm, as each world has a unique one. So in that case all you would really need to run is the checkRealmName() and checkOrigin() functions, and maybe also checkBannedIPs()
Perhaps it would be nice to restructure this project a bit more, so that all of these checks are easy to toggle on or off via a config file