atproto

perative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back. [0] https://github.com/bluesky-social/atproto/discussions/2705 [1] Alternatively there's an option for HTTP handle resolution instead via `/.well-known/atproto-did` [2] https://atproto.com/specs/account#pds-account-migration [3] https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...

elf, at least 10x. (1) Bluesky should have created subscriptions for their service, they wouldn't have needed the private equity had they. (2) Bluesky did more to block others making money than enable it. Graze was in talks with them to enable the creators using their feed system to make money, until Bluesky walked away. (3) Permissioned data would unlock monetization without blockchain. Permissioned data is being worked on, but the commentary from Bluesky is not promising. (1) Nobody in ATProto has built a permission system (that I'm aware of) (2) Bluesky are proposing a very simplistic system. This will put burden on app developers and create opposition the credible exit philosophy. Record history / editing. The former should be at the protocol level, the later on feature that is highly desired, possible today, but they resist with fervor. Bluesky could have put way more funding into the ecosystem, especially in hindsight with the $100M they picked up just after peak. Now they are struggling and stepping on that ecosystem, re: replacing Graze instead of supporting and integrating them with their latest "ai" stunt. Compare this to Hytale and what they are doing. Night and day. The Bluesky team has also made several PR mistakes, upsetting their base, they are really tone deaf. Hope the waffles are tasty!

computing, and only a small handful have really worked out. AKA, been resilient to abuse, attacks, neglect, etc, over years and decades. magnet links are cool but kind of the exception to the rule. I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "in real life" with millions of users, and I suspect that will be difficult, and I would not expect Bluesky to lead that charge (we already have our own pet DID method to maintain and support).

ata is governed by "lexicons" which are essentially type definitions used by app authors. E.g. `app.bsky.feed.post` type definition is maintained by the Bluesky team. There's a codegen that generates validation code from that definition. If validation doesn't pass, the Bluesky app server will just ignore that record. Records are generally treated by apps as untrusted input, similar to form submissions. They can be validated during ingestion or in the process of usage later.