Skip to content

Conversation

shroominic
Copy link

This PR modifies NIP-87, which now defines a standardized way to discover nostr services like ecash mints or routstr providers.

image

This PR serves as an alternative to the proposed NIP-91: #1987

- Transform NIP-87 from Ecash Mint specific to general service discovery
- Keep existing ecash mint functionality (kind:38172, kind:38173)
- Add Routstr provider discovery (kind:38421)
- Define kind:38000 as general service recommendation event
- Provide framework for future service types
@shroominic shroominic changed the title Modify NIP-87: General service discovery - adding Routstr Discoverability Modify NIP-87: General service discovery - adding Routstr discoverability Aug 17, 2025
@staab
Copy link
Member

staab commented Aug 18, 2025

Compare https://github.com/nostr-protocol/nips/blob/82eeff3994e46a38556cd57f3a91d24d8e935291/90.md, I don't mind overloading the discoverability kind in this case, but k is probably the wrong way to partition it. This also might break clients that assume 38000 are only for ecash mints.

@kwsantiago
Copy link

Compare https://github.com/nostr-protocol/nips/blob/82eeff3994e46a38556cd57f3a91d24d8e935291/90.md, I don't mind overloading the discoverability kind in this case, but k is probably the wrong way to partition it. This also might break clients that assume 38000 are only for ecash mints.

This is a good point! A solution could be to introduce a new kind for general service recommendations to avoid breaking changes or adding a deprecation notice for ecash-only assumptions and mandate that clients filter on the k tag moving forward for a graceful transition.

@staab
Copy link
Member

staab commented Aug 18, 2025

Deprecations and mandates don't really work on nostr, so I would just create a new kind.


### Alternative query bypassing `kind:38000`
Alternatively, users might choose to query directly for `kind:38173` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
Users might choose to query directly for service events. Clients SHOULD be careful doing this and use spam-prevention mechanisms or query high-quality restricted relays to avoid directing users to malicious services.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider expanding this into a "Security Considerations" section, mandating clients to:

  1. Cross-verify a tags against recommended events
  2. Require pubkey signatures for service announcements
  3. Integrate with NIP-05 or kind:0 for provider identity

@rabble
Copy link
Collaborator

rabble commented Sep 24, 2025

Could this be used for DVM discovery as well?

@shroominic
Copy link
Author

Compare https://github.com/nostr-protocol/nips/blob/82eeff3994e46a38556cd57f3a91d24d8e935291/90.md, I don't mind overloading the discoverability kind in this case, but k is probably the wrong way to partition it. This also might break clients that assume 38000 are only for ecash mints.

38000 is already defined for fedi mint or cashu mints so every client needs to differentiate these 2 kinds, i dont think it will break by introducing new kinds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants