Add rationale for kind numbers
All checks were successful
CI / Lint (push) Successful in 31s
CI / Test (push) Successful in 58s

This commit is contained in:
2026-04-22 15:37:45 +04:00
parent 9468a6a0cc
commit 95961e680f
2 changed files with 8 additions and 0 deletions

View File

@@ -102,6 +102,10 @@ Clients SHOULD include `alt` (accessibility descriptions), `dim` (dimensions), `
## Rationale
### Kind 360
Easy to remember as a 360-degree view of places.
### Why not use NIP-68 (Picture-first feeds)?
NIP-68 is designed for general-purpose social feeds (like Instagram). Place photos require strict guarantees about what entity is being depicted to be useful for map clients, directories, and review aggregators. By mandating the `i` tag for POI linking and the `g` tag for spatial querying, this kind ensures interoperability for geo-spatial applications without cluttering general picture feeds with mundane POI images (like photos of storefronts or menus).

View File

@@ -276,6 +276,10 @@ Content payloads SHOULD NOT include place identifiers.
## Rationale
### Kind 30360
Pairs with kind 360 (Place Photos). Easy to remember as a 360-degree review of all aspects of a place.
### No Place Field in Content
Avoids duplication and inconsistency with tags.