rich1.0Mike Dilger ☑️ (npub1ac…9p35c)https://yabu.me/npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35cnjumphttps://yabu.meON BLASTR: The main problem I have with blastr (nostr:npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv) is that it works too well. So well that lots of nostr software is broken and the developers don't even know it is broken because blastr fixes it for them. It is like everybody is riding their bicycles with training wheels on, and we don't have a clear idea who what software would fall over if the training wheels came off. If events were not being copied (at least for a while) then the community of devs could find and fix the insufficiencies. But is that a pipe dream? Secondarily, I don't like the inefficiencies of copying events all over the place and I think that won't scale as nostr grows. But that is a self-correcting problem. ON THE INBOX MODEL: Outbox model is now also being challenged by "inbox model" (https://github.com/nostr-protocol/nips/discussions/1134, https://github.com/nostr-protocol/nips/pull/1135). I think these relay usage patterns can co-exist. These models of following people have different properties. Compared to the outbox model, the inbox model has these properties: * The publisher improves their reach by pushing their events to many relays * It is easy to see and count who is following the publisher * The publisher can cut you off, and you cannot follow someone secretly under this model * Readers only have to read from their own approved relays, not random ones they might not trust. This might also be nice for power-limited phones. * Worse overhead because events are copied to all the recipient relays, which might be a lot of copies. * It is not clear where reactions and replies go, or if everybody participating in a converstaion sees the reactions/replies of everybody else participating nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6