Live data from Hacker News

Bluesky April 2026 Outage Post-Mortem

pckt.blog

81–85 of 85 posts

Re: Bluesky April 2026 Outage Post-Mortem

#81
post #78
post #37

Earlier quoted context omitted.

The comparison here is to something like TCP/IP. TCP/IP never goes down. TCP/IP is a protocol, the servers may go down and cause disruption, but the protocol doesn't really have the ability to "go down". Nostr is also a protocol. The communication on top of Nostr is pretty resilient compared to other solutions though, so that's the main highlight here. If tens of servers go down, then some people may start noticing a…

That's because TCP/IP is a protocol, not a (centralized or decentralized) server. A protocol cannot go down. It can trigger failures, it can be abused, but it cannot go down. It's like saying "English never burns". Sure, you can't burn English but you can burn specific books, newspapers and so on.

That's... literally the point I just made in my reply?

Re: Bluesky April 2026 Outage Post-Mortem

#83
post #79

Earlier quoted context omitted.

If nostr went down would people even notice?

The good thing about nostr is that, contrary to popular federated protocols, your identity is not tied to any single server, you own the keypair to your account, so you can continue using it just fine even if some relays experience a downtime.

until one day when a quantum computer comes along, then goodbye your control of your nostr identity in both the future and the past!

Re: Bluesky April 2026 Outage Post-Mortem

#84
post #80

Earlier quoted context omitted.

Getting clients to do the right thing is like herding cats, but there has been some progress. Early 2023 Mike Dilger came up with the "gossip model" (renamed "outbox model" for obvious reasons). Here's my write-up: https://habla.news/hodlbod/8YjqXm4SKY-TauwjOfLXS The basic idea is that for microblogging use cases users advertise which relays their content is stored on, which clients follow (this implies that there ar…

Thanks! Not to be critical - more like thinking out loud - and don't have solutions to following myself - but that sounds like it could 1) affect negatively to power concentrating into the top popular relays -> potentially leading to same kind of speech issues as semi-centralized ActivityPub, and 2) it won't solve need to maintain multiple firehose connections. I've been wondering if the multi-firehose architecture i…

Yeah, any time you need either an index or a caching layer you have to re-centralize one way or another. But decoupling those "services" from the data storage itself helps, and credible exit makes the gatekeepers far less powerful. An example: a few weeks ago nostr.band, one of nostr's main indexers/search services went away. Search is still somewhat impacted (evidence that we were centralized around it), but indexing (i.e. finding users' relay lists) is still covered by several other services.

Re: Bluesky April 2026 Outage Post-Mortem

#85
post #81
post #78

Earlier quoted context omitted.

That's because TCP/IP is a protocol, not a (centralized or decentralized) server. A protocol cannot go down. It can trigger failures, it can be abused, but it cannot go down. It's like saying "English never burns". Sure, you can't burn English but you can burn specific books, newspapers and so on.

That's... literally the point I just made in my reply?

Right but that's kind of meaningless, saying the nostr protocol never goes down, because the AT Protocol didn't go down in this bluesky case either. Protocols don't "go down". Stuff making use of protocols does.
Post reply on HN