Oddbean new post about | logout
 Though, too: More infrastructure, widely distributed system means more complexity, more fragility and a bunch of ... interesting effects to address. Some of them, so far, seem to be handled not very well in #nostr , hope this will improve at some point. And maybe not everything of this is technology. 
 which issues are these? 
 Re-occurring problem I tend to see here is communication threads being just partially displayed (or quotes referring to stuff I can't see) because messages are sent through different relays. That's the most "visible" aspect. If it works this way, I'd have to be sure to have at least one relay in common with each contact I'm communicating with all the time _and_ this particular relay needs to be available to work well. Generally, accounts being closely tied to servers seems to me one of the major drawbacks in protocols like ActivityPub or Diaspora, but the opposite probably should be much more akin to TCP in general: There's a myriad of unnamed nodes, the protocol makes sure "information" is sent from sender to recipient _under all circumstances_ and will try to choose hops / relays at hand for that to work. The very moment relays become more prominent (like, "choose yours" vs "you're blocked on this one" vs "this one's a paid service", this whole concept seems to give again too much power to individual relays that just shouldn't probably be there). 
 I understand what you say when you use the word fragility, but it’s exactly the opposite of fragile. Nostr doesn’t “go down” like other platforms have. 
 Depends on how you understand "goes down". If talking about the network as a whole: True. If talking about the likeliness of communication between two random actors being temporarily interrupted without notice or workaround by the system itself: Unsure. 
 Agree, but that’s not what fragile means. Maybe unreliable? But how many times does your scenario play out? How unreliable does something have to be to be officially “unreliable”?

I’ve only had post not propagate because of clients, not the protocol. 
 I'm not sure whether this is really the point - or rather the fact that this kind of (obvious) unreliability, including measuring or benchmarking it, hasn't apparently been considered on protocol level. As a participant, an unreliable communication system is (strictly speaking) even worse than one that visibly fails ever then and now...