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

181–190 of 198 posts

Re: I was right about ATProto key management

#181

Post by OneDeuxTriSeiGo »

direwolf20 wrote: post #147
OneDeuxTriSeiGo wrote: post #63

Earlier quoted context omitted.

It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second. The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user). - Building out PDS communities that are trusted takes time a…

The way I see it, Mastodon started with a core decentralisation system and then tacked on bits to make it more Twitter-like, while Blue Sky started with a core Twitter-like system and then tacked on bits to make it more decentralised.

I don't really think that's fair.

Mastodon started as an alternative software stack for GNU/Social (and Laconica before it) years before ActivityPub even existed. It was created in an already almost decade old community/ecosystem and was competing against a PHP tech stack that was showing its age (which is why Mastodon was created).

Comparatively Bluesky/ATproto was a greenfield project with no pre-existing protocol or community to integrate with. And architecture-wise atproto within like 6 months of their 1.0 release federated/decentralised really really well. Bluesky less so (as it's mainly the appview that is limiting).

Even then though bluesky still works pretty well in a decentralised/federated context if you compare the scale it's operating at relative to mastodon and co back when they were of similar project age. Like the appview architecture at a high level works well but it breaks down once you are at a scale of tens of millions of users. And it'll only take relatively minor tweaks to the internal architecture of the bluesky appview to remove this scaling limitation.

Sorry for the rant but point being the ATproto is doing pretty well decentralisation wise for being ~3 years old and accommodating the sudden explosion of non-technical users on the platform so early in its life.

Re: I was right about ATProto key management

#182

Post by bccdee »

robcohen wrote: post #180
bccdee wrote: post #161

Earlier quoted context omitted.

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.

> 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.

Re: I was right about ATProto key management

#183

Post by bccdee »

direwolf20 wrote: post #174
bccdee wrote: post #160

Earlier quoted context omitted.

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.

Sure, but it shows global replies, it provides global search, it's not O(n^2), it's not easily DOSed, and it's highly amenable to spam filtering, which are the issues you raised.

It's true that this solution doesn't work for private posts and DMs, but the n in O(n^2) is much smaller there, so I don't think it's as much of an issue for personal data servers to communicate directly in those cases.

Re: I was right about ATProto key management

#184

Post by neko-moe »

jadbox wrote: post #72
bnewbold wrote: post #11

fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem). I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running thei…

I'm not too familiar, but isn't there a way to host your own did:plc auth server?

You can host your own instance, but resolving forks is not self-authenticating and requires some central trust (because of the 72 hour rollback window for higher priority rotation keys). Not counting that, you could essentially run your own fully independent instance where the worst that could happen is that you lack some newer updates to people's did documents (but anyone can upload them since they're self-authenticating). Some people do run their own instances for caching reasons, but these just ingest operations from the official one.

In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.

Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]

[1] https://docs.bsky.app/blog/plc-directory-org

Re: I was right about ATProto key management

#185

Post by tsimionescu »

anonymous908213 wrote: post #115
tsimionescu wrote: post #112

Earlier quoted context omitted.

> 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. I agree that it does not need to do more than inform you - but that doesn't mean it won't do more. Please show me a sing…

I don't exactly go around saving advertisements, but plainly informational ones do exist here and there. Off of memory, an example of an indie game trailer I think is well-made is that of Wargroove[1]. It's a simple and clear clip reel of gameplay showing off a variety of content and features, and if I recall correctly, advertisements for it were simply smaller slices of the trailer. I think there's nothing offensive…

I will grant you that this type of advertisement is indeed benign (though if I were really really really nitpicky, I could claim that the pace of gameplay shown in the trailer is probably not indicative of how you'd play the actual game, and I'm not sure if the music is part of the game soundtrack).

Still, I think this is such a tiny minority of real advertisment that it's barely worth mentioning. For example, here is a trailer for the original The Binding of Isaac, which (while being an interesting piece of art in itself, which many ads are) is stil clearly not just meant to inform consumers about the game, but instead is meant to sell a certain image of the game that it may or may not invoke in you:

https://m.youtube.com/watch?v=iDFnMfJnI7s

I'd also note that advertisments for artistic products such as games are some of the most ambiguous about the line between informative and persuasive, as the "feel" (atmosphere, tone, persuasive storytelling etc) of the final product is an intrinsic part of its value in a way that is not relevant for, say, produce, or consumer goods. It could be argued, for example, that the Story trailer for Elden Ring captures a real and important part of the appeal of that game, despite it including 0 details about the gameplay, and despite it being entirely original footage and dialog that is not in any way part of the game itself. The same ambiguity doesn't exist about an ad showing the glamorous lifestyle of someone who gets a mobile phone plan from company X, in contrast.

Re: I was right about ATProto key management

#186

Post by tsimionescu »

fc417fc802 wrote: post #108
tsimionescu wrote: post #92

Earlier quoted context omitted.

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.

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 to a public institution's Matrix account, not in a manner that either (a) isn't e2e encrypted with no realistic risk of a MITM, or (b) doesn't require an out-of-band pre-approval, such as someone from the institution adding my account to some encrypted room.

Also, even if Matrix did find a way to make it easy to send e2e encrypted data to someone else without out-of-band communication, it would then suffer from the problem of spam. Every client would have to filter all incoming messages for spam, instead of being able to centralize this work at the server level.

Re: I was right about ATProto key management

#187

Post by tsimionescu »

direwolf20 wrote: post #132
tsimionescu wrote: post #92

Earlier quoted context omitted.

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.

None of this is fundamental to the federated model. It's only because email is older than modern security practices.

It very much is.

Even the web suffers from problems of trust to some extent, with the PKI being a huge vulnerability and relying on the collective action of all browser vendors to act as a check on any CA trying to break the agreed guarantees. But in a world where you would have a hundred, or even 20, different popular browsers, with different geopolitical assignments, it would be far harder to punish a CA that decided to sign certificates improperly, e.g. to allow some government or criminal enterprise to MITM communication.

Establishing identity in a non-centralized manner, and without requiring a second, already secure, communication method than the one you're trying to authenticate, such as an in-person key exchange, is in fact impossible, not just hard. There are partial solutions, with different trade-offs, such as the PKI for the web, the TOFU with optional verification options used in Matrix or SSH, or the web-of-trust model of PGP.

Re: I was right about ATProto key management

#188

Post by lmm »

zeratax wrote: post #116
lmm wrote: post #96

Earlier quoted context omitted.

Discord is technically centralised but in a way that mostly doesn't matter at the point of use, and its design avoids many of the failure modes of old school forums, IRC, or usenet where moderator cabals take control of any community and bully lowly users.

how does it avoid that? i have experienced just as many power tripping mods on discord as i have on irc. the only difference to me is that i have never seen an irc channel with over 20 million users

By making it very easy for every user to start their own server, rather than the multiple tiers of ircops/server admins/etc. where some users genuinely do have more power (and/or a level of technical ability that becomes a difference in power) than others.

Re: I was right about ATProto key management

#189

Post by apitman »

direwolf20 wrote: post #135
pythonaut_16 wrote: post #86

Earlier quoted context omitted.

I don't understand how you can seriously pose Discord as an alternative in this conversation as it's entirely centralized and full of all sorts of toxic behavior and failure modes. Like at least suggest old school forums, IRC, or usenet.

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.

Re: I was right about ATProto key management

#190

Post by nl »

WorldMaker wrote: post #179
fc417fc802 wrote: post #103

Earlier quoted context omitted.

> 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 t…

This is fairly accurrate
Post reply on HN