Draft proposal for @tpto IM command

Author: KittyBarnett

Template.md

@@ -64,4 +64,4 @@ Include links to any relevant discussions, previous RFCs, or documentation.
 
 ---
 
-**(End of RFC)**
+**(End of RFC)**

draft/[email protected]

@@ -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)**