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

191–198 of 198 posts

Re: I was right about ATProto key management

#191

Post by nl »

fc417fc802 wrote: post #103
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 c…

Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.

This in itself is a pretty good idea (with some bad usability, but at least technically interesting)

DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).

Re: I was right about ATProto key management

#192

Post by fc417fc802 »

tsimionescu wrote: post #186
fc417fc802 wrote: post #108

Earlier quoted context omitted.

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.

I don't agree with this at all. There are fundamental tradeoffs, and the reason no one has added e2e encryption to email, while we did add it to the web, is not because of backwards compatibility, it's because there was no compelling solution to some of these trade-offs. Matrix simply doesn't solve some of the problems that email solves, or at least not in an e2e encrypted manner. For example, I can't send a document…

Doesn't the spam filtering complaint apply in equal measure to _any_ E2EE messaging solution? Signal can't implement content based filtering either.

Out of band confirmation is similarly universal unless you're okay with either TOFU or delegation. (Delegation being recursively subject to the same choice.) TLS on the web goes with delegation and a root certificate store obviously.

My point being that none of this is specific to either email or federation more generally.

Re: I was right about ATProto key management

#193

Post by fc417fc802 »

grishka wrote: post #175
fc417fc802 wrote: post #171

Earlier quoted context omitted.

Yeah it's a fair point that the spec as written doesn't preculde handling domains in a more sensible manner. But in practice it's a headache. Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation. Maybe things have improved since the last time I encountered that? I doubt it though.…

> Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation. If you do it in a rapid succession, then of course it would not work. You have to wait at least a day, and then, when you send something to another server, there's a good chance it would refresh your actor and pick up the new…

Exactly my point. Account migration simply isn't supported. Not in any practical sense.

> there's a good chance it would refresh your actor and pick up the new key.

And how will this be displayed to users of remote instances? Last I checked it was a confusing mess on most implementations (ie every one I have experience with) and the mess would persist indefinitely without manual intervention in the db by a given remote admin.

In the event a domain has changed hands then even with remote intervention no truly satisfactory outcome is possible. This is due to, as you rightly point out, there being no higher level identities. The domain is a fundamental part of the account as modeled by AP which makes conflicts a serious problem.

Re: I was right about ATProto key management

#194

Post by steveklabnik »

direwolf20 wrote: post #141
mcdonje wrote: post #4

Earlier quoted context omitted.

>you get to use a slightly worse form of Twitter The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc

Is there an advantage to using this protocol instead of a more application–specific one? Perhaps the shared identity?

A few things. Shared identity is one of them. Another is that applications can understand each other's data and mix them together, if they wish, or keep them separate, if they wish. An instagram-like client can read the posts made by the microblogging client and re-use posts that include images, for example. Same goes with the social graph: re-use one from another application, or create your own.

Re: I was right about ATProto key management

#195

Post by pythonaut_16 »

apitman wrote: post #189
direwolf20 wrote: post #135

Earlier quoted context omitted.

The GP didn't say Discord itself, but the Discord-like model of small communities. Ironically it's also the old web forum model.

Almost. The key difference is I can log in to Discord once and post in unlimited communities. The auth UX is excellent. Joining communities is very cheap. We need an open protocol of this concept.

I can't help but laugh at the irony of posting this in an ATProto thread.

That's essentially exactly what they're trying to solve for although focused on the Twitter use case rather than Discord. And also one of the key advantages of ATProto over ActivityPub.

Re: I was right about ATProto key management

#197

Post by robcohen »

bccdee wrote: post #182
robcohen wrote: post #180

Earlier quoted context omitted.

You did not understand what my original post suggested. I'm not suggesting people pay to be certified. If a spammer wants to pay me $20 to see their message, I am happy to see it.

> If a spammer wants to pay me $20 to see their message, I am happy to see it. Yeah, but I'm not. It's spam. And the people whose messages I do want to see are overwhelmingly not going to pay $20 to show it to me. This is a system that selects exclusively for advertisements. Nobody would want this.

Would you be willing to see an ad for $1000? A million? Sure no one would pay it, but you can set whatever limit you want.

No one would want this? Again I don't think you understand what I am proposing.

It isn't a a system that selects exclusively for ads. It selects for people you know, then people they know, and so on, and fades out how often posts show up the further away you get. If someone pays more, then more people will see their message in their network as it compensates people for their attention, starting with the people who value their attention the least.

No one would want this? You think people don't want to get paid for their attention? This is essentially what a job is.

Re: I was right about ATProto key management

#198

Post by robcohen »

direwolf20 wrote: post #122
robcohen wrote: post #33

Earlier quoted context omitted.

This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.

Should I create 1 million accounts with bots that scroll endlessly to harvest microtransactions?

Ah yes, the sybil attack. This is why establishing an identity is useful, and worthwhile. An identity with no proof is likely not a real person, and therefore has little value in being advertised to.

If you're a real person, then yes, it is valuable to show you things.

Want to know how I'm right? Because fingerprinting browsers and tracking people is how we establish that they are real in the current advertising world. Advertisers pay for that. Thus it has value.

Post reply on HN