Maybe map needs to be in right side column

https://iris.to/map geohash feed

Negentropy or "send only matching event ids, I'll request those that I don't already have" would help with bandwidth

What was buggy in neovim? I only recently graduated from IDEs to neovim. Vim would of course be even more universal and simple.

Yes to both.

Initial load of all the follow lists is just heavy. Need to use graph snapshots instead, at least on web & mobile, so there's that centralization. But you can always locally recrawl when you feel bandwidth-rich.

If you're near a border, maybe last used geohash should be used instead of current location

meant border not intersection

If you live at the intersection of geohash areas, frequent posting from neighboring geohashes can reveal your fairly detailed location?

We're probably moving with image & video clients to kind 1 with label tags. Only point for kinds other than 1 is if you want to be intentionally incompatible with other clients.

I think so too. Either social graph or pay to play. PoW hinders regular users (especially mobile) more than spammers.

I think social graph might be needed

How will bitchat solve spam in the geohash mode?

Paid relays are not good for onboarding and still need moderation. Web of trust does not work with ephemeral identities. Rule-based spam filtering doesn't work: it's a cat-and-mouse game that you can't win and rules get ever more complex, with false positives.

Bluetooth mesh mode doesn't have the spam problem, because spammers don't have global reach.

nostr:nevent1qgsy2ga7trfetvd3j65m3jptqw9k39wtq2mg85xz2w542p5dhg06e5qpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcqyzhwt8tpwanqqkl85mgvhmanljjy828qljuuk2sd274ujh2g722gv3wj4a6

True. Then the only option is to somehow restrict relay write access, which is not great. Bluetooth mesh works better because spammers dont have global reach.

Will need web of trust filtering when spam starts

In the meantime you can save it to home screen as PWA (from the safari browser's share btn)

I am already able to build it for ios, but would need to go through the app store compliance hell again. I might one day.

The suggestion is to add ["l", "picture-first"] tag. That is compatible with existing clients, yet allows image clients to show only posts that have that label. No unnecessary complexity. Kind 20 will remain a solution to those who seek a smaller audience for their posts and compatibility issues like you noticed between nostr.build and lumina.rocks.

Maybe someone will PR Olas & co. to use kind 1 instead 😅 Would prevent the same problem from happening over and over again.

It’s unnecessary complexity

They could query based on the ["l", "picture-first"] label tag.

If they choose to show kind 1:s that don't have the "l" tag they'd need to client side filter by event / image format.

Iris will continue to use kind 1 instead of kind 20 for image post creation:

* Works on most clients, doesn't break existing clients' reaction / reply based feeds

* Kind 1 events reach larger audience than 20

* No added complexity, no different handling for kind 20. Keep nostr client implementation simple.

* Clients that don't support images can just show the text content, or filter out notes that have images

* Clients that only want images can filter out posts that don't have images

* Optionally, they can use ['l', 'picture-first'] or similar tag for relay indexing of image posts

nostr:nevent1qgsy2ga7trfetvd3j65m3jptqw9k39wtq2mg85xz2w542p5dhg06e5qpz3mhxue69uhhvct4d36zu6tjd9ejuar09uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzqpdj0dmmuqxgt4u6xe86au3zyh6v2lkq9xzpuajdrqusv4n0fm3yqskns0

Thanks to nostr:npub1dmhju6xrn8y09malwrvrrs4krrt6sj7l6gtnf2q7d47nmqtldpgqgctgtm for the "For you" feed!