Compare commits

..

18 Commits

Author SHA1 Message Date
fiatjaf
ae825539c6 unfollowing is just deleting the follow event.
@vitorpamplona: https://github.com/nostr-protocol/nips/pull/1135#issuecomment-2016546516
2024-03-23 15:51:35 -03:00
fiatjaf
b2d6af6fe5 nip-64: inbox model. 2024-03-23 10:31:34 -03:00
Alex Gleason
9e9ae1eb88 Merge pull request #1113 from nostr-wine/nip50-extensions
NIP-50: add event classification extensions
2024-03-11 00:28:08 -05:00
nostr.wine
0438236268 Update 50.md 2024-03-08 12:05:49 -05:00
nostr.wine
d11f50bd0a NIP-50: add event classification extensions 2024-03-08 11:23:22 -05:00
Alex Gleason
c4c9bd0057 Merge pull request #1105 from nostr-protocol/alexgleason-patch-1
NIP-50: search by nip05 domain
2024-03-08 05:28:49 -06:00
Asai Toshiya
6871b3b334 README: add kinds and tags for NIP-34 2024-03-07 07:34:04 -03:00
Alex Gleason
1166fb9fb5 NIP-50: search by nip05 domain 2024-03-06 13:59:36 -06:00
Asai Toshiya
808569e562 README: add NIP-34 2024-03-06 12:35:59 +09:00
fiatjaf_
9a283796ce NIP-34: git stuff (#997)
* NIP-34: git stuff.

* repository head.

* threads/issues and replies.

* add "p" optional tags to events.

* add list of things to do later in the end.

* multiple values in some tags instead of multiple tags.

* replace "patches", "issues" tags and replace that with "relays".

* bring in tags that allow for a commit id to be stable.

* edit "reply" kind to say it should follow normal NIP-10 threading rules.

* update "things to be added later".

* add commit time to "committer" tag.

* remove "head" tag.

* mention the possibility of mentioning others users in patches.

Co-authored-by: DanConwayDev <114834599+DanConwayDev@users.noreply.github.com>

* clarify commit-pgp-sig.

* clarify requirements and threading of replies.

* add t=root tag.

---------

Co-authored-by: DanConwayDev <114834599+DanConwayDev@users.noreply.github.com>
2024-03-05 08:57:59 -03:00
Alex Gleason
849f59f6ba Merge pull request #1100 from AsaiToshiya/AsaiToshiya-patch-3
BREAKING.md: add NIP-18 change
2024-03-04 20:43:18 -05:00
Asai Toshiya
ac1221fa5d BREAKING.md: add NIP-18 change 2024-03-05 10:34:01 +09:00
fiatjaf_
5b2461eb01 NIP-29: Simple Groups (#566)
* NIP-29: Simple Group Chat.

* split hostname and subgroup path into two different tag items.

* add and remove permissions actions.

* fix kind number for moderation event.

* add missing / to "flavors" in example.

* some new ideas + making this universal and not only applicable to chat.

* fix delete-message => delete-event.

* flesh out the entire thing.

* saner approach with multiple kinds for moderation.

* delete-event as kind 9005.

* update meta events description.

* `public` and `open` tags and join request event.

* edit-group-status permission.

* add kinds to README.

* add kind:12

* add nip-10 note

* add optional list of members

* admins prefixed by "p".

* remove "alt" from event templates for brevity.

* add kind 10009 for public list of simple groups.

* update "previous" stuff.

* remove naddr stuff, use a different identifier format.

* remove reference to trimmed signatures until that is more developed.

* add kind:10 threaded chat replies.

---------

Co-authored-by: Pablo Fernandez <p@f7z.io>
2024-02-28 11:50:54 -03:00
Alex Gleason
f3a2356484 Merge pull request #1086 from AsaiToshiya/AsaiToshiya-patch-2
README: add q tag
2024-02-25 21:39:10 -06:00
Asai Toshiya
c9b3abfa3c Remove marker
Co-authored-by: Alex Gleason <alex@alexgleason.me>
2024-02-26 12:30:49 +09:00
Asai Toshiya
383eb594b4 README: add q tag 2024-02-26 10:07:55 +09:00
Alex Gleason
4a171cb0a8 Merge pull request #1074 from jb55/quote-repost-q-tags
Use `q` instead of `e` tags for quote reposts
2024-02-25 08:09:09 -06:00
William Casarin
996ef45605 Use q instead of e tags for quote reposts
Signed-off-by: William Casarin <jb55@jb55.com>
2024-02-22 11:40:58 -08:00
6 changed files with 176 additions and 5 deletions

7
18.md
View File

@@ -20,9 +20,10 @@ reposted.
## Quote Reposts
Quote reposts are `kind 1` events with an embedded `e` tag
(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes
an `e` tag, it may show up along replies to the reposted note.
Quote reposts are `kind 1` events with an embedded `q` tag of the note being
quote reposted. The `q` tag ensures quote reposts are not pulled and included
as replies in threads. It also allows you to easily pull and count all of the
quotes for a post.
## Generic Reposts

102
34.md Normal file
View File

@@ -0,0 +1,102 @@
NIP-34
======
`git` stuff
-----------
`draft` `optional`
This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr.
## Repository announcements
Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.
```jsonc
{
"kind": 30617,
"content": "",
"tags": [
["d", "<repo-id>"],
["name", "<human-readable project name>"],
["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
]
}
```
The tags `web`, `clone`, `relays` can have multiple values.
Except `d`, all tags are optional.
## Patches
Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
```jsonc
{
"kind": 1617,
"content": "<patch>", // contents of <git format-patch>
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
["p", "<repository-owner>"],
["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
// for the first patch in a thread or series
["t", "root"],
// optional tags for when it is desirable that the merged patch has a stable commit id
// these fields are necessary for ensuring that the commit resulting from applying a patch
// has the same id as it had in the proposer's machine -- all these tags can be omitted
// if the maintainer doesn't care about these things
["commit", "<current-commit-id>"],
["parent-commit", "<parent-commit-id>"],
["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
]
}
```
## Issues
Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
```jsonc
{
"kind": 1621,
"content": "<markdown text>",
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
["p", "<repository-owner>"]
]
}
```
## Replies
Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
```jsonc
{
"kind": 1622,
"content": "<markdown text>",
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
["e", "<issue-or-patch-id-hex>", "", "root"],
// other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
["p", "<patch-author-pubkey-hex>", "", "mention"],
["e", "<previous-reply-id-hex>", "", "reply"],
// ...
]
}
```
## Possible things to be added later
- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
- "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
- inline file comments kind (we probably need one for patches and a different one for merged files)

4
50.md
View File

@@ -47,3 +47,7 @@ Relays SHOULD exclude spam from search results by default if they support some f
Relay MAY support these extensions:
- `include:spam` - turn off spam filtering, if it was enabled by default
- `domain:<domain>` - include only events from users whose valid nip05 domain matches the domain
- `language:<two letter ISO 639-1 language code>` - include only events of a specified language
- `sentiment:<negative/neutral/positive>` - include only events of a specific sentiment
- `nsfw:<true/false>` - include or exclude nsfw events (default: true)

55
64.md Normal file
View File

@@ -0,0 +1,55 @@
NIP-64
======
Inbox model
-----------
`draft` `optional`
Suppose **Sarah** wants to subscribe to the notes **Walter** writes.
She must let Walter know she is following him. The first step is to find Walter's _inbox list_:
```jsonc
{
"kind": 10064,
"pubkey": "<walter>",
"tags": [
["relay", "wss://walter.inbox"]
]
}
```
Now Sarah can publish a `kind:6401` _follow intent_ to `wss://walter.inbox` tagging Walter:
```jsonc
{
"kind": 6401,
"pubkey": "<sarah>"
"tags": [
["p", "<walter>"],
["relay", "wss://sarah.inbox"],
["relay", "wss://other.inbox"]
]
}
```
Sarah also publishes these to her own inbox relays (`wss://sarah.inbox` and `wss://other.inbox`) so they are aware.
From the Walter side, whenever he is about to publish a note, he downloads all the `kind:6401` events from his inbox relays and sends his note to all the relays he finds in these.
Whenever Sarah's inbox relay receive a note from Walter, they will know that Sarah is following him, so they index that note in a way that it is associated with Sarah. If the relays receive a note from someone else they can simply reject the note.
When Sarah turns on her client she will connect to her inbox relay, perform [NIP-42](42.md) `AUTH` and create a subscription that doesn't specify `"authors"` (for example, `["REQ", "_", {}]`). The relays, aware of who she is and who she is following, can deliver to her just Walter's notes.
If Sarah ever decides to stop following Walter, she just sends a `kind:5` _deletion_ to both Walter's relay and hers.
---
The approach described in this NIP doesn't replace any of the other models for following people that are already in use in Nostr, and doesn't claim to be strictly superior to the Outbox Model, but just provides an alternative way to do things.
In reality, clients should implement both approaches and can never assume others will implement this.
For example, if Sarah wanted to follow Wesley and he didn't have a `kind:10064` she would have to do the normal "outbox" approach of subscribing to his relays and fetching his notes from there.
In the same vein, if for any reason Sarah noticed that she had stopped receiving notes from Walter for a long time (~7 days) it would make sense for her to go to his relays (obtained from [NIP-65](65.md), [NIP-05](05.md), relay hints or other means) and check if he is publishing to these. In the affirmative case, she would turn Walter into an "outbox follow" instead of an "inbox follow".

View File

@@ -5,6 +5,7 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2024-02-25 | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag |
| 2024-02-16 | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [NIP-49](49.md) | Password first normalized to NFKC |
| 2024-02-15 | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [NIP-39](39.md) | PGP identity was removed |
| 2024-02-07 | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [NIP-46](46.md) | Connection token format was changed |

View File

@@ -49,6 +49,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-30: Custom Emoji](30.md)
- [NIP-31: Dealing with Unknown Events](31.md)
- [NIP-32: Labeling](32.md)
- [NIP-34: `git` stuff](34.md)
- [NIP-36: Sensitive Content](36.md)
- [NIP-38: User Statuses](38.md)
- [NIP-39: External Identities in Profiles](39.md)
@@ -110,6 +111,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1059` | Gift Wrap | [59](59.md) |
| `1063` | File Metadata | [94](94.md) |
| `1311` | Live Chat Message | [53](53.md) |
| `1617` | Patches | [34](34.md) |
| `1621` | Issues | [34](34.md) |
| `1622` | Replies | [34](34.md) |
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
| `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) |
@@ -162,6 +166,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30315` | User Statuses | [38](38.md) |
| `30402` | Classified Listing | [99](99.md) |
| `30403` | Draft Classified Listing | [99](99.md) |
| `30617` | Repository announcements | [34](34.md) |
| `31922` | Date-Based Calendar Event | [52](52.md) |
| `31923` | Time-Based Calendar Event | [52](52.md) |
| `31924` | Calendar | [52](52.md) |
@@ -214,6 +219,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `l` | label, label namespace | annotations | [32](32.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `q` | event id (hex) | relay URL | [18](18.md) |
| `r` | a reference (URL, etc) | petname | |
| `r` | relay url | marker | [65](65.md) |
| `t` | hashtag | -- | |
@@ -222,9 +228,10 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `challenge` | challenge string | -- | [42](42.md) |
| `client` | name, address | relay URL | [89](89.md) |
| `clone` | git clone URL | -- | [34](34.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `description` | invoice/badge description | -- | [57](57.md), [58](58.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
@@ -233,7 +240,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `imeta` | inline metadata | -- | [92](92.md) |
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
| `location` | location string | -- | [52](52.md), [99](99.md) |
| `name` | badge name | -- | [58](58.md) |
| `name` | name | -- | [34](34.md), [58](58.md) |
| `nonce` | random | -- | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |
@@ -246,6 +253,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `summary` | article summary | -- | [23](23.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | article title | -- | [23](23.md) |
| `web` | webpage URL | -- | [34](34.md) |
| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
## Criteria for acceptance of NIPs