Compare commits

...

14 Commits

Author SHA1 Message Date
Arc
133fc0f182
Merge 2ec7833e8e into a1ca7a194b 2024-12-11 11:44:52 +00:00
Jon Staab
a1ca7a194b Change strategy for naming groups 2024-12-10 19:25:28 -03:00
ben
2ec7833e8e payment_hash needed to identify payment 2023-04-12 17:33:17 +01:00
ben
56c8556855 added some bits 2023-04-12 14:13:39 +01:00
ben
0bc0c7d317 rephrase 2023-04-12 14:11:21 +01:00
ben
91c2a8a8c9 removed shameless lnbits link 2023-04-12 14:08:16 +01:00
ben
db5b8c7d4a rephrase 2023-04-12 13:59:24 +01:00
ben
00218c6de9 Added BC to authors 2023-04-12 13:41:39 +01:00
ben
32bd6de504 Added permission example 2023-04-12 13:39:33 +01:00
ben
3a09d4aa7c typo 2023-04-12 13:34:26 +01:00
ben
459b10793a typo 2023-04-12 13:33:02 +01:00
ben
a8ea432727 typo 2023-04-12 13:31:28 +01:00
ben
3a1393a861 Cleaned json 2023-04-12 13:27:24 +01:00
Arc
5d4d79228a
NIP-83 Wallet connect/bridge
Useful for clients wanting to intergrate non-custodal wallet features.

> Intended for use with bitcoin, but could be used with any invoice payment system that can pay invoices/create invoices/check payment status.
2023-04-12 13:24:27 +01:00
3 changed files with 95 additions and 3 deletions

4
29.md
View File

@ -30,8 +30,6 @@ When encountering just the `<host>` without the `'<group-id>`, clients MAY infer
Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
## Timeline references
In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
@ -242,3 +240,5 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
### Using `unmanaged` relays
To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.

2
51.md
View File

@ -29,7 +29,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |
| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) |
| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |

92
83.md Normal file
View File

@ -0,0 +1,92 @@
NIP-83
======
Wallet connect/bridge
--------------
`draft` `optional` `author:arcbtc` `author:blackcoffeexbt`
Useful for clients wanting to intergrate wallet features, could be custodial or non-custodial or both.
> Intended for use with bitcoin, but could be used with any invoice payment system that can pay invoices/create invoices/check payment status.
## Motivation
All bitcoin lightning wallet clients connected to nodes use http, they should also be able to use nostr.
Simple plugins/middleware/libraries could be easily made for existing nodes and lightning wallet software.
## Examples
There are two simple clients sending json over [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). These clients could be standalone or built into clients/services.
1. `funding source client`: Connected to the funding source.
2. `service client`: Built into service/client that wants wallet functions.
### Permissions
In `funding source client` nostr pubkeys used by `service client` are given and permissions granted (such as `read`/`create_invoice_only`/`pay_invoices`)
### Creating an invoice
`service client` sends `create_invoice` event:
```json
{
"create_invoice":{
"amount":"int",
"memo":"<Optional[str]>",
"description_hash":"<Optional[bytes]>"
}
}
```
`funding source client` checks the pubkey has permission and sends `generated_invoice` event:
```json
{
"generated_invoice":{
"payment_hash":"<string>",
"payment_request":"<string>"
}
}
```
### Paying an invoice
`service client` sends `pay_invoice` event:
```json
{
"pay_invoice":{
"invoice":"<string>",
"note":"<Optional[str]>"
}
}
```
`funding source client` checks the pubkey has permission and attempts to pay the invoice.
### Checking a payment in/out
`service client` sends `check_payment` event:
```json
{
"check_payment":{
"payment_hash":"<string>"
}
}
```
`funding source client` checks the pubkey has permission, checks the payment status and sends `payment_status` event:
```json
{
"payment_status":{
"payment_hash":"<string>",
"paid":"<bool>"
}
}
```