ON 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

Both inbox and outbox models make sense for different types of users just like certain lightning wallets make sense for those who make payments vs those who receive payments. Would definitely like to see both of these models get integrated with multiple clients. Maybe clients could operate in "publish" and "read" modes (inbox and outbox) depending on the activity

Reply to this note

Please Login to reply.

Discussion

No replies yet.