mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-15 03:18:51 +00:00
Compare commits
3 Commits
djot
...
d54c426709
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
d54c426709 | ||
|
|
179e421011 | ||
|
|
74681c3c14 |
22
45.md
22
45.md
@@ -14,17 +14,17 @@ Some queries a client may want to execute against connected relays are prohibiti
|
|||||||
|
|
||||||
## Filters and return values
|
## Filters and return values
|
||||||
|
|
||||||
This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
|
This NIP defines the verb `COUNT`, which accepts a query id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
|
||||||
|
|
||||||
```
|
```
|
||||||
["COUNT", <subscription_id>, <filters JSON>...]
|
["COUNT", <query_id>, <filters JSON>...]
|
||||||
```
|
```
|
||||||
|
|
||||||
Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
|
Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
|
||||||
In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
|
In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
|
||||||
|
|
||||||
```
|
```
|
||||||
["COUNT", <subscription_id>, {"count": <integer>}]
|
["COUNT", <query_id>, {"count": <integer>}]
|
||||||
```
|
```
|
||||||
|
|
||||||
Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
|
Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
|
||||||
@@ -34,27 +34,27 @@ Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST ret
|
|||||||
### Followers count
|
### Followers count
|
||||||
|
|
||||||
```
|
```
|
||||||
["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
|
["COUNT", <query_id>, {"kinds": [3], "#p": [<pubkey>]}]
|
||||||
["COUNT", <subscription_id>, {"count": 238}]
|
["COUNT", <query_id>, {"count": 238}]
|
||||||
```
|
```
|
||||||
|
|
||||||
### Count posts and reactions
|
### Count posts and reactions
|
||||||
|
|
||||||
```
|
```
|
||||||
["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
|
["COUNT", <query_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
|
||||||
["COUNT", <subscription_id>, {"count": 5}]
|
["COUNT", <query_id>, {"count": 5}]
|
||||||
```
|
```
|
||||||
|
|
||||||
### Count posts approximately
|
### Count posts approximately
|
||||||
|
|
||||||
```
|
```
|
||||||
["COUNT", <subscription_id>, {"kinds": [1]}]
|
["COUNT", <query_id>, {"kinds": [1]}]
|
||||||
["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
|
["COUNT", <query_id>, {"count": 93412452, "approximate": true}]
|
||||||
```
|
```
|
||||||
|
|
||||||
### Relay refuses to count
|
### Relay refuses to count
|
||||||
|
|
||||||
```
|
```
|
||||||
["COUNT", <subscription_id>, {"kinds": [4], "authors": [<pubkey>], "#p": [<pubkey>]}]
|
["COUNT", <query_id>, {"kinds": [1059], "#p": [<pubkey>]}]
|
||||||
["CLOSED", <subscription_id>, "auth-required: cannot count other people's DMs"]
|
["CLOSED", <query_id>, "auth-required: cannot count other people's DMs"]
|
||||||
```
|
```
|
||||||
|
|||||||
4
55.md
4
55.md
@@ -295,6 +295,8 @@ For the other types Signer Application returns the column "result"
|
|||||||
|
|
||||||
If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application
|
If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application
|
||||||
|
|
||||||
|
Clients SHOULD save the user pubkey locally and avoid calling the `get_public_key` after the user is logged in to the Client
|
||||||
|
|
||||||
#### Methods
|
#### Methods
|
||||||
|
|
||||||
- **get_public_key**
|
- **get_public_key**
|
||||||
@@ -303,7 +305,7 @@ If the user chose to always reject the event, signer application will return the
|
|||||||
```kotlin
|
```kotlin
|
||||||
val result = context.contentResolver.query(
|
val result = context.contentResolver.query(
|
||||||
Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
|
Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
|
||||||
listOf("login"),
|
listOf(hex_pub_key),
|
||||||
null,
|
null,
|
||||||
null,
|
null,
|
||||||
null
|
null
|
||||||
|
|||||||
Reference in New Issue
Block a user