Udon Discord API Integration
『
『Schwi』
Proposing an Udon wrapper around the Discord API for world creators to create more immersive worlds.
Discord already has an extensive API to interact with their services, poll servers for users, grab their groups, post messages to channels, retrieve messages from channels, etc..
The amount of new and exciting things creators could do in their worlds if they had this ability is almost endless.
I feel like this is an especially important and needed feature of the game, especially since crafting URL's at runtime is still being artificially disabled.
The entire Discord API does not need to be exposed from the get go, not that it would be very difficult to do.
Errors are already returned in JSON format which means they can easily be parsed in Udon without any additional development required from VRC devs.
Interacting with the API is a simple HTTP/REST library requiring you to formulate your request inside of a JSON object, so again, not much is needed from VRC devs to expose the ability for us to start interacting with the Discord API.
Essentially we just need https://discord.com/api whitelisted and an object that cant post and receive a JSON 'payload' to/from the URL.
Thank you for your consideration, I know this will be a widely appreciated feature for world creators and players.
Log In
『
『Schwi』
The only other hurdle/roadblock to this implementation I can think of would be rate limits from discord.
The rate limits are extremely well defined, each request payload can ask for information about the current rate statistics. Users can then use this information to slow/queue their requests based on how close they're getting to hitting their limits.
Obviously a naive developer will not handle this properly and must be extrapolated out on VRChat's side.
It would be simple enough to ensure any JSON request leaving a world has the proper fields set/injected to ask for rate information prior to sending it off to discord. Then when a response comes in, the rate information can be read out and handled appropriately at the VRChat level before sending the response JSON all the way back down to the world.
It really should just be that simple.
This will avoid any novice world creators from spamming discord and getting VRChat's discord bot on the backend flagged and blocked. Extrapolating the rate handling away from creators would also remove one of the barriers of entry from creators to more freely implement their ideas with the API.
Rate handling from discord works on a few different levels, there are separate rate statistics tracked on a per API key level as well as on a per bot level.
I imagine VRChat would have a sort of load balancing system put in place for their discord bots, similar to how the world instances are spun up and down. I'm not sure what the server architecture looks like on the backend, I would hope its something like an individual docker container per world or per world instance running in a large Kubernetes cluster, but hey, probably not that streamlined and efficient.
Either way, the rate limits can easily be handled and extrapolated away from the users.
VRChat could also reach out to discord and see if they qualify for increased rate limits (which they no doubt would qualify for)..
If anyone else sees any potential roadblocks to my proposal here thus far please feel free to leave a comment.
『
『Schwi』
Okay, I know what you are saying. Discord requires an API key to interact with their services. Yes it does and anyone sniffing outbound packets on their computer can grab your API key.
Yeah, this sucks, but we don't have the ability to generate VRCUrl objects at runtime which would completely mitigate this issue, so I have some ideas about that.
- Allow world creators to specify their API key during upload, just like we already do with name/description/tags..
- Give us a new object we can call like Networking.PostDiscordAPI(VRCJson)
- Give us a new networking event like OnDiscordAPIResponse(VRCJson)
Creators can formulate their JSON payloads to send to the Discord API and send it off via PostDiscordAPI(), they pass in their VRCJson object and OMIT their API Key.
The JSON is sent off to the backend server running the current instance, the server-side inserts the API Key specified during world upload and then the request is sent off to api.discord.com
Discord will return the response back to the backend instance server, this will then forward the JSON received from discord down to the players in the instance through OnDiscordAPIResponse()
The JSON response can be parsed as needed at this point since we're back in happy creator land again.
Calls to PostDiscordAPI() could be heavily limited to once every 30 seconds per active instance as these JSON payloads could end up being quite large depending on what is requested. Testing would be needed here.
This will keep our API key's out of reach of onlookers since the key is only handled on VRChat servers (this is the exact same way people WILL accomplish this as soon as we can create urls at runtime, requests will just get forwarded to 3rd party community ran webservers).
All that being said, I don't think there's too much of an issue having our API key exposed assuming permissions on the key have been locked down to read only and at the very most possibly permissions to send messages. This however is obviously extremely limiting. Even with the ability to craft url's at runtime, this system may still be highly desirable to eliminate the need to run 3rd party servers to handle requests. If these communities die and servers get shut down, large portions of functionality in instances may cease to function. Having the system outlined above would eliminate one potential point of failure and keep instances alive without requiring a 24/7 service ran by a 3rd party (other than Discord of course).
That's all I have on the subject for now. I think this is a completely viable and doable solution offering full range of access into the Discord API and while keeping all the sent/received data inside VRChat and Discord's sphere of influence.