Replying to Avatar PABLOF7z

📢 NDK 1.0 is out!

Codename: Outbox ✅

When I set out to write NDK my main goal was implementing the gossip protocol, now known as *outbox model*. I wanted nostr applications to have decentralizing tendencies by *default*; transparent to the developer.

After a few failed attempts, it's finally here, which, paired with a bunch of non-backward compatible changes, prompts me to do a major version bump.

# What is outbox model?

In short, the outbox model allows nostr to fragment, instead of everybody coalescing around a few popular relay and using things like Blastr. Nostr simply doesn't work without the outbox model.

# Main changes:

* Outbox model support, obviously.

* `fetchEvent(s)` is now faster, (particularly with queries using exclusively `ids` filters).

* Fixed unstable relay back-off code (credit goes to nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 for the valuable testing infrastructure)

* Defaults to blacklisting wss://brb.io #censorship (credit goes to nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 for the widely hinted-at dead relay)

* Subscription aggregation now works when multiple filters run at the same time

* Subscriptions that should close when EOSEd are now closed when each individual relay EOSEs instead of waiting for all of them to EOSE.

* A better algorithm on when to signal a subscription's EOSE. The margin that NDK now gives to relays to EOSE is now a function of how many of the connected relays in the relay set have EOSEd (accounting for relays that are still sending events).

* There are *many* more changes that I needed to do to accommodate for this that I don't remember now.

Some of the most glaring breaking changes:

* `ndk.subscribe` now defaults to keeping the subscription alive; the default of closing subscriptions on EOSE was bothering me

* NDKUser changes the `hexpubkey` from a function to a getter, so wherever you were using `user.hexpubkey()` needs to change to `user.hexpubkey`.

# Enabling outbox model

Outbox model comes disabled by default *for now*, as soon as I test it more throughogly it will be the default.

To enable it you need to instantiate NDK with:

```

const ndk = new NDK({

explicitRelayUrls: [...],

outboxRelayUrls: ["wss://purplepag.es"],

enableOutboxModel: true,

})

```

The outbox model will largely be transparent to you and will work on the background once you enable it.

NDK getting gossip support is a huge win for Nostr's decentralization 🫂💜🤙🏻

nostr:nevent1qqs8r0jpp6tgspz2hfsrc3hdrw29lzccwnrdp82eyt28mxanargqtqcpz9mhxue69uhkummnw3ezuamfdejj7q3ql2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqxpqqqqqqz9h7e2s

Reply to this note

Please Login to reply.

Discussion

This is gossip protocol like in hashgraph?

This allows clients to essentially go out and find the relays where an npubs notes are located so you don't have to technically have a relay in common. This enables relays to be decentralized and clients to do the legwork to find the content based on the relays attached to the nprofile.

At least that's how I see it. I could be slightly incorrect in my understanding here nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 are experts on this topic and can help correct me.

yes, that;s correct.

This model depends on self-reported data, which is the thing that I find problematic on the gossip protocol; the way NDK will extend this is (doesn't yet but I already laid down the infrastructure for it) it'll keep a score of the number of events for different pubkeys it sees in different relays and will add into different pubkey inferred relay lists.

So yeah, the intent here is to further decentralize. I'm going to be experimenting with penalizing relays that are at the top of the list of many npubs to try and favor smaller relays (if it doesn't impact speed/event visibility).

The idea is that, sort of like bitcoin miners abandon pools when a pool becomes too powerful, NDK-based clients could favor smaller relays if a vast amount of events are happening in a handful of relays.

(Again, this behavior would only be triggered if it doesn't sacrifice speed/finding events)