few

nostr:note1lm07jhrq6krlmzh0aa33jtz9qq7acd335546l793aphau7zag3xsvnxmym

Reply to this note

Please Login to reply.

Discussion

We're trimming everything to be local-first, and getting LE Bluetooth going, but nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj suggested also going full Kafka on the other end of the spectrum and I'm like...

Hear me out:

Have both. They solve their own use cases.

When you want to search the world’s largest library that’s the tradeoff you are making.

But once you find it, or get a book from a friend for example, you put it in your indexedDB database and congrats.

I personally envision the hierarchy ad follows

- Indexers, that have almost everything. They are the Google of Nostr. People push their events here and others find them.

- Large relays, which serve large communities. Think Nostr.land, Damus, etc. These are hubs for retrieving content in bulk.

- Community relays. These can be self-hosted or hosted in the cloud. People push from here to large relays and from large relays to here, what they care about.

- Local cache. This is the user’s own space and that is it.

The ideal relays would be:

- indexer: custom software

- large relays: strfry on medium end, NFDB and possible other options at large end

- community relays: could be a mix of strfry, NFDB, realy, nostrdb-based

- local relays: nostrdb, indexedDB-based

You use a search tool to find books.

You go to a library to read the book.

If you care you add it to your own collection as well or share it with your friend group.

now implement deletions

correct

its caches all the way down

or all the way up

all good networks converge to a tree. Nostr is no exception.

you can see this in IP

- local peering

- “hub” IX peering at large centers

- medium-sized IP carriers

- huge IP carriers

or the internet

- search engines

- large content hubs

- community forums

- personal sites

to rely on a cache relay for certain things like global search is no weakness, but the good apps are which can tolerate and re-shape their network topology based off of the current situation

Yeah, I've spent months figuring that auto-confuguration out. And nagging you. 😂

cache rules everything around me

Did you upgrade to Kafka, or still the other one? Can never remember the name...

A good amount of companies scrapped Kafka for Pulsar, so why should I move back to the inferior solution? :)

I don't know, haven't used Pulsar before. Knees-deep in Kafka at work, and low-key totally in awe. Biggest interface I've ever seen, and I've seen some doozies.

Pulsar deals better with variable loads, but Kafka is best for Gigantic Interface Spaghetti, right?

We probably don't have a load to justify Kafka, yet, but hold my beer. 😂

No, 99% of use cases would work with both of them. The benefit is Pulsar was designed with hindsight.

Okay, well it's your call, since I don't have to run it.

bluetooth would be cool

🤔

How? making every client a potential relay?

yeah damus Android/desktop works this way