Compare commits

...

10 Commits

Author SHA1 Message Date
fiatjaf
23b069d469 recommend using "k" tag always. 2025-02-26 17:04:45 -03:00
fiatjaf
1b86a40df4 nip25: recommend that reactions do not include a million tags, only the target event. 2025-02-26 07:23:02 -03:00
cypherhoodlum
7cc120ecb0 Optional t tag to git repository announcements (#1798) 2025-02-21 05:57:03 -08:00
AsaiToshiya
93d9a12f16 Update BREAKING.md 2025-02-20 21:11:22 +09:00
AsaiToshiya
0b6b69bcc7 add NIP-56 link to x tag. (#1724) 2025-02-20 00:58:25 +09:00
Vitor Pamplona
58287cd641 Updates NIP-27 to use q tags instead of "mention" markers (#1751) 2025-02-19 09:52:30 -06:00
Vitor Pamplona
0f12cf111f Updates NIP-53 live chat to remove markers and add q tags (#1747) 2025-02-19 10:36:45 -05:00
Vitor Pamplona
619e3bea57 Right to Vanish (#1256)
Co-authored-by: fiatjaf_ <fiatjaf@gmail.com>
Co-authored-by: K <kehiiiiya@gmail.com>
2025-02-18 19:08:36 -08:00
greenart7c3
330de34c7c [NIP-55] Make it clear how to use the package name and what is the purpose of the intents and content resolvers (#1791) 2025-02-17 13:09:37 -05:00
fiatjaf_
8e6f2c06c3 add kind:10002 to nip51 (#1785) 2025-02-14 11:14:43 -03:00
9 changed files with 90 additions and 23 deletions

19
25.md
View File

@@ -25,26 +25,21 @@ consider it a "+".
Tags
----
The reaction event SHOULD include `e` and `p` tags from the note the user is reacting to (and optionally `a` tags if the target is a replaceable event). This allows users to be notified of reactions to posts they were mentioned in. Including the `e` tags enables clients to pull all the reactions associated with individual posts or all the posts in a thread. `a` tags enables clients to seek reactions for all versions of a replaceable event.
There MUST be always an `e` tag set to the `id` of the event that is being reacted to. The `e` tag SHOULD include a relay hint pointing to a relay where the event being reacted to can be found. If a client decides to include other `e`, which not recommended, the target event `id` should be last of the `e` tags.
The last `e` tag MUST be the `id` of the note that is being reacted to.
The SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If a client decides to include other `p` tags, which not recommended, the target event `pubkey` should be last the `p` tags.
The last `p` tag MUST be the `pubkey` of the event being reacted to.
If the event being reacted to is an addressable event, an `a` SHOULD be included together with the `e` tag, it must be set to the coordinates (`kind:pubkey:d-tag`) of the event being reacted to.
The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to.
The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.
The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
Example code
**Example code**
```swift
func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
var tags: [[String]] = liked.tags.filter {
tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p")
}
tags.append(["e", liked.id])
tags.append(["e", liked.id, liked.source_relays.first ?? ""])
tags.append(["p", liked.pubkey])
tags.append(["k", liked.kind])
tags.append(["k", String(liked.kind)])
let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
ev.calculate_id()
ev.sign(privkey: privkey)

2
27.md
View File

@@ -10,7 +10,7 @@ This document standardizes the treatment given by clients of inline references o
When creating an event, clients should include mentions to other profiles and to other events in the middle of the `.content` using [NIP-21](21.md) codes, such as `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg`.
Including [NIP-10](10.md)-style tags (`["e", <hex-id>, <relay-url>, <marker>]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
Including [NIP-18](18.md)'s quote tags (`["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
A reader client that receives an event with such `nostr:...` mentions in its `.content` can do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, [NIP-21](21.md) links or direct links to web clients that will handle these references.

7
34.md
View File

@@ -22,9 +22,10 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
["description", "brief human-readable project description>"],
["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
["r", "<earliest-unique-commit-id>", "euc"]
["maintainers", "<other-recognized-maintainer>", ...]
["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
["r", "<earliest-unique-commit-id>", "euc"],
["maintainers", "<other-recognized-maintainer>", ...],
["t", "<arbitrary string>"], // hashtags labelling the repository
]
}
```

1
51.md
View File

@@ -24,6 +24,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
| --- | --- | --- | --- |
| Mute list | 10000 | things the user doesn't want to see in their feeds | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads) |
| Pinned notes | 10001 | events the user intends to showcase in their profile page | `"e"` (kind:1 notes) |
| Read/write relays | 10002 | where a user publishes to and where they expect mentions | see [NIP-65](65.md) |
| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
| Communities | 10004 | [NIP-72](72.md) communities the user belongs to | `"a"` (kind:34550 community definitions) |
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |

8
53.md
View File

@@ -63,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h
### Live Chat Message
Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used.
Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to.
```jsonc
{
@@ -76,6 +76,12 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
}
```
`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
```json
["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
```
Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.
## Use Cases

7
55.md
View File

@@ -10,7 +10,7 @@ This NIP describes a method for 2-way communication between an Android signer an
# Usage for Android applications
The Android signer uses Intents and Content Resolvers to communicate between applications.
The Android signer uses Intents (to accept/reject permissions manually) and Content Resolvers (to accept/reject permissions automatically in background if the user allowed it) to communicate between applications.
To be able to use the Android signer in your application you should add this to your AndroidManifest.xml:
@@ -66,7 +66,7 @@ Create the Intent using the **nostrsigner** scheme:
val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$content"))
```
Set the Signer package name:
Set the Signer package name after you receive the response from **get_public_key** method:
```kotlin
intent.`package` = "com.example.signer"
@@ -114,7 +114,6 @@ launcher.launch(intent)
```kotlin
val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:"))
intent.`package` = "com.example.signer"
intent.putExtra("type", "get_public_key")
// You can send some default permissions for the user to authorize for ever
val permissions = listOf(
@@ -130,7 +129,7 @@ launcher.launch(intent)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **pubkey** in the result field
- If the user approved the intent it will return the **pubkey** in the result field and the signer packageName in the **package** field
```kotlin
val pubkey = intent.data?.getStringExtra("result")

61
62.md Normal file
View File

@@ -0,0 +1,61 @@
NIP-62
======
Request to Vanish
-----------------
`draft` `optional`
This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database.
## Request to Vanish from Relay
Kind `62` requests a specific relay to delete everything, including [NIP-09](09.md) Deletion Events, from the `.pubkey` until its `.created_at`.
```jsonc
{
"kind": 62,
"pubkey": <32-byte hex-encoded public key of the event creator>,
"tags": [
["relay", "<relay url>"]
],
"content": "<reason or note>",
//...other fields
}
```
The tag list MUST include at least one `relay` value.
Content MAY include a reason or a legal notice to the relay operator.
Relays MUST fully delete any events from the `.pubkey` if their service URL is tagged in the event.
Relays SHOULD delete all [NIP-59](59.md) Gift Wraps that p-tagged the `.pubkey` if their service URL is tagged in the event, deleting all DMs to the pubkey.
Relays MUST ensure the deleted events cannot be re-broadcasted into the relay.
Relays MAY store the signed request to vanish for bookkeeping.
Paid relays or relays that restrict who can post MUST also follow the request to vanish regardless of the user's status.
Publishing a deletion request event (Kind `5`) against a request to vanish has no effect. Clients and relays are not obliged to support "unrequest vanish" functionality.
Clients SHOULD send this event to the target relays only.
## Global Request to Vanish
To request ALL relays to delete everything, the event MUST include a `relay` tag with the value `ALL_RELAYS` in uppercase.
```jsonc
{
"kind": 62,
"pubkey": <32-byte hex-encoded public key of the event creator>,
"tags": [
["relay", "ALL_RELAYS"]
],
"content": "<reason>",
//...other fields
}
```
Clients SHOULD broadcast this event to as many relays as possible.

View File

@@ -5,6 +5,8 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2025-02-14 | [81908b6e](https://github.com/nostr-protocol/nips/commit/81908b6e) | [07](07.md), [46](46.md), [55](55.md) | `getRelays` and `get_relays` were removed |
| 2025-02-07 | [0023ca81](https://github.com/nostr-protocol/nips/commit/0023ca81) | [10](10.md) | `"mention"` marker was removed |
| 2025-01-31 | [6a4b125a](https://github.com/nostr-protocol/nips/commit/6a4b125a) | [71](71.md) | video events were changed to regular |
| 2024-12-05 | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
| 2024-11-12 | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |

View File

@@ -77,6 +77,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-59: Gift Wrap](59.md)
- [NIP-60: Cashu Wallet](60.md)
- [NIP-61: Nutzaps](61.md)
- [NIP-62: Request to Vanish](62.md)
- [NIP-64: Chess (PGN)](64.md)
- [NIP-65: Relay List Metadata](65.md)
- [NIP-68: Picture-first feeds](68.md)
@@ -130,6 +131,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `42` | Channel Message | [28](28.md) |
| `43` | Channel Hide Message | [28](28.md) |
| `44` | Channel Mute User | [28](28.md) |
| `62` | Request to Vanish | [62](62.md) |
| `64` | Chess (PGN) | [64](64.md) |
| `818` | Merge Requests | [54](54.md) |
| `1018` | Poll Response | [88](88.md) |
@@ -169,7 +171,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `9802` | Highlights | [84](84.md) |
| `10000` | Mute list | [51](51.md) |
| `10001` | Pin list | [51](51.md) |
| `10002` | Relay List Metadata | [65](65.md) |
| `10002` | Relay List Metadata | [65](65.md), [51](51.md) |
| `10003` | Bookmark list | [51](51.md) |
| `10004` | Communities list | [51](51.md) |
| `10005` | Public chats list | [51](51.md) |
@@ -299,7 +301,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `s` | status | -- | [69](69.md) |
| `t` | hashtag | -- | [24](24.md), [34](34.md), [35](35.md) |
| `u` | url | -- | [61](61.md), [98](98.md) |
| `x` | infohash | -- | [35](35.md) |
| `x` | hash | -- | [35](35.md), [56](56.md) |
| `y` | platform | -- | [69](69.md) |
| `z` | order number | -- | [69](69.md) |
| `-` | -- | -- | [70](70.md) |