5 ms·
It seems to me that a lot of the problems discussed in this thread (it's using a new protocol that doesn't work with existing tools, it uses crypto, handles aut
by iptq 3y ago
It seems to me that a lot of the problems discussed in this thread (it's using a new protocol that doesn't work with existing tools, it uses crypto, handles auth in the protocol, server can goes down) are just frustrations that don't have to do with the core innovation that Bluesky promises to deliver, and are instead confusing the AT protocol to be another ActivityPub-related protocol, rather than something completely different. In fact, it misses that having pull-based indexes is part of the idea of separating data publication vs. data curation. Yes, invite codes are kind of a weird thing to shove so deep into the protocol but sometimes these kinds of things are necessary to bootstrap a social network, and become relatively unimportant in the long term.
But on the other hand, the AT protocol is not all what it seems either. It's fundamentally not possible to do what they promise unless there is some kind of synchronization point where your most up-to-date identity can be searched. The documentation goes on extensively about the format of DIDs and the fact that there _is_ a resolution scheme, but it fails to mention that this resolution is being done by Bluesky themselves, and is not planned to expand into something that others can control. As a decentralized protocol, you would expect this to be something DNS-based, or if you really wanted something more peer-to-peer, DHT lookup, or at the worst case, a distributed blockchain. Seeing as this is a fundamental protocol-level change, the fact that they're rolling with the current approach makes me believe they will not be changing this in the near future. Bluesky is just converting one problem into another.
- pfraze 3y agoThe DID method has to satisfy a lot of requirements. I did a ton of research on DHT and blockchain approaches and none of them give the right performance, reliability, and cost outcomes while also supporting key rotation. DNS isn't far off but it's a little obtuse to cram it into, so we're starting with did:web and did:plc. We'll add others if they have the right characteristics. The only options that seem reasonable for PLC is for it either to be operated by some trusted multi-stakeholder institution like ICANN or to be a closed-group blockchain. I'm open to either approach but they require the creation of a consortium, which requires buyin from a set of stakeholders that don't exist yet. So until that happens, we run it, and that's why we called it Placeholder. We'll backronym it into something else once we get there (the C most likely being Consortium).
- seattleeng 3y agoSince you're familiar with this, what was wrong with how Farcaster approached name registration? Signing up or rotating your key is (relatively) cheap on Ethereum mainnet, and client apps could front the cost of signing users up. The user registry doesn't need to be maintained by a closed group in the long run (could start out that way, with Bluesky maintaining the contracts but eventually removing upgradeability when out of beta).
- bb010g 3y agoWhat are your thoughts on KERI? Some of Phillip's slide decks are weird to go through, but I really like its security & usability goals (key rotation needs to be realistic!) and the fact that it's going through the IETF RFC process. (Also, it avoids cryptocurrency-related blockchain baggage. It's disappointing how much blockchains have infested decentralized identity efforts.) <https://github.com/WebOfTrust/keri https://github.com/WebOfTrust/keri>
- epicsponge 3y ago> are just frustrations that don't have to do with the core innovation that Bluesky promises to deliver, and are instead confusing the AT protocol to be another ActivityPub-related protocol, rather than something completely different. AtProto is designed to be a federated protocol. The issue I have is that it is not interoperable with the major standard used on the federated internet right now: ActivityPub. You can built protocols on top of each other. Instead of doing that, Bluesky built a confusing alternative that is difficult to implement and difficult to work with. > In fact, it misses that having pull-based indexes is part of the idea of separating data publication vs. data curation. Mastodon does this already. There is literally an 'explore' part of the app that is completely separate from the feed and does not rely on ActivityPub. You cannot 'publish' content without having some sort of a federation protocol to go overtop of it, to network things together and send your content to the people who follow you. There is nothing about ActivityPub that makes a single global view impossible or hard to implement.
- mattdesl 3y agoCreating a restriction where every new social media protocol has to be built on top of ActivityPub sounds awful. There is room for innovation outside of this narrow scope of ideas.
- nr2x 3y ago“We have a thing that is arcane and hasn’t taken off with the public so don’t make a new one” isn’t exactly a stellar argument. The only winning move is to onboard users and given hundreds of millions of people may be looking to leave Twitter, Mastodon utterly shit the bed and missed the moment. That’s the end of the story: if the system can’t catch users raining down from the sky during a generational upheaval in social media it ain’t never gonna make it.
- robertlagrant 3y agoI wondered if Twitter would try extending its protocol so it integrated into the Fediverse, and just become the best Mastodon server ever that everyone ended up congregating on.
- deleted 3y ago[deleted]
- OJFord 3y ago> , it uses crypto, handles auth Good? HN also uses crypto. Unless I'm missing it, it's not using cryptocurrency or 'tokens' or anything, just good old fashioned cryptography.