Oddbean

I'm trying to establish a better understanding of OUTBOX and INBOX model as it pertains to relays to work in improvements to the BoostZapper project for greater reach. Good longform post by Mike Dilger for those looking for a succinct explainer https://habla.news/a/naddr1qvzqqqr4gupzpms35h0lgrqe542lg8ly9dy0qrnp3jgjy43z4cmmds4mv7mkcnjfqqxnzde3xycngdpjxg6nqdfs3tegz3 "Later, NIP-65 made a new kind of relay list where someone could advertise to others which relays they use. The flag "write" is now called an OUTBOX, and the flag "read" is now called an INBOX." Note that NIP-65 does not refer to this anywhere as the OUTBOX or INBOX. None of the Nostr NIPS refer to OUTBOX or INBOX apart from a reference in NIP-04 regarding users receiving messages in their inbox under another context. If OUTBOX and INBOX are intended as user interface terms, this should probably be expressed in some recommendation NIP My plan is to follow the implementation advice given by Mike in his article. I'll just be internalizing as a read relay, or write relay. #grownostr #nips

Shame he's such a bigot. It's a good model. #cybersecgirl nostr:nevent1qqsvmh3mgn6590vzu6xy399v9gpzmc8gce2rjtdpykkvn044ym6eewspp4mhxue69uhkummn9ekx7mqzyqsmgxgs9k50czafqjz2ajf5ha2m0270whhdkwgjf6xhtey37sd9uqcyqqqqqqg097x9y

There are plenty of people I follow that I don’t agree with or even have strongly opposing views with on #Nostr. But I’m trying to contribute and help #grownostr. If I limit it to those I closely align with on all or even most things it severely limits possibilities and progress. Case in point - I’ve enjoyed a lot of your posts and info yet I disagree with your take. But I’m not going to now stop checking out your #privacy and #tech info. People are multifaceted and usually changing. #Bitcoin is for anyone and I hope Nostr will be too.

there is an inherent conflict between outbox ("gossip") model and broadcast (blastr) outbox is for private communication - ie DMs, application specific data, and closed groups everything that is intended to be public should be broadcast so we don't get this problem of being unable to find notes thus, if your client or middleware is looking for kind 0, 1, and other intentionally public things, there should be no limit to where you search for them - except for the case of intending to use a specific set of relays due to privacy, nor should there really be any limit to where you broadcast them at minimum, clients should consider this in their configuration system, there is good reasons to limit this for such as metered connections and sticking to paid relays, who also should be seeking to pull in all available public events paid relays should also broadcast any public type of messages on behalf of their users so that those that are not paying customers still see the public messages

https://github.com/nostr-protocol/nips/issues/1162 i've made an issue about this... i think if these distinctions were added to wherever they are relevant in the specification it would make it a lot easier for everyone to know how to design both clients and relays in order to maximize decentralization as well as defending privacy and bandwidth/battery use for mobile devices