mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 08:55:52 -05:00
86 lines
3.9 KiB
Markdown
86 lines
3.9 KiB
Markdown
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).
|