mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
add Shared Account
This commit is contained in:
parent
c4c9bd0057
commit
ea7d2957e2
85
260.md
Normal file
85
260.md
Normal file
|
@ -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).
|
Loading…
Reference in New Issue
Block a user