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

171–180 of 198 posts

Re: I was right about ATProto key management

#171

Post by fc417fc802 »

grishka wrote: post #168
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…

> if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways Actually no. It's not supposed to break implementations that are made according to spec. It's not quite TOFU. Keys can be rotated. An Update activity would not work in this case because the new domain owner will not have the private key to sign it, but a periodic refresh that most implementations do will. The only…

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.

> Account migration on the fediverse is a thing

Has something changed within the past year or so? Because if you're referring to the mechanism where a notification is sent out that A@X has moved to B@Y I hardly consider that to qualify. Proper account migration would mean moving the account itself, not automated assistance coordinating the person behind an account switching from one to the other.

Re: I was right about ATProto key management

#172

Post by throwaway290 »

dwaite wrote: post #98
jacquesm wrote: post #68

Earlier quoted context omitted.

That's fine but we don't need to know about that. Comment on the article, not on the format in which it is presented.

The article that they are having trouble reading due to its format?

I had no problem reading it but what browser these days don't have reader mode?

Re: I was right about ATProto key management

#173

Post by direwolf20 »

jeremie wrote: post #166
direwolf20 wrote: post #139

Earlier quoted context omitted.

No, did:plc is centralised, not federated or anything. The whole ecosystem relies on a server at Blue Sky PBC

While did:plc was intended to be centralised from the start and under open governance ( https://docs.bsky.app/blog/plc-directory-org ), did: provided a framework to adopt other key resolution methods. As part of the IETF work ( https://docs.bsky.app/blog/taking-at-to-ietf ) this is a hotly debated area and I’d expect some solid evolution to happen as part of that process, super encourage anyone interested to get invo…

Having a framework to provide alternative key resolution methods isn't enough. You need alternative key resolution methods.

Re: I was right about ATProto key management

#174

Post by direwolf20 »

bccdee wrote: post #160
direwolf20 wrote: post #131

Earlier quoted context omitted.

This is how offline social networks work, and it might be fundamentally the only way social networks end up working. If each instance can't filter what it receives, then spam is too easy. If every message is globally flooded, the system scales as O(N^2) and is easily vulnerable to DoS.

AT solves these problems. Even if AT turns out to be a bust, they have an excellent architecture.

AT works by the use of global relays which see everything.

Re: I was right about ATProto key management

#175

Post by grishka »

fc417fc802 wrote: post #171
grishka wrote: post #168

Earlier quoted context omitted.

> if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways Actually no. It's not supposed to break implementations that are made according to spec. It's not quite TOFU. Keys can be rotated. An Update activity would not work in this case because the new domain owner will not have the private key to sign it, but a periodic refresh that most implementations do will. The only…

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 key. You can also force a refresh on a server where you have an account by pasting your self-hosted account's username or URL into the search.

> Proper account migration would mean moving the account itself

There is no such thing as "account itself" as a separate entity in ActivityPub. The URL that points to the actor object JSON, aka the ID, is your account, and that includes the domain. There are no higher-level identities.

Re: I was right about ATProto key management

#176

Post by notpushkin »

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’m trying to understand how “burning” works here. If I understand correctly:

1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.

2. They deleted their account and let the domain expire.

3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.

I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.

(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)

Re: I was right about ATProto key management

#177

Post by ramon156 »

direwolf20 wrote: post #138
tptacek wrote: post #42

Earlier quoted context omitted.

Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting. https://news.ycombinator.com/newsguidelines.html

Backseat moderating is also against the guidelines. If you believe the comment needs moderator attention, flag it. It's pretty ironic you can't say this rule without breaking it

It's not a rule, but I'd like it to be

Re: I was right about ATProto key management

#178

Post by mschuster91 »

Angostura wrote: post #90
mschuster91 wrote: post #67

Earlier quoted context omitted.

> What do you think is wrong about Mastodon? The same problems as always. Allow federation and you get... - federation wars and moderators conducting these wars using their own users as hostages - I left Mastodon years ago when some particularly dumb morons decided to do bitchfights regarding Israel / Palestine. No I'm not interested in your pointless squabble, but I do care when I suddenly don't see posts from a bun…

Sounds like you want to run your own private instance. That way you control your own moderation and federation policies

> Sounds like you want to run your own private instance.

I'd like to do so, yes, but that exposes me to a (not insignificant) financial cost, (especially in Germany) a significant legal risk from CSAM/DMCA et al., and a significant amount of effort in maintenance.

Sure, there are "Mastodon as a service" providers that take at least the legal risk and maintenance off of me, but again, these cost even more money, and now I have the risk that the hoster is a fly-by-night operation that one day decides to close up shop for whatever reason.

And if anything happens to that private instance (say, the hoster disappears, the machine disappears without a backup, or the hoster undergoes an orderly shutdown), in the best case I still may have enough preparation to migrate the followers, but the old content is lost in any case. And that is bad.

In contrast with Bluesky and to a lesser degree Twitter, I can at least be reasonably sure that the provider does not vanish over night.

Re: I was right about ATProto key management

#179

Post by WorldMaker »

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…

Not the parent poster, but the cynical impression I had from very early on for DID is that almost all of its complexity and much of the reason its space is full of half-working implementations rather than working ones is pretty obviously because it was designed to be an abstraction layer on top of "namecoins" and when the "namecoin" dependency was removed (for good reasons) there were not enough good ideas for what to replace that dependency with, sort of intentionally leaving what was left of the design in a sort of guaranteed perpetual state of half-implementation (including implementations based on some of the original "namecoin" ideas).

Re: I was right about ATProto key management

#180

Post by robcohen »

bccdee wrote: post #161
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.

Twitter is thronging with blue-check spambots. This idea has been comprehensively disproven. People will pay to spam you. In fact, judging by the Exodus of non-scammers, only scammers will pay to send you their messages—which makes sense, since they're the ones who expect to turn a profit.

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.
Post reply on HN