Compare commits

...

29 Commits

Author SHA1 Message Date
Arc
e2a1632290
Merge 4fa5b4f997 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
Arc
4fa5b4f997
Update 88.md
Co-authored-by: arthurfranca <arthur.a.franca@gmail.com>
2023-06-30 12:18:56 +01:00
Arc
fa086e0c6a
Update 88.md 2023-06-29 15:03:36 +01:00
Arc
8bb004db59
Update 88.md 2023-06-29 14:58:28 +01:00
Arc
131b1cca4f
Update 88.md 2023-06-29 14:58:08 +01:00
Arc
d3a2cddbc6
Update 88.md 2023-06-29 14:55:01 +01:00
Arc
b57abac1d5
Update 88.md 2023-06-29 14:54:28 +01:00
Arc
29a8368678
Update 88.md 2023-06-29 14:13:56 +01:00
Ben
feba8cf6a1 removed ecash mention, its not ecash 2023-06-29 14:11:13 +01:00
Ben
2198147d2b disclaimer elaborated on 2023-06-29 13:59:52 +01:00
Ben
10407208a6 added ecash disclaimer 2023-06-29 13:56:29 +01:00
Ben
56dcdb3075 Merge remote-tracking branch 'arcbtc/nostrcash' into nostrcash 2023-06-29 12:16:28 +01:00
Ben
3cf4a54aad format 2023-06-29 12:14:54 +01:00
Ben
cf71afb42d added nostr cash
Update 88.md
Update 88.md
Update 88.md
Update 88.md
typo


typos


typo


adding descriptions for workflows


Expanded explanation 


added explanation
2023-06-29 12:14:01 +01:00
Ben
933674fea0 added explanation 2023-06-29 12:13:44 +01:00
Ben
b0526aec4d Expanded explanation 2023-06-29 12:11:06 +01:00
Ben
d3b5da312d adding descriptions for workflows 2023-06-29 12:08:28 +01:00
Ben
aef4ad0e53 typo 2023-06-29 11:59:25 +01:00
Ben
bd584464c0 typos 2023-06-29 11:58:37 +01:00
Ben
6c273e42bf typo 2023-06-29 11:57:14 +01:00
Arc
72d686ff3a
Update 88.md 2023-06-29 11:53:47 +01:00
Arc
c831ee252f
Update 88.md 2023-06-29 11:53:36 +01:00
Arc
a0bf41e860
Update 88.md 2023-06-29 11:53:08 +01:00
Arc
88c52fc45c
Update 88.md 2023-06-29 11:51:14 +01:00
Ben
4cf6ea7137 added nostr cash 2023-06-29 11:40:25 +01:00
Ben
57e9e8d92f Merge branch 'master' into mymaster 2023-06-29 10:20:38 +01:00
Arc
d82b733182
Merge pull request #3 from arcbtc/nips121
WIP: Unicast event
2023-06-09 12:22:20 +01:00
ben
3815a6fd09 init 2023-06-09 12:20:18 +01:00
4 changed files with 219 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)) |

197
88.md Normal file
View File

