Skip to content

NIP-XX: Accommodation Listing Profile for NIP-99 Marketplace Listings - #7

Draft
pats2sats wants to merge 1 commit into
OpenMarketsFoundation:mainfrom
sudonym-btc:draft/accommodation-listing-profile
Draft

NIP-XX: Accommodation Listing Profile for NIP-99 Marketplace Listings#7
pats2sats wants to merge 1 commit into
OpenMarketsFoundation:mainfrom
sudonym-btc:draft/accommodation-listing-profile

Conversation

@pats2sats

Copy link
Copy Markdown

Summary

Adds an accommodation marketplace profile for NIP-99 marketplace listings. The proposal keeps accommodation listings on the existing NIP-99 listing event kinds and defines the profile-specific fields clients need for lodging search, rendering, and filtering.

What this defines

  • The accommodation marketplace profile tag.
  • Accommodation-specific listing tags such as check-in/check-out times and spec details.
  • H3-based g location indexing for area search without requiring exact property disclosure.
  • Promoted compact tags for efficient relay/client filtering.
  • Listing anchor and client behavior guidance for accommodation listings.

Scope

This does not define a new listing event kind. Generic marketplace behavior such as auto-acceptance, negotiability, deposits, dispute periods, and cancellation policy lives in the marketplace listing extension.

@ericfj2140

Copy link
Copy Markdown

The accommodation-specific profile split makes sense. One interoperability boundary still looks underspecified: availability.

This draft defines checkIn, checkOut, and uses minDuration, but it does not say how clients discover host-blocked dates, existing bookings, or otherwise unavailable stay ranges. Could the Scope or Related NIPs section explicitly state whether accommodation availability is expected to use NIP-52 or a companion availability proposal?

NIP-52 kind 31922 already models date-based intervals with inclusive start and exclusive end, and kind 31924 can group calendar events. Reusing those primitives could avoid a second incompatible calendar model, but an accommodation profile would still need to define the listing reference, authoritative publisher, privacy expectations, and how blocked periods relate to committed orders. NIP-52 RSVP events should not by themselves imply booking acceptance.

Even if availability remains out of scope here, an explicit non-goal and pointer would help prevent accommodation clients from inventing incompatible blocked-date tags.

@ericfj2140ericfj2140 mentioned this pull request Aug 18, 2026
Sign up for freeto 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.

2 participants

@pats2sats@ericfj2140