From 9a1e9ae2ee5601d577d8f45f41f24e722a3b112e Mon Sep 17 00:00:00 2001
From: Kitty Barnett <develop@catznip.com>
Date: Mon, 10 Feb 2025 21:47:00 +0100
Subject: [PATCH] Draft proposal for @tpto IM command

---
 Template.md         |  2 +-
 draft/0001-@tpto.md | 96 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 draft/0001-@tpto.md

diff --git a/Template.md b/Template.md
index f3f8357..fe2b5b7 100644
--- a/Template.md
+++ b/Template.md
@@ -64,4 +64,4 @@ Include links to any relevant discussions, previous RFCs, or documentation.
 
 ---
 
-**(End of RFC)**
\ No newline at end of file
+**(End of RFC)**
diff --git a/draft/0001-@tpto.md b/draft/0001-@tpto.md
new file mode 100644
index 0000000..27f8640
--- /dev/null
+++ b/draft/0001-@tpto.md
@@ -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)**