Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was right about ATProto key management

notes.nora.codes

Post reply on HN
Print view View original

101–110 of 198 posts

Re: I was right about ATProto key management

#101

Post by dboreham »

direwolf20 wrote: post #34
arjie wrote: post #3

My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me…

Blockchain is still like that. Today I am setting up a blockchain node. The chain is actually two chains that recursively depend on each other. The docs say to start one of them first and wait for it to fully sync. It prints a timeout error for every block, saying the other chain node software was unreachable, and is estimated to catch up to current block height in about 200 years, which can't be right. Maybe I need…

Nice to meet a third person who both works with blockchain and understands distributed systems ;)

Re: I was right about ATProto key management

#102

Post by anonymous908213 »

tsimionescu wrote: post #95
anonymous908213 wrote: post #64

Earlier quoted context omitted.

I don't agree. I think the chief problem with advertising is that it is extremely repetitive. I'm not, in principle, opposed to being informed about new things relevant to my interests existing. In a world that is completely oversaturated with content, it is hard to gain traction on something new with word-of-mouth alone, even if it is of very high quality. There is a point to being informed about something existing…

Advertising is never going to inform you - it is by definition about persuasion, not information. An advertisement is always designed to try to convince you to buy a different product than you would rationally choose yourself. Even a seller in a physical market telling you their tomatoes are very sweet and juicy is simply trying to get you to buy: they have no idea, and don't care, if their tomatoes really are sweet…

> An advertisement is always designed to try to convince you to buy a different product than you would rationally choose yourself.

Perhaps you could consider toning down the absolutism. This is true in many or most cases, but certainly not all cases. Let's take, for example, video games. I can afford to purchase any game that interests me, and do. However, I often go several months between new game purchases, because I am not aware of any games that interest me that I do not already own. An advertisement for a game does not need to convince me to purchase it over an alternative product, it simply needs to make me aware of its existence and broadly convey what the game is about so that I will know whether it matches my specific game interests closely enough to investigate further.

Particularly in the modern world of hyper-specialised interests, it's quite easy to get into a niche of a hobby where you have found and already purchased all of the things you are aware of. As another example, there are hyper-specific novel genres where there are at most a couple of dozen entries in that genre and you are able to read every single entry in it. You are still interested in that genre, and will likely purchase anything else in it, should you become aware of it. Enter the benevolent advertisement, which makes you aware of its existence in a mutually beneficial way wherein you get more of the content you are interested in consuming and the creator gets money.

Re: I was right about ATProto key management

#103

Post by fc417fc802 »

nl wrote: post #23

> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky? Presumably to stop credential reuse attacks on Bluesky itself? Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!) I've done some work in the DID space. Not really a fan, and the space is full…

> I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.

I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)

Re: I was right about ATProto key management

#104

Post by fc417fc802 »

grishka wrote: post #45
nl wrote: post #23

> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky? Presumably to stop credential reuse attacks on Bluesky itself? Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!) I've done some work in the DID space. Not really a fan, and the space is full…

So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate? I really like the ActivityPub approach more. There, if a d…

I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.

Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.

While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.

Re: I was right about ATProto key management

#105

Post by Meneth »

fc417fc802 wrote: post #104
grishka wrote: post #45

Earlier quoted context omitted.

So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate? I really like the ActivityPub approach more. There, if a d…

I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the d…

"the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time."

Email has that problem too, doesn't it?

Re: I was right about ATProto key management

#106

Post by fc417fc802 »

anon7000 wrote: post #26
echelon wrote: post #22

Earlier quoted context omitted.

Peer to peer, not federation, is the way forward. We should only build peer to peer social protocols. Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control). {Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}. Bluesky and Mas…

Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra. Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But at…

> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping?

Presumably by fusing the P2P and federated models together. There's no particular reason those two models can't coexist within the same protocol. It just hasn't been created yet.

Similar to how a good mesh networking implementation will make use a high bandwidth backhaul such as the internet if it's available.

Re: I was right about ATProto key management

#108

Post by fc417fc802 »

tsimionescu wrote: post #92
hollow-moe wrote: post #55

Earlier quoted context omitted.

Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users…

Email is by far the least secure form of communication in common use right now. It's trivial to impersonate others over email, and every MTA that processes your email has access to the full contents, because they are never encrypted except in flight (and except by a few tiny disparate groups using PGP, and even these groups can't authenticate one another). And not for lack of trying, I should add.

Comes across as an ad hominem. Email is insecure due to being dated, having a massive amount of inertia, and being essentially impossible to upgrade in the necessary ways without breaking backwards compatibility. None of that has anything to do with federation vs p2p vs centralization.

If you want a fair comparison for reasoning about security related challenges and tradeoffs you should probably go with matrix.

Re: I was right about ATProto key management

#109

Post by Thorrez »

Meneth wrote: post #105
fc417fc802 wrote: post #104

Earlier quoted context omitted.

I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the d…

"the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time." Email has that problem too, doesn't it?

It might be the case that the designers of email and the designers of ATProto and the designers of AP all assumed the owner never changes. But I think the actual behavior of the protocols in the event of a change is different.

For email, if the owner changes, the new owner gets full control. This is nice for the new owner, but maybe not so for the old owner, because now any emails meant for the old owner can be read by the new owner.

For ATProto and AP, it sounds like in the event of an owner change, things kind of break. This protects the security of the old owner to some degree, but means the new owner can't really do much.

Re: I was right about ATProto key management

#110

Post by BrenBarn »

patmorgan23 wrote: post #85
BrenBarn wrote: post #74

Earlier quoted context omitted.

People often mention email as an example of federated communication, but the way email works in practice doesn't entirely live up to that ideal. Good luck getting your own self-hosted email server to send emails that actually reach anyone using a major email provider; they'll just be blocked as spam. In practice, email is much less federated than it seems. A significant proportion of people are just using gmail. You…

Federation does at least give you the choice of providers, even a little bit of competition goes a long way to improving a company's behavior.

But in practice in doesn't always give you a choice, because the biggest providers will embrace and extend and start providing things other providers don't. Or they'll just make it difficult to export your data, etc.
Post reply on HN