I have learned various useful things about Bluesky today and I appreciate everyone who engaged with me about it. Still somewhat frustratingly far from understanding *exactly* how certain things work, but I think I have an idea for future attempts at Discourse:

Maybe let's stop talking about whether something is "truly decentralized" or not, and instead talk about specific characteristics of either the software or its deployment, and just try to be as specific as possible.

For example, when I have used the term in the past, what I've been talking about is the ability to experience partial failure. It's also important to reduce the scope of partial failures. For example, my understanding is that if *today, right now*, Bsky.app were exploded by drone strike, "the Atmosphere" would functionally be annihilated. Something like 99.99% of its users would no longer be able to access their data. Nobody would use a thing called "bluesky" any more, after that.

But, we are not *that* far off of that outcome on the fediverse. FediDB says right now, total fediverse MAU is hovering a bit below a million; 973k. mastodon.social is 273k MAU. Losing 28% of your users is pretty far off from losing 99% of them, but it would still be pretty devastating.

Moreover, in a *hypothetical* future where Bluesky managed to actually get 70% of its users to use other services, the ability to decouple PDS from AppView at least has the *potential* to allow *some* users to keep their post history in the event of a catastrophe. If they *weren't* self-hosting their PDS but they *were* maintaining control over their handle via custom DNS records, they could at least have continuity of the same name, even if they lost their posts.

Whereas, in the context of this potential Fediverse ELE where Mastodon gGmbH disappears, everybody just has to go make a new account, search up all of their old followers, lose *both* all their posts *and* their handle, and start from scratch. To say nothing of the difficulty of re-starting development, which would be equally difficult in both cases. It's not *quite* to the level of, like, Twitter shutting down, but it's not all that much different.

@glyph I have an account on mastodon.social (the "centralized" instance) and an independent PDS on bsky. Imagine m.s shut down. I'd lose all my posts, and I'd lose my follow/followers UNLESS I was given 48 hours warning. However I could rebuild much of my network on another site.

If bsky shuts down, I have… all my posts in a dense, non human readable binary format, and… a json-rpc server from which someone, if it occurred to them to do so, could read them. Which would never ever happen.

@glyph The first of these scenarios is sucky. But the second is… well, bad enough it's not clear to me what the benefit of my pds surviving post bsky is.

I've thought often about making a limited frontend I can slap in front of my pds to display my posts as a sort of smol web archive if I ever quit bluesky. But it's frustrating to imagine doing unpaid dev to paper over the shortcomings in a corporation's product. And then my frontend would be pointed to as a "see, the system works!" thing. Ugh

@glyph I can imagine various systems someone could hypothetically create to mitigate the bluesky fragility problem. But I could also imagine mastodon ggmbh implementing a system where when you migrate your posts when you migrate follows, significantly addressing my problems there. Nobody gets points for hypotheticals.

I wish my handle here could be @ mcc @ dryad dot technology.

@mcc saaaaaame

@mcc I mean I don't wish my handle were mcc at dryad dot technology, I would want glyph at glyph dot im. But mostly same.

Whereas, in the context of this potential Fediverse ELE where Mastodon gGmbH disappears, everybody just has to go make a new account, search up all of their old followers, lose *both* all their posts *and* their handle, and start from scratch. To say nothing of the difficulty of re-starting development, which would be equally difficult in both cases. It's not *quite* to the level of, like, Twitter shutting down, but it's not all that much different.

@glyph starting over nearly from scratch when twitter died wasn't too bad

@mcc actually while we're talking about big hypotheticals, I have more of a brass-tacks issue that I keep procrastinating on, and maybe your deep knowledge here would help provide a useful answer. I have 2 presences on Bluesky, this account (bridged) and glyf.bsky.social, which is mostly just a placeholder so I have a "native" account, since… well, for obvious reasons, probably. Can I set up the custom DNS magic to point either or both of these at glyph.im, and would that be a good idea?

@glyph moving your .bsky.social account to your own domain would be absurd easy, you follow a simple guide within the bsky.social interface and add some TXT records to your domain. I can think of no reason not to do it tomorrow, unless you're considering moving your account off bluesky pds to a selfhost pds. You might want to do the migrations together. Maybe. I literally don't know.

Moving your bridgyfed… that would be a question for bridgyfed. It would depend on how bridgyfed works.

@aeva I do wish I had my post history, though

@mcc I guess I was more thinking about whether I would want my native ("just in case, but mostly just follow the other one") or bridged ("follow this one unless mastodon blows up I guess") should be like the 'glyph.im' toplevel, or whether there's a cost imposed to changing later

@glyph As far as I know changing later is virtually zero cost.

If it were me, I would put a bridgyfed tag in like bridgy.glyph.im or bridged.glyph.im or mastodon.glyph.im. this would avoid confusion if someone tried to interact with your bridged account like a regular bsky account, which it isn't*exactly*

@mcc I mean… creating that *illusion* is the whole point! But yeah you’re probably correct. Perhaps for symmetry I will just do mastodon.glyph.im and bluesky.glyph.im

@glyph I do think having a merged feed, if it's possible, would be valuable for a few reasons