iCentiPay was a payment processor and marketplace, designed to tackle an extremely delicate, yet complicated issue. It was created as a solution as offline payments were not possible at the time for one of the largest economy Minecraft server at the time. To solve this, iCentiPay facilitated off-site transactions with its own ledger and payment system, and a revolutionary automated deposit system, that resembles real life gift cards. Mere offline transactions wasn't comprehensive enough however, to tackle the core issue. Thus, a built in marketplace was added to iCentiPay, to allow for automated ordering -> payment -> delivery system to take place. This type of system has never been made available for the server. Over the course of its operation, iCentiPay had an unprecedented 80% active player base capture rate, and obtained over 250 of the active player base. Its unrelenting growth allowed small businesses to gain access to high profile locations, and convienent delivery system, allowing for better reach, and drove competition. Its industry leading technology allowed for immense growth and adoption from the server at hand. It became one of the most well known corporations on the server, serving 10+ high profile locations, and leaving a legacy for many years to come. The project is no longer maintained, and is no longer operational.

Autopilot was created as a way to have frontier LLMs respond to Discord chat messages on your behalf. It takes converstions completely on autopilot. It expanded to include multimodal features, and tool calls for web browsing, autonomous important memory management, and the use of a vector database and an advanced memory management system to store past conversations and retrieve them. The advanced memory management uses 3 tiers of memory. The short term memory is simply the last few messages, in plain text. The medium term memory then creates a summary of the short term memory periodically, store them in the vector database by use of embedding and storing it in its the memory json file. This is then done once again periodically (once we reached a limit) for long term memory. This cascading memory management system follows principles similar to a human mind. A human may remember the recent past very clearly, but the context and information loss fades overtime. Most importantly, in its default state, the plugin captures emotions, which are contextually relevant to each memory. Finally, a semantic search is done on every message, requesting for relevant medium term, and long term memories. Much like a real human mind, it retrieves contextually relevant, based on the message itself and the emotion it convey, and is finally made available to the LLM for a personalized message output. For web searches, it is delegated to Perplexity's API. Once the tool call is complete, and the search is done by Perplexity, the context is then injected into the conversational chain, and the LLM will act as if it found the information by doing the search itself. This is much like a human, since we delegate our searches to google, then have all the information, then responds with it. The LLM here, henceforth follows a similar pattern. For multimodal image processing, this is done by OpenAI. Images are simply retrieved from the received message, and uploaded. The LLM can also choose to add important memories into its context. For example, if it determines that your name or your favorite color is important, it will make the appropriate tool call. For transparency, messages can also be watermarked so that users know the responder is currently using AI. Code can be edited to support other LLMs. Default only supports OpenAI models. Memory management and storage is done locally, but calls OpenAI embeddings, and messages are sent to OpenAI for processing. This plugin was made for educational purposes. I do not personally condone breaking any terms of service. This project overall can be used as a standalone AI agent that can act as a real person, or can takeover your conversations for you when you need to step away. This project is both open source and was made beginning in November 2024, starting with a small prototype.

EnhancedRPC is forked from Colin Hartigan's valorant-rpc, retaining its Discord Rich Presence integration while significantly expanding remote-control capabilities. It enables users to remotely manage their VALORANT game through Discord commands. These includes queuing up matches, dequeuing, instant locking favorite agents with randomized delays (as to remain compliant with Riot ToS), and quick lobby dodging. The bot also provides detailed match insights including map, game mode, real ranks of both teams, and party composition. Built using Python asyncio and discord.py, EnhancedRPC securely interfaces with VALORANT's local Riot client API. This method allows the program to not require user credentials, preserving safety and security.. An owner-verification mechanism ensures secure command execution, preventing unauthorized access or interference.

In an effort to allow multiple local clients to connect securely to a centralized discord bot, I made a proof of concept, P2P-style communication system between discord bots. It works by having individual discord bots connect to a server. These bots are controlled by the clients. The primary discord bot can then communicate with these bots. When a user sends a command, the host discord bot relays the request, with the necessary information like who sent the request and what the request is, through a shared discord channel to the client discord bot. This message stream then allows for the client to respond, with the information it has, and the host then relays it back to the user. This allows for a singular discord bot to be used to reduce attack surface when distributing programs that require discord communication. This proof of concept was developed for EnhancedRPC, another project I developed. This system simulated a client and server communication, but without an actual communication relay needed to be established. For sensitive information, this is not secure, since the host-to-client communication channel is accessible to the client bot owner. This can be modified to increase security, but there are better methods that supersede this method. However, this method is safe for remote control for users since the protocol requires time-based authentication. It requires time-based OTP-style authentication to ensure that the client and the host are authenticated; otherwise, the message would not be relayed. In the proof of concept, the OTP was generated by a simple mathematical equation known to both the client and the host. If an attacker discovered that equation, effectively the shared secret, they could spoof messages and hijack remote-control commands. In a production version, each client would therefore have its own unique secret, rather than a single secret shared across the entire protocol, to mitigate this risk. This enforced security as authorization is needed for all commands that are issued by any user. Additionally, a client may verify the origin of the request by user ID. This allows clients to safely execute commands remotely, as long as the user account is not compromised. Nevertheless, this protocol can be improved by encrypting requests and signing them by time-based authentication, combined with an ephemeral key exchange such as X25519 or ECDHE and per-message authenticated encryption, which would allow for perfect forward secrecy. But this was abandoned since it was not required for a proof of concept. For production, these improvements would surely help increase the protocol’s security. However, superior communication protocols like https and secure websocket (wss) can accomplish the same thing without relying on an external service like discord. Regardless, the protocol was a cool proof of concept and I really enjoyed making it.