Problem

Currently, Mostro uses the same replaceable event kind (38383) for multiple event types:

• Orders
• Ratings/Reputation
• Info (Mostro node information)
• Disputes

While these events are differentiated using the z tag (with values like "order", "info", "dispute"), clients that want to fetch only order events must:

1. Subscribe to all kind:38383 events
2. Download all events (orders, ratings, info, disputes)
3. Filter locally by the z tag

This creates unnecessary bandwidth usage and processing overhead for clients, especially those that only need order data for displaying the orderbook.

Proposed Solution

Introduce separate kinds for each event type:
┌────────────┬───────┬───────────┐
│ Event Type │ Kind │ Change │
├────────────┼───────┼───────────┤
│ Orders │ 38383 │ No change │
├────────────┼───────┼───────────┤
│ Ratings │ 38384 │ New (+1) │
├────────────┼───────┼───────────┤
│ Info │ 38385 │ New (+2) │
├────────────┼───────┼───────────┤
│ Disputes │ 38386 │ New (+3) │
└────────────┴───────┴───────────┘

Benefits

• Efficient client subscriptions: Clients can subscribe only to the event types they need
• Reduced bandwidth: Orderbook-only clients won't download rating/info/dispute events
• Better relay filtering: Relays can more efficiently serve filtered queries
• Cleaner architecture: Event kind alone identifies the event type, reducing reliance on tag parsing
• Scalability: As the network grows, this separation becomes more important

Considerations

• This is a breaking change for existing clients that rely on querying kind:38383 for all event types
• The z tag can be kept for backwards compatibility and additional context
• Clients and documentation will need to be updated
• Migration period may be needed where both old and new kinds are supported

Related

All these event types are currently created in src/nip33.rs using NOSTR_REPLACEABLE_EVENT_KIND from mostro_core.