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).