@ -0,0 +1,197 @@
NIP-88
======
Nostr Cash (simple Nostr cash/token/cheque)
-----------------------------------
`draft` `optional` `author:benarc`
Electronic cash is useful and relays should have the option to offer minting/custodial services. Other mints could exist as stand-alone clients, but relays are ideally placed to package in with their service offerings.
Nostr Cash is simple and flexible. User gives a mint some money and the mint issues the user electromic cash/cheque/token that can be used as money in nostr.
Nostr Cash is entirely custodial and trust based, and is just a common standard for users to send/receive value in nostr. Keeping mints simple means more users can run, for themselves, their family, or the whole world.
Relays offering mints must have a keypair and an additional nostr keypair for its mint.
Nostr Cash uses derived keys, much like [NIP06](https://github.com/nostr-protocol/nips/blob/master/06.md). Each "cash" is actually just a derived private key that can be burned or passed to another user.
All communication between the relay and user happen over [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md).
The mints ledger is two tables `active` and `spent`:
```
active:
key: <integer, keypair deriviation number from master>,
amount: <integer BTC millisat denomination>,
user: <string, public-key of user>,
timestamp: <integer timestamp>
spent:
key: <integer, keypair deriviation number from master>,
amount: <integer BTC millisat denomination>,
user: <string, public-key of user>,
timestamp: <integer timestamp>
```
User client cash wallet stores:
```
active:
key: <string, derived private key/cash>,
amount: <integer BTC millisat denomination>,
relay: <string, relay ws address>,
relaykey: <string, public-key of relay>,
timestamp: <integer timestamp>
spent:
key: <string, derived private key/cash>,
amount: <integer BTC millisat denomination>,
relay: <string, relay ws address>,
relaykey: <string, public-key of relay>,
timestamp: <integer timestamp>
```
## Workflows
### Mint details
**For fetching info about the mint.**
User DMs the relay:
```json
{
"mint": <bool true>
}
```
Relay DMs user (maybe after a check if the relays mint has restricted access):
```json
{
"title": <string mints title>,
"description": <string mints description>,
"liquiity": <integer optional public millisat balance of mint>,
"type": <list different offered payment types bolt11 bolt12 onchain stripe paypal shitcoin etc>,
"fee": <integer millisat fee for internal nostr payments>,
}
```
### Minting
**For creating new cash from a mint.**
User DMs the relay:
```json
{
"amount": <integer millisats>
}
```
Relay responds with payment request, which user pays:
```json
{
"request": <string payment request bolt11 bolt12 onchain stripe paypal shitcoin etc>
}
```
Once paid the mint generates derived keypair from the mints private key, storing in table `active`:
```json
{
"key": <integer derived keypair number>,
"amount": <integer BTC millisat denomination>,
"user": <string public-key of user>
}
```
Mint replies to user:
```json
{
"key": <string derived private key/cash>,
"amount": <integer BTC millisat denomination>
}
```
User client stores:
```json
{
"key": <string derived private key/cash>,
"amount": <integer BTC millisat denomination>,
"relay": <string relay ws address>,
"relaykey": <string public-key of relay>,
"timestamp": <integer timestamp>
}
```
### Claiming
**For cashing in cash with the mint.**
User DMs relay:
```json
{
"key": <String, derived private key/cash>,
"amount": <Integer, BTC millisat denomination>,
"type": <String, preffered payment method bolt11 bolt12 onchain stripe paypal shitcoin etc>
}
```
Relay DMs user:
```json
{
"type": <String, bolt11 bolt12 onchain stripe paypal shitcoin etc>
}
```
User DMs relay:
```json
{
"request": <String, payment-request bolt11 bolt12 onchain stripe paypal shitcoin etc>,
}
```
### Sending
**For sending cash to another nostr user.**
User DMs relay:
```json
{
"key": <String, derived private key/cash>,
"amount": <Integer, BTC millisat denomination>,
"type": <String, public key of recipient>
}
```
Mint `burns` the old record for the cash and creates a new record(s), depending on if sending user is owed change (the old record moves from `active` to `spent` table). The mint creates a new record in `active` and DMs the recipient user the private-key/cash. If change is due, another record is created in `active` and sent back to the sender user.
Relay DMs user(s):
```json
{
"key": <string derived private key/cash>,
"amount": <integer BTC millisat denomination>
}
```
User(s) client stores:
```json
{
"key": <string derived private key/cash>,
"amount": <integer BTC millisat denomination>,
"relay": <string, relay ws address>,
"relaykey": <string public-key of relay>,
"timestamp": <integer timestamp>
}
```

19
NIP-121.md Normal file
View File

@ -0,0 +1,19 @@
NIP-121
======
Unicast event `"tags": "r"`
-------------------------------
`draft` `mandatory` `author:benarc`
`route` list of relays as a new tag `"r"`, to help create a unicast route for an events.
```json
{
"tags": [
["r", "<csv of relay IDs>"]
]
}
```
A client receives an event with tag `"r"`, if the client received the event from a relay in the list and it has a connection with the next relay in the list, the client will pass the event to that relay.