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 delegation tokens.

The delegator user should be able to inform the delegatee's pubkey to the client through a "Share Account Access" feature.

The delegators 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 delegators "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:

{
  "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 DMs 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).

3.9 KiB Raw Blame History