Oddbean

I'm not going to do this. My outboxes include nos.lol, offchain.pub, nostr.einundzwanzig.space so I can be better heard. My client also reads from nos.lol, relay.mostr.pub, nostr.wine, and relay.damus.io even though I don't advertise those as inboxes, so that I can better hear you. I don't think jumping to what some feel is the ideal model and cutting off part of the community in the process is going to change anything. Besides it sounds like Will/Damus will be trying this model, it's just a lot of work to get there (which I totally appreciate, especially along side the infinite parade of all of the other things we clients are expected to support). nostr:nevent1qqsxu9x33akalmvzf76ttvxrj0c25n3wer4ff0hhnpm49aamhguegdcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme03dzq87

We can live with both. If people say "nostr isn't decentralized" we can argue that this only applies to some clients, not others. People who depend on large well-trafficked servers have their own set of problems that will eventually motivate them to change to something else. That something else might not be the gossip model, but it might be a different thing. But I think they will eventually change because: * Centralization isn't something users want due to censorship concerns, so users will vote with their feet by switching clients, * Fixed relay lists mean people are unable to see all the notes from people they follow. Users don't want to depend on some possibly-flakey possibly-censorious middle-man relay or copying service, so users will vote with their feet again, * Centralization will cause the central hubs to become overloaded in CPU, space and bandwidth terms (I don't know which will be the straw breaking the camel's back). I don't like telling other people what to do. I prefer figuring out how to live with whatever they do.

Outbox model for known unknowns (missing notes you have the hash of) is perfect… …for unknown unknowns (missing notes you don’t have the hash of) can do set reconciliation using Negentropy to the relay(s) the NIP65 note specifies in an interval-based schedule (check the relay every X amount of time). That way all 3 models are used all the time. It might be impractical to only use outbox for *all* unknown unknowns, so I lean in this direction for practicality’s sake. If the static list is censoring, then the interval based syncing with negentropy and the NIP65 relay will get around it once the interval is reached. ⏳ 20/20 in hindsight but makes perfect sense.

I have a foggy vision of mobile clients spinning up a dvm to cache, collate and do the heavy lifting of OUTBOX websockets to all followed contacts, and it optimizes bandwidth to the mobile device. It, or another DVM, can serve as the npub's own dedicated OUTBOX, possibly also bunker. I don't know how that translates to a "global" feed.