PaperMC / PaperMC/Velocity

Add a way to directly communicate with Paper servers

Open
#1,488 13 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: feature
Dominant language
Java
Stars
2.3k
Forks
959
Avg merge
5d 10h
Merged PRs (30d)
2

Description

Requested Feature

What I would like to suggest is a feature which is not only tied to Velocity, but also Paper.

In short, I think it would be great to be able to directly communicate with backend Paper servers from the Velocity proxy. This could be done in a way similar to plugin messages (maybe a bit more wrapped together, allowing sending of more complex data types?), where either proxy or paper server send out a message and the receiver may receive and handle it.

Why is this needed?

I think this is mainly useful in case of sending "general" information without the need to rely on a specific player's connection.

Alternative Solutions

Currently, the only way to send information from or to backend servers is using plugin messages. This system has a few flaws though:

  1. It requires an active player connection, meaning you can't just send data at any time (like server startup).
  2. If not intercepted properly, messages from the backend to the proxy can result in a player being able to view those plugin messages.
Additional Information

I have decided to open the issue on the Velocity repo instead of the Paper one, since I feel like this is more a concern to developers who work on proxy servers instead of developers purely working with Paper.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing plugin-message approach described in the issue and the communication paths between Velocity and Paper servers. Define how messages should work without an active player connection, including how complex data is represented and handled on each side. Done means a concrete, agreed protocol and implementation scope exists for both proxy and backend servers.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, backend-api-design, distributed-systems, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.