Add rationale for kind numbers
This commit is contained in:
@@ -102,6 +102,10 @@ Clients SHOULD include `alt` (accessibility descriptions), `dim` (dimensions), `
|
|||||||
|
|
||||||
## Rationale
|
## Rationale
|
||||||
|
|
||||||
|
### Kind 360
|
||||||
|
|
||||||
|
Easy to remember as a 360-degree view of places.
|
||||||
|
|
||||||
### Why not use NIP-68 (Picture-first feeds)?
|
### 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).
|
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).
|
||||||
|
|||||||
@@ -276,6 +276,10 @@ Content payloads SHOULD NOT include place identifiers.
|
|||||||
|
|
||||||
## Rationale
|
## 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
|
### No Place Field in Content
|
||||||
|
|
||||||
Avoids duplication and inconsistency with tags.
|
Avoids duplication and inconsistency with tags.
|
||||||
|
|||||||
Reference in New Issue
Block a user