[Feat]: New Assembly - Message Relay

[blurpesec]

Motivation

Part of discovering the Trinary will be discovering and interacting with player-hosted services. This can be things like buying a ticket to access some faction's gate network for the next 30 minutes or a fully-fledged trading hub. Discovering how you, in a random flyby, are intended to use these services will be a challenging task. To that end - i'm dredging up a proposal from >12m ago.

Details

A network node owner can deploy a message relay assembly in game. When a player travels in proximity of that relay - CCP's server sends an in-game mail through to the player. The relay should have an extension interface that allows the structure owner to dictate what message they want to send to players in proximity.

Personalization

We can utilize message templating variables to personalize messages to players (rendered on either server-side or client-side). To start, this could cover just a basic target player name.

Hello ${{ targetPlayer.name }},

Please visit the Ticket Machine SSU to purchase a 30m gate pass for 1 $EVE or a daily pass for $10.

Thank you for your patronage,
Deep Space Infrastructure Services

Risks

Message content cost

It is going to be too inefficient (read as: expensive) to place full messages on-chain - so perhaps the method could be tied to a content-addressed file service like IPFS (with the content id being the unique key that appears on-chain pointing to the file that should be used to generate the message). The way content-addressed files work are by running a hash function on content of the file contents - such that any change to the file contents results in the file's content id (hash) changing.

Since content-addressed files don't change, in your indexer you would only need to download the file from IPFS when it's first seen (with a TTL on refresh if initial resolution fails), sanitize / scan for phishing risk, and store in an object store (again - addressed by content ID) and serve to users when they come in proximity.

Security

Having a generalized "serve this file directly to players" interface introduces a lot of security risks. The worst case scenario would be one of the following:

1. Players coming in proximity of the Message Relay are served directly to their in-game mail with phishing links.
2. Players coming in proximity of the Message Relay are served with message content that is improperly sanitized resulting in some type of script execution on mail open within their client.

These risks can be alleviated to a large degree by:

1. Strict message sanitization (including message string character-level allowlists)
2. Instituting strict content rules - no URLs, no embedded images, etc.
3. Be liberal with bans for players who break the rules + make these assemblies only accessible to be deployed by players with active subscriptions (imposes added economic cost to use this avenue for phishing).
4. Only allow specific file types (text/markdown).
5. Create tooling in-game (and open source scripts) for validating the message files players create - so it's less likely that players run afoul of content rules.

Message spam

Players will inevitably get tired of receiving the same messages repeatedly for commonly-travelled paths. Therefore - allow players (in their client or via server-side blocklists) to block messages by content ID.

[0xxlegolas]

Interesting proposal. If the goal is discovery, we could also use advertising banners in high-traffic flyby areas. We have discussed deploying structures for this like rentable ad space for services like "access to some faction gate." Content could be stored in Walrus (Sui's IPFS equivalent).

Is the goal to solve discovery (with Message Relay as one option), or is Message Relay specifically needed this ?

[blurpesec]

Interesting proposal. If the goal is discovery, we could also use advertising banners in high-traffic flyby areas. We have discussed deploying structures for this like rentable ad space for services like "access to some faction gate." Content could be stored in Walrus (Sui's IPFS equivalent).

There are probably two types of "discovery" here:

1. Advertisement-like service "discovery" - Discover a new service/tool/etc.
2. Instructional "discovery" - "I see a smart gate on a common route I travel. How do I use it?"

The mechanism could probably be the same behind both. Advertising vs deployable structure? Could go either way

[0xxlegolas]

Great. That means we can avoid an email service and keep the system simpler.