Sandwich
Sandwich
> hum... some clients may crash on gs that are not geohashes. But after they fix it, this looks ok to me. Sounds like a client-issue, their implementations should be...
`nostr-geotags` now produces _tags_ in alignment with this nip.
Removed `tag[3]` from NIP - less bloat - was unneeded, especially since the `g` namespace is collision free.
`nostr-geotags` source and docs updated to support omission of `tag[3]` from geotags.
> Use L and l. It doesn't really matter that G labels are related to a particular domain, they're exactly equivalent to regular labels. @fiatjaf @pablof7z My primary argument against...
> I don't understand this. My suggestion is that you don't change g at all, which would only result in one pattern existing `NIP-32`: If I have a client that...
Primary updates 1. Moved everything to `G` tag. 2. Added `subRegionCode` and `interRegionCode`, 3. Added `numeric` again since there is no more collision with geohashes. 4. Changed format of `regionCode`...
> Maybe we could just specify an arbitrary JSON object of relay URLs with an object for each like stringified JSON in `content`?
Nope, just wanted clarification. I actually see a benefit to this, unlike tags, there's less chance of error for clients to add a relay twice since it's a dictionary. Granted,...
@KotlinGeekDev Using JS as an example ``` const relays = JSON.parse(event.content) for(const relay of Object.entries(relays)) { key = relay[0] policy = relay[1] ... } ``` vs ``` const content =...