For you and others following. Common in early nostr apps. The web-extension spec is defined in https://github.com/nostr-protocol/nips/blob/master/07.md. Most apps check for window.nostr, then fail silently when it's missing or blocked. There are also some popular extensions in that list.
In Flare, a video sharing site built on Nostrnostr-protocol
nips
Communication & Social2022–2026
nostr-protocol / nips
nips
Nostr Implementation Possibilities
44Distinct people
61Mentions
0Explicit recommenders
3.1KGitHub stars
What to know before exploring
What it is
Nostr Implementation Possibilities
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- aljazceru/awesome-nostr · linked in 2 of the same discussions
- nostr-protocol/nostr · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year61 dated mentions
Observed mentions: 2022-11-25 20:22:21 UTC to 2026-10-17 16:09:57 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 33 | 2 | 31 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 1 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
NIPs
NIPs stand for Nostr Implementation Possibilities.
They exist to document what may be implemented by Nostr-compatible relay and client software.
NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP. Each app picks the subset relevant to its use case. Don't implement something just because it exists in this repo. Other standards and NIPs may exist outside this repository (e.g. as pull requests) and may already be deployed in the wild -- they should also be considered for implementation.
List
Event Kinds
Message Types
Client to Relay
Relay to Client
Criteria for acceptance of NIPs
Is this repository a centralizing factor?
How this repository works
License
List
NIP-01: Basic protocol flow description
NIP-02: Follow List
NIP-03: OpenTimestamps Attestations for Events --- unrecommended: vulnerable to one specific attack, needs update
NIP-04: Encrypted Direct Message --- unrecommended: deprecated in favor of NIP-17
NIP-05: Mapping Nostr keys to DNS-based internet identifiers
NIP-06: Basic key derivation from mnemonic seed phrase --- unrecommended: prefer a single nsec
NIP-07: window.nostr capability for web browsers
NIP-08: Handling Mentions --- unrecommended: deprecated in favor of NIP-27
NIP-09: Event Deletion Request
NIP-10: Text Notes and Threads
NIP-11: Relay Information Document
NIP-13: Proof of Work
NIP-14: Subject tag in text events
NIP-15: Nostr Marketplace (for resilient marketplaces) --- unrecommended: too complicated, try 99 instead
NIP-17: Private Direct Messages
NIP-18: Reposts
NIP-19: bech32-encoded entities
NIP-21: nostr: URI scheme
NIP-22: Comment
NIP-23: Long-form Content
NIP-24: Extra metadata fields and tags
NIP-25: Reactions
NIP-26: Delegated Event Signing --- unrecommended: adds unnecessary burden for little gain
NIP-27: Text Note References
NIP-28: Public Chat --- unrecommended: try NIP-29 instead
NIP-29: Relay-based Groups
NIP-30: Custom Emoji
NIP-31: Dealing with Unknown Events --- unrecommended: unnecessarily bloated
NIP-32: Labeling
NIP-34: git stuff
NIP-35: Torrents
NIP-36: Sensitive Content
NIP-37: Draft Events
NIP-38: User Statuses
NIP-39: Linking Profiles to Other Platforms
NIP-40: Expiration Timestamp
NIP-42: Authentication of clients to relays
NIP-43: Relay Access Metadata and Requests
NIP-44: Encrypted Payloads (Versioned)
NIP-45: Counting results
NIP-46: Nostr Remote Signing
NIP-47: Nostr Wallet Connect
NIP-48: Bridged Events
NIP-49: Private Key Encryption (ncryptsec)
NIP-50: Search Capability
NIP-51: Lists
NIP-52: Calendar Events
NIP-53: Live Streaming and Spaces
NIP-54: Wiki
NIP-55: Android Signer Application
NIP-56: Reporting
NIP-57: Lightning Zaps
NIP-58: Badges
NIP-59: Gift Wrap
NIP-5A: Static Websites (nsites)
NIP-60: Cashu Wallet
NIP-61: Nutzaps
NIP-62: Request to Vanish
NIP-64: Chess (PGN)
NIP-65: Relay List Metadata
NIP-66: Relay Discovery and Liveness Monitoring
NIP-67: EOSE Completeness Hint
NIP-68: Picture-first feeds
NIP-69: Peer-to-peer Order events
NIP-70: Protected Events
NIP-71: Video Events
NIP-72: Moderated Communities --- unrecommended: try NIP-29 instead
NIP-73: External Content IDs
NIP-75: Zap Goals
NIP-77: Negentropy Syncing
NIP-78: Application-specific data
NIP-7D: Forum Threads
NIP-84: Highlights
NIP-85: Trusted Assertions
NIP-86: Relay Management API
NIP-87: Cashu and Fedimint Discoverability
NIP-88: Polls
NIP-89: Recommended Application Handlers
NIP-90: Data Vending Machines --- unrecommended: this got totally out of control, prefer use-case-specific microstandards
NIP-92: Media Attachments Metadata (imeta)
NIP-94: File Metadata
NIP-96: HTTP File Storage Integration --- unrecommended: replaced by Blossom
NIP-98: HTTP Auth
NIP-99: Classified Listings
NIP-A0: Voice Messages
NIP-A3: payto: Payment Targets
NIP-A4: Public Messages
NIP-B0: Web Bookmarks
NIP-B7: Blossom
NIP-BE: Nostr BLE Communications Protocol --- unrecommended: only implemented once and unclear whether it works, requires review
NIP-C0: Code Snippets
NIP-C7: Chats
NIP-CC: Geocaching
NIP-CD: Slash Commands
NIP-EE: E2EE Messaging using MLS Protocol --- unrecommended: superseded by the Marmot Protocol
NIP-F4: Podcasts
Event Kinds
This table is not exhaustive. For a machine-readable registry of all known event kinds prefer https://github.com/nostr-protocol/registry-of-kinds (or alternative registries following the same YAML schema).
kind
description
NIP
0
User Metadata
01
1
Short Text Note
10
3
Follows
02
4
Encrypted Direct Messages
04
5
Event Deletion Request
09
6
Repost
18
7
Reaction
25
8
Badge Award
58
9
Chat Message
C7
11
Thread
7D
13
Seal
59
14
Direct Message
17
15
File Message
17
16
Generic Repost
18
17
Reaction to a website
25
20
Picture
68
21
Video Event
71
22
Short-form Portrait Video Event
71
24
Public Message
A4
30
internal reference
NKBIP-03
31
external web reference
NKBIP-03
32
hardcopy reference
NKBIP-03
33
prompt reference
NKBIP-03
40
Channel Creation
28
41
Channel Metadata
28
42
Channel Message
28
43
Channel Hide Message
28
44
Channel Mute User
28
54
Podcast Episode
F4
62
Request to Vanish
62
64
Chess (PGN)
64
78
Application-specific Data
78
443
KeyPackage
Marmot
444
Welcome Message
Marmot
445
Group Event
Marmot
818
Merge Requests
54
1018
Poll Response
88
1021
Bid
15
1022
Bid confirmation
15
1234
Draft Checkpoint
37
1040
OpenTimestamps
03
1059
Gift Wrap
59
1063
File Metadata
94
1068
Poll
88
1111
Comment
22
1222
Voice Message
A0
1244
Voice Message Comment
A0
1311
Live Chat Message
53
1337
Code Snippet
C0
1617
Patches
34
1618
Pull Requests
34
1619
Pull Request Updates
34
1621
Issues
34
1622
Git Replies (deprecated)
34
1630-1633
Status
34
1971
Problem Tracker
nostrocket
1984
Reporting
56
1985
Label
32
1987
AI Embeddings / Vector lists
NKBIP-02
2003
Torrent
35
2004
Torrent Comment
35
2022
Coinjoin Pool
joinstr
4550
Community Post Approval
72
7374
Reserved Cashu Wallet Tokens
60
Read the full README on GitHubWhat Hacker News says
33 sourcesI am glad Zach posted here also, I think nostr devs need some reality pull from "non-crypto normies". To be clear it is (hopefully) becoming more common practice to use a nip-07 web-extension for signing (hardware or software) or other methods such as NIP-46. To be clear though, a user on nostr will HAVE to interact with cryptography in some way as every message on the network is signed.
Im working on https://github.com/VnUgE/NVault as an option for more paranoid users that want a self hosted networked approach. But there are others listed here https://github.com/nostr-protocol/nips/blob/master/07.md
Finally, I wholly dislike the practice of offering an option of entering an nsec. Use a signing extension!
In Flare, a video sharing site built on Nostr> IIUC, you have to know which relay(s) have what you're looking for, and if you don't, you just have to guess.
This problem is tackled by an improvement to the protocol that was recently introduced called "NIP-65":
https://github.com/nostr-protocol/nips/blob/master/65.md
The TLDR is that when a Nostr client supports NIP-65, it broadcasts to all known relays (which is continually updated/expanded) the list of relays that User A posts their stuff to.
This means that as long as User B is connected to at least one of those "all known relays", their client now knows what relays User A posts their stuff to, and will specifically fetch things from those relays when it needs to load User A's things.
It's essentially the Nostr take on the Gossip protocol: https://en.wikipedia.org/wiki/Gossip_protocol
In RSS can be used to distribute all sorts of informationI am a huge fan of RSS (Atom) and was really hoping for a comeback... I feel like it unfairly died out because of Google Reader's sudden demise and was hoping some new equally popular client to show up and take over. I even spent some time creating one.
But for the past year or so I have been falling down the Nostr rabbit hole. Nostr is a lot like RSS, but it really is better and without getting much more complicated! You can write a Nostr client that simply does what a RSS reader would do (fetch status updates) in a couple of lines without external libraries. And the Nostr ecosystem has been growing so much over the past months, it is getting hard to keep up! It seems to be really getting the momentum I was hoping RSS to regain.
PS: For those that are curious about Nostr and don't know where to start, have a look at the NIPS [1] and of c
Read the rest
ourse at the awesome-nostr [2] list on GitHub!
[1]: https://github.com/nostr-protocol/nips
[2]: https://github.com/aljazceru/awesome-nostr
I think your best bet here is Nostr (Notes and Other Stuff Transmitted by Relays): https://nostr.com https://github.com/nostr-protocol/nostr
Nostr isn't a federated platform like Mastodon or Lemmy, it's more similar to the AT protocol created by Bluesky, whilst being far simpler to understand and write apps using it. The nostr protocol is defined by a series of NIPs (Nostr implementation possibilites https://github.com/nostr-protocol/nips), the most basic of which can be implemented in a client or a relay in 50-100 lines of code in any modern programming language.
Each user runs a client, anyone can write a relay or run any of hundreds of existing implementations, both clients and relays can choose to support a number of NIPs. Users have a public-private keypair, and distribute notes to relays signed with their private key, which are veri
Read the rest
fied by relays. Clients subscribe via websockets to any number of relays (I usually have 20-30), and receive notes from all users on those relays' databases, or filtered by the public keys of the users you're following. Relays for the most part don't communicate with each other. If you're ever blocked or banned from a relay, you'll still be able to have your notes seen as long as you have at least one relay in common with anyone who wants to see them. I run my own as well for extra resiliency.
At the moment there's ~50 standardised NIPs, which add features like likes, zaps (bitcoin tips for notes), user status, post expiration, mentions, search, DMs, and public chats. Nearly all of these are supported by popular clients and relays. While nostr is primarily used for social media at the moment, it's already possible to build upon as a protocol for pretty much any online service.
The total active user count on most public relays I'd estimate is somewhere around 500k to a million, though the nature of the protocol makes it impossible to estimate its true size. The perceived community on most relays before following anyone frankly can get pretty cancerous, mainly due to a lot of clients sorting notes by new by default, so I can only hope to high heaven it'll improve as it grows.
Though like any new non-centralised platform, it's more difficult to get started on for most non-technical users as they have to pick one of hundreds of clients to install, and requires caution to never leak your private key and be very wary of which clients you trust it with.
There is no "zaps balance". Zaps are just receipts of lightning payments.
The basic idea is that a lightning node will detect when the invoice with a nostr note inside is paid, and then send the receipt to nostr as a nostr note, with the original bolt11 invoice inside with the signature from the user who sent the zap.
It's all described by NIP-57, a spec I put together to support this:
https://github.com/nostr-protocol/nips/blob/master/57.md
I was working on c-lightning at the time and I thought it would be really cool to replace the "like" button with an instant bitcoin micro-payment. I think it worked out quite well! There are many sites utilizing zaps in all aspects of the protocol, such as a decentralized market for AI job requests (data vending machines), zapgoals and zap fundraisers. All built on this note type. protocol synergy!
In Why I’m betting on NostrAfaik there is no key rollover story or recovery. I know it’s been discussed and I found this PR: https://github.com/nostr-protocol/nips/pull/637
KERI sounds interesting, I’ll read up on that. Maybe you can review that PR and share some insights?
In Why I’m betting on NostrI was playing around with it a few months ago and set up a relay for fun (https://blog.notmyhostna.me/posts/taking-a-look-at-nostr/). I found it to be a very nice starting point if you want to follow how a protocol is being developed as it's all very transparent, simple and easy to follow here:
https://github.com/nostr-protocol/nips
In Why I’m betting on NostrWell... people?
Quite a few of them crypto enthusiasts and sometimes timeline can look like you've come across some crypto scam page, lol. This scares some people.
What I like about Nostr is its simplicity comparedy to ActivityPub.
The protocol is basically a set of NIPs[1] (Nostr Implementation Possibilities). Each of them describes what features relays and clients may or have to implement.
Out of 99 (currently) NIPs only one (NIP 01) is mandatory and around twelwe are stable\final (the other ones are drafs for now). So to create a basic nosrt relay or clien you have to implement a bare minimum of functionality.
The way it works:
Each user has a public and a private key.
Public one is to be shared with other people and can be published online.
The Private one is your identity you use to "log in" via nostr client of you choice.
As soon a
Read the rest
s you log in with your private key a client will fetch your notes (and notes of other people you follow if any) from relay(s), assuming you were communicating with these relays before (which will be the case unless you are using more than one client with completely different sets of relays they are talking to).
In Nostr a client (a web app, mobile app, cli tool etc) simple publishes notes to N relays and gets\receives notes from them.
Quite similar to RSS, except you have more than one RSS agregator and feed is being actively pushed to the said agredgator by "publisher".
Also if you are using a client that implemented NIP-72 (like https://satellite.earth/) you basically get a simple reddit alternative
[1]: https://github.com/nostr-protocol/nips
this is effectively how nostr works. you generate a public/private keypair. the keys are bech32 encoded.
https://github.com/nostr-protocol/nips/blob/master/19.md
In Why even let users set their own passwords?What if you could run your node on a raspberry pi in your closet, and interact with thousands of others doing the same (at the cost of a static IP address)?
https://github.com/nostr-protocol/nips/blob/master/65.md
In The case for the decentralization of online forumsSecure Communication with Deniability for Nostr
2 points · Open discussionNostr is decentralized. I think a big part of the idea is that relays just dont carry spam/bad actors. The protocol doesn't, as of yet, have need to handle most of your "it doesn't handle complex social issues X Y or Z" nags because it so far handles these problems socially, not technically, and that's been working for now.
Nostr is all based on anonymous cryptographic identifiers, so it seems like you have some special definition of anonymity that you are looking for, as it seems nothing if not anonymous. Having a stable identifier allows relays to know who to send versus who not to send, and allows connecting data together. Users are free to sock puppet up to their hearts content, if they wish to further diffuse traffic.
The appeal? The appeal here is that this is an incredibly malleable & comprehensible low level tool for messaging. Co
Read the rest
mpetitors like AtProto or ActivityPub involve complex protocols to exchange/syndicate data around, as much as the payload of the messages themselves. They are high level visions for what a network is. By compare, Nostr's low level approach is organic & searching not a refined final product, but a thriving ecosystem of expanding ideas.
Nostr has extreme elegance as a protocol by being focused primarily on messages themselves, which start as very simple & understandable self signing devices. The transport & exchange of messages is almost incidental, and indeed, Nostr over shoebox or carrier pigeon is possible. This allows a lot more flexibility with how the network can form distributed connections, allows great offline capabilities, allows creative relays & creative/selective distribution mechanisms to form.
Nostr is an excellent base layer. The base specs are quite short & direct. It's a protocol one can happily implement in a weekend.
Nostr has incredibly wild applications, because it is a simple extensible base. There's a wide variety of interesting capabilities that have already need accepted as Nostr Implementation Possibilities, NIPS, that grow & build on one another. Nostr base protocol is just a start, just the seed of an idea, one that's meant to be iterated on & expanded, and it's so easy & direct to do so. This is the biggest advantage by far; I cannot stress this enough. Not trying to do absolutely everything & making a modular simple protocol to start building & iterating from is all the wins, is the Bazaar to the ambitious Cathedrals.
https://github.com/nostr-protocol/nips
Nostr is by far the most malleable, most open set of possibilities, the most grow able, of the social networks we have. Everything else seems to have been designed to arrive somewhat fully formed, ready to go, but Nostr's strength is that it doesn't purport to know every use case & to have a total picture of what it is. It's a much simpler idea, with much more focus on finding out the uses.
There's little spam at the moment. There will be. But at that time the relays (pieces of server software that relay nostr messages) can step in and implement spam control via whatever they see fit. Perhaps some smart filtering, perhaps pay a few sats to have a message relayed or perhaps some real name policy. Clients can pick a (set of) relay(s) which fit their preference best. Or not, and accept the default.
The protocol is surprisingly simple to read [1], many relays and clients exist already.
I exchanged messages with a friend of mine who was using a very different client and it just worked!
Personally I like the fact that you can 'like' posts by sending a couple of sats via Lightning. I think it is a great motivator to write thoughtful, quality content.
Currently nostr is radical, weird and unpolished. The Amethyst client is slow at t
Read the rest
imes. But the pace of development is incredible.
[1] https://github.com/nostr-protocol/nips/blob/master/01.md
I've changed views a lot. I absolutely intend to spend a significant fraction of my life working on interoperability & interoperation, in trying to find & capture the essences that are the same. I identify a lot with the value system you're presenting. I'd felt a bit morose originally that BlueSky/@ had made their own fresh take.
What's charged is my mindset. I'm no longer coming with such a view of scarcity. Of insisting we work together.
You know who gets everyone in a big meeting room & then decides what to do & builds that architecture out? Corporations. In contrast, I think the organic growth model is a huge win here. We can cover more ground, better assay where the rich & nutritious veins are, better explore the many ecosystems of possibilities with an organic model.
It's all still so early, we're so young. ActivityPub, Nostr, BlueS
Read the rest
ky/@.... they barely have antecedents and none are proven. We are in free-form mode, none of us know what to do yet. You mention RSS, but that's a read-only medium. That attempts to explore the bounds of that didn't get that far: Google Buzz, the Salmon Protocol. OpenSocial. They weren't necessarily bad techs but we never really figured it out, democratized it, pulled it off.
We have multiple different explorers now, and I like it. The ability to keep making useful growth, is, I think, what counts here. ActivityPub has shown some decent flexibility in going across-mediums, but we don't have a ton of extensions, a ton of new modes for it (I think Akkoma, an Elixer-based fork of Pleroma is the most boundary-pushing, and reaction-emoji is their main defining claim to fame). BlueSky is brand new and we have no idea how far it'll go, but it also has a lot of really neat compelling web-oriented ideas in it's core, of signed DIDs that let it be web without having to rely on http:// and dns:// and give us self-sovereignty. Nostr I think is incredibly fantastically compelling, for it's hackability, and what a huge roster of incredibly smart & sharp "Nostr Implementation Possibilities," (https://github.com/nostr-protocol/nips). What a beautiful phrase that captures so much essence of where we are: finding possibilities.
Right now, we need to emerge a shit ton of complexity. We need really wild off the wall stuff. We need lots of ideas & possibilities. We need growth & exploring bounds. Once we have some actual experience building these things & running them as smaller scale individual/microcollective operators & peers, I think then we can focus a lot more on narrowing down & coming together & deciding where and how to meet.
Showing the 15 most recent of 33 sources. Enable JavaScript to search and browse every indexed mention.