From ea7d2957e2af190726c16eaa40daeaf2920c4019 Mon Sep 17 00:00:00 2001
From: arthurfranca <arthur.a.franca@gmail.com>
Date: Fri, 8 Mar 2024 16:08:48 -0300
Subject: [PATCH] add Shared Account

---
 260.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)
 create mode 100644 260.md

diff --git a/260.md b/260.md
new file mode 100644
index 0000000..2d956c6
--- /dev/null
+++ b/260.md
@@ -0,0 +1,85 @@
+NIP-260
+=======
+
+Shared Account
+--------------
+
+`draft` `optional`
+
+This NIP introduces a standard way to share account signing privileges without revealing its privkey.
+It uses time-released delegation events to get around the irrevocability property of [NIP-26](26.md) delegation tokens.
+
+### "Share Account Access" Feature
+
+The `delegator` user should be able to inform the `delegatee`'s `pubkey` to the client through a "Share Account Access" feature.
+
+The `delegator`s client then pre-generates a set of "Delegation Delivery" events to be released on their `write` relays by a "cron-like" (scheduler) service at each event's `.created_at` moments.
+
+Each of these events holds one NIP-26 `delegation token` and a corresponding `condition string` covering a *very narrow* `created_at>A&created_at<B` time window such as 3 hours. The time windows are expected to be contiguous, with the complete set of `condition strings` together covering a wider period such as 2 weeks.
+
+The `delegator` at any time should be able to ask the client to disable the "Share Account Access" feature.
+Then their client should ask the scheduler service to delete "Delegation Delivery" events yet to be released, effectively
+preventing future use of the delegation.
+
+Ideally, the scheduler service shouldn't have access to the `delegator`'s privkey
+but just store the "Delegation Delivery" events to be published.
+
+### "Use Shared Account" Feature
+
+The `delegatee` user should be able to inform the `delegator`'s `pubkey` to the client through a "Use Shared Account" feature.
+
+Before publishing an event, the `delegatee`'s client should fetch the latest "Delegation Delivery" event of the `delegator`
+from one of the `delegator` write relays and use the embedded token in accordance with NIP-26 spec until it expires.
+
+After token expiration, the `delegatee`'s client is expected to repeat the procedure of fetching and using the latest available
+`delegator`'s "Delegation Delivery" event.
+
+Disabling the "Use Shared Account" feature means the `delegatee`'s client will stop fetching and using `delegator`s
+"Delegation Delivery" events delegation tokens when publishing new events.
+
+### "Delegation Delivery" Event
+
+The "Delegation Delivery" event is of `kind:1026`, the `.pubkey` is the `delegator`, there is a `delegation_delivery` tag
+with the `condition string` and the `delegation token` as array elements and a `p` tag with the `delegatee`'s pubkey.
+It must have atleast one `k` tag and each should be set to the (required) `kind` field values present on the `condition string`.
+It should have an `expiration` tag with the value set to the delegation expiration condition.
+
+Event example:
+
+```js
+{
+  "kind": 1026,
+  "pubkey": "<delegator_pubkey>",
+  "tags": [
+    [
+      "delegation_delivery",
+      "kind=1&created_at>1702711000&created_at<1702721800",
+      "6f44d7...e5f524"
+    ],
+    ["p", "<delegatee_pubkey>"],
+    ["k", "1"],
+    ["expiration", "1702721800"]
+  ],
+  "content": "",
+  "created_at": 1702711000 // future time when the delegation starts to count
+  // ...other fields
+}
+```
+
+### Relay Support
+
+A relay may act as a scheduler service by allowing the publishing of `kind:1026` events with future `.created_at`
+values while also never sending such events with future timestamps to users other than the author.
+
+### Use Cases
+
+- Enable employees to publish `kind:1` events on behalf of an enterprise account.
+`Delegatees` should publish to the `delegator` relays.
+Reading client's interface should display the `delegator` as the delegated `kind:1` events' author
+(e.g.: show just the `delegator`'s avatar picture);
+
+- Enable employees to publish `DM`s on behalf of an enterprise account.
+`Delegatees` should publish to their own relays.
+Reading client's interface should display the `delegatee` (**not the delegator**)
+as the author of the delegated `DM` events and indicate it is speaking
+on the company/`delegator`'s behalf (e.g.: show both accounts' avatar pictures).