Skip to content

#1 - Proposal for @tpto IM command #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Template.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,4 +64,4 @@ Include links to any relevant discussions, previous RFCs, or documentation.

---

**(End of RFC)**
**(End of RFC)**
96 changes: 96 additions & 0 deletions draft/[email protected]
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
# Request for Comments (RFC): @tpto as an IM force command

**Author(s):** Kitty Barnett
**Date:** 2025-02-10
**Status:** Draft
**Related RFCs:** n/a

---

## 1. Summary

This proposal extends the IM command set to include a teleport command that allows the sender to teleport the recipient to a specified location.

## 2. Motivation

We already have `@tpto:<param>=force`, which lets users force-teleport someone to a specified location on the grid. By integrating this functionality into IMs, we can streamline the process — provided the recipient has the sender on an `@accepttp` or `@tpto` exception list and teleportation to that location is allowed.

## 3. Specification

### 3.1 Command/Restriction Overview

- **Command/Restriction Name:** `@tpto`
- **Syntax:** `@tpto <slurl|region/x/y[/z]>`
- **Parameters:**
1. `slurl` – A valid SLurl that specifies the destination
2. `region[/x/y[/z]` – Specifies the region and coordinates (Z is optional)
- **Example Usage:**

```@tpto Ahern/123/56/20 ```

### 3.2 Behavior Details
When an IM containing `@tpto` is received, the recipient is teleported to the designated location—assuming the sender is listed as an `@accepttp` or `@tpto` exception.

- Invalid Location: If the location is invalid, the sender receives a silent system message.
- Valid Location: If the teleport succeeds, a notification appears in IM history and as a toast message (see Open Questions below).
- Teleport Cooldown: To prevent abuse, a cooldown will be enforced to block rapid successive teleports that could force a user offline.

## 4. Impact Analysis

### 4.1 Compatibility

n/a

### 4.2 Security and Privacy Considerations

- Are there potential exploits or abuse scenarios?
Since `@accepttp` already allows for arbitrary teleportation (via auto-accepted offers), this addition does not introduce new vulnerabilities—even when accounting for relays.

- Does this affect user privacy in any way?
No.

### 4.3 Performance Considerations

- Does this introduce any performance bottlenecks?
No.

- Any expected impact on resource consumption?
Minimal. The command will be throttled to prevent spam teleports.

## 5. Alternatives Considered

n/a

## 6. Open Questions

#### Who Can Initiate a Teleport?

Three potential approaches:

1. Introduce `@tpto:<uuid>=add` to maintain a dedicated exception list.
2. Extend `@accepttp:<uuid>=add` to cover both auto-accepting teleports and force-teleporting via IM.
3. Implement both options.

#### Transparency vs. Hardcore Mode
By default, force-teleports triggered via IM will generate a notification in IM history, a toast, and/or a nearby chat message for transparency. However, some users—especially hardcore RLVa users—might prefer silent teleports.

One solution could be a hardcore RLVa debug setting that toggles notifications (queryable via `@getdebug_xxx`). This would require a separate RFC.

#### Maturity-Level Considerations
Some users may want to block forced teleports to regions that don’t match their preferred maturity level. Should RLVa include a setting to enforce max/min maturity levels for teleports? This would also require a separate RFC.

#### @tpme counterpart?

`@accepttprequest:<uuid>=add` already automatically accepts teleport offers, but `@tpme` would result in a teleport offer being sent to the sender. In this case, and because the recipient might be unaware, there is a privacy issue so the offered teleport would not include the recipient's location (the 'Join me in...'). If desired, this would also require a separate RFC.

## 7. Test scenarios

TODO

## 8. References

This topic will be discussed at the RLVa office hour.

---

**(End of RFC)**