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

There’s also the question of do you need transactions.

There is transactions for consistency, and there’s transactions to ensure correctness of the system state (like indexes)

Many Nostr use cases actually do not need strict consistency. There is only some level of correctness required.

CRDTs and conflict resolution fixes this. A notes app for example can be represented as a set of diffs on top of each other, and two updates to the same note can be merged.

This is also why Dynamo and eventually consistent databases exist. You could also have slightly smarter relays that can do slightly smarter queries if you want.

This is something I can support in the next Nostr.land version

Damus on Android = notedeck

Damus currently allows editing note content by trusted relays. So that could be used to replace media links with optimized versions

Nostr.land optimizes your relay data connection only.

To optimize media I’d need to be able to modify the note content.

Currently Damus allows this but this won’t work with Notedeck, I guess nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s could do something that allows nostrscript modules for this.

It is separate. The biggest data eater on Nostr is media, not relays.

An app built with nostr.land and some other performant relays would not have any difference from Primal’s data usage if it optimizes media.

Their caching server is not the part saving data, it’s their media optimization proxy.

They can get rid of it and instead use high performance relays like nostr.land and it would still barely use data :)

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s if you ever want to migrate tigerbeetle between clusters if it gets too big or you change replication

create an account for the purpose of closing and closing only

when you want to migrate, create a linked set of events

- transfer all balance from source to closing account (use balancing_debit)

- pending transfer, close source account

after that on the new cluster both create the account and credit it the previous cluster’s balance (read back the transfer you sent to get how much it was at that instant)

your client should always try on the old cluster, if it fails with a closed error, try on the new cluster, and retry if you get an account nonexistent error

At its core it’s actually just an extension of the FIDO specification, with now “resident” credentials.

Security keys have no memory. What actually happens is the website sends you back a list of possible security keys, and the encrypted version of the private key. The security key decrypts it and signs with it.

With resident credentials, the security key keeps track of which sites etc. the key was registered on, and when you go to example.com it can tell you “would you like to log in with x account”

That and “emulated” security keys, which use the TEE/TPM/SE in your phone or desktop

They push them because it’s so easy to use for users, and reduces account compromise risk for them.

The best way to explain it is it’s npub based login but per-website. And it works with a security key, but also many OSes have integrated passkey stuff.

NFDB 2.1

identity of the 💰 🪪 💾 variety

a new tier (lower, not higher)

payments 📆

higher limits

UI rework

gm Nostr

👨‍💻 building the next version of Nostr.land

There is nothing in Pubky that can’t be implemented on Nostr. Many already are.

They use the Mainline DHT to signal where a user’s content resides. Nostr uses 10002’s spread to thousands of relays.

On Pubky, you need a semi-trusted homeserver that has complexity and can be easily censored. Nostr events can be transported via relays, or any other method like BLE meshes.

Otherwise, nothing changes.

nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 has this.

what LN wallet do you use for zaps? with NWC, ofc

You can also build sequential embeddings this way:

The summary of the last segment was as follows:

Since you are dealing with things that could be non-self-descriptive and probably are not what embeddings are trained for, consider feeding your text to an LLM first to summarize and turn into more explaining content.

Then feed that to the embedding model

64KB of memory should be enough

excuse me a CAR?!

German public transit isn’t extremely shit and even in places where it is people use it.

NVK would like to have a word about the “commies” that “stole” their HWW code that was licensed as OSS

then made it better

First time?

The API should return a “bulk-allowed” field before any bulk queries are made.

still true to this day

Looking for some small Nostr hashtags/follows that aren’t just Bitcoin/Nostr

This givee me an idea

If I can’t send sats now to someone, it won’t change the fact that they can’t receive it.

Instead of trying to improve LN reliability, we are trying to hide the problem in ways that will harm recipient adoption.

“The payment didn’t work” will become “the payment is stuck” “I paid a 20% fee for a payment” “I can’t get my own sats out”

This is an abhorrent system multiple times worse than EMV

If people give me $1, and publicly show a zap saying they did, then I should not have to claim it in a process where I might end up $0.

If the sender sees a lightning failure, it was going to fail anyway with nutzaps. But instead of pushing the problem down in the stack by making it harder to receive money, the problem could be addressed immediately.

This is starting to sound oddly familiar

Corporate capture

No one does their job properly either

I wish I had 10% of this 🤣

Why not more upload?

The answer is you throw out the hub, and *pair it as like you would with the hub* by putting it into setup mode

Then you allow devices to join on your coordinator and it just works, no hacky workarounds required

Since I am a nerd I have my Home Assistant pi shoved in a server rack.

The Zigbee coordinator is in another place with another Pi, that has a USB dongle connected and it connects to an MQTT server on the HA pi

It’s like Bluetooth but for smart home devices.

If you have Philips Hue devices they support it out of the box and are ridiculously easy to use with Home Assistant. A bunch of others do too

I’d recommend you use the Home Assistant OS and also set up Zigbee2MQTT.

As an alternative to your smart switches, you can use the Hue wall switch modules, which you can wire to any wall-mountable switch/button and link to anything.