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

161–170 of 198 posts

Re: I was right about ATProto key management

#161

Post by bccdee »

robcohen wrote: post #33
direwolf20 wrote: post #32

Earlier quoted context omitted.

Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out. A P2P system requires every user to filter every spam message, together consuming far more effort than the spammer needed to send it.

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.

Re: I was right about ATProto key management

#162

Post by skybrian »

Dylan16807 wrote: post #83
skybrian wrote: post #2

It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.

If you mean the buggy and badly documented process, sure. But the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.

I see this as a mistake caused by really poor docs that should explain what to do and warn not to do the thing this person did.

It's also true that big instances have a lot of power and it's going to require a lot of growth of alternative instances to fix that, which will take time. At least it's possible, though. It's an intended outcome.

Re: I was right about ATProto key management

#163

Post by mariusor »

glenstein wrote: post #79
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…

I don't disagree, but I'm baffled that, with P2P as your preferred outcome, your orientation toward federated infrastructure is one of opposition rather than support. It feels philosophically confused to me; they're your natural allies, they're a step in your preferred direction and they have an instance of real world success (well, to a degree) which is important. Whatever theory of change motivates this form of cri…

I think supporters of P2P as "the one true way" perhaps don't realize that federation is just as peer to peer if your user count is 1.

The fundamental distinction between a communication network that is p2p and one that is federated is the storage mechanism.

For p2p the network itself is the storage, and as a participating node you connect and retrieve what is addressed to you while the amorphous data blob that contains said messages remains to float in the network. While for a federated network, the receiving node needs to be present on the network at all times to be able to access/receive the messages addressed to itself, after which the messages are absent from the network (to some degree or another).

Personally the overhead of having the network having to bear the weight of all its nodes data is too large to make it viable.

Re: I was right about ATProto key management

#164

Post by jrm4 »

account42 wrote: post #124
miki123211 wrote: post #99

Earlier quoted context omitted.

The problem with centralized social media is that the admins have power over you. They can ban your account with no recourse, censor some of your posts (or some posts you want to read), or even post something from your own account that you don't approve of. Mastodon doesn't change this, it just changes who the admins are. It lets a person under the jurisdiction of admin A interact with a person under the jurisdiction…

> They can (and very often do) defederate from instances that post "too much nazi content", and if you disagree with the decision, there's again no recourse (you can migrate, but you won't get your lost relationships back). Worse, they defederate instances that don't also defederate instances that they dislike badly enough so you can't even have neutral instances where you can communicate with everyone.

Yes, very good point sure. I (as a Black not-right-wing person) have huge problems with the whole "The Bad Place" thing (long story short, Black folks that I generally agree with politically are absolutely horribly ban-heavy and way too power-trippy on moderation.)

Re: I was right about ATProto key management

#165

Post by Diti »

culi wrote: post #5
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…

ATProto can be used be used for a lot more than just microblogs https://tangled.org/

So can ActivityPub, as far as I know. Most of the social coding projects agreed upon a shared vocabulary: https://codeberg.org/fediverse/delightful-fediverse-experien...

Re: I was right about ATProto key management

#166

Post by jeremie »

direwolf20 wrote: post #139
jadbox wrote: post #72

Earlier quoted context omitted.

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

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 involved there!

Re: I was right about ATProto key management

#167

Post by anonymous908213 »

h3half wrote: post #154
anonymous908213 wrote: post #58

Earlier quoted context omitted.

There is no ambiguity that needs further clarification, I am talking about the words as written. Their entire message clearly conveys they believe there is an objective design standard that everyone should strive to adhere to, and they are criticising a website for daring to deviate from their ideal standard as though it were an objective flaw and not a matter of personal preference. > getting upset over blatantly su…

Subjectivity is implied. You’re shadowboxing against a claim that the person you replied to never made. Communication is more than the simple dictionary definitions of the words being written. And as has been pointed out, you are yourself asserting your opinion about subjective communications as fact (i.e. that you should always make it denotatively clear to readers when you’re going your opinion and when you’re glob…

I will give you credit, you have an art for writing absolutely infuriating comments. How is it that you manage to so perfectly encapsulate the exact thing you baselessly accuse one of doing?

> You’re shadowboxing against a claim that the person you replied to never made.

You start with this, and then immediately lead into:

> Communication is more than the simple dictionary definitions of the words being written.

> that you should always make it denotatively clear to readers when you’re going your opinion and when you’re globally asserting something)

Neither of which are claims I made. At no point did I engage in the dictionary-definition pedantry that plagues this site. I was specifically highlighting how the sentiments they expressed in their message come together as a whole. An accusation that one "forgot to take basic principles into account" cannot possibly be construed in any way other than insulting. That phrase denies the possibility that the OP considered readability but consciously chose to make a trade-off in alignment with their own values, asserts the author's view as a matter of principle, and denigrates the person who "forgot" to consider it.

> you are yourself asserting your opinion about subjective communications as fact

Insofar as words have any meaning whatsoever, I am observing a fact about how they chose to communicate. If you really want to play the stupid game the people of this forum love where you play at the margins of language endlessly redefining everything into meaninglessness to score points in an argument, you can count me out.

Re: I was right about ATProto key management

#168

Post by grishka »

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…

> 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 fundamentally immutable field of any AP object, including an actor, is the ID. In practice, objects usually don't change types either, even though the spec technically doesn't forbid that. The only case I know when they do is when you edit a post and attach a poll, or remove a poll from a post that had one. Then the type changes between Note and Question.

Of course the dependency on DNS isn't nice. But we haven't invented anything better yet, so this will have to do for now.

Account migration on the fediverse is a thing, but it could be better by transferring past content. This is an active area of research right now.

Re: I was right about ATProto key management

#169

Post by tptacek »

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

No it isn't.

Re: I was right about ATProto key management

#170

Post by troyvit »

account42 wrote: post #120
embedding-shape wrote: post #117

Earlier quoted context omitted.

There are different types of attacks possible though, most broadly you can divide them into "design holes" and "implementation holes". This seems to be about preventing a design hole, and those you need to prevent with architecture/design, you can't just fix those once the implementation and documentation is done.

But the design hole is treating (IMO unfortunately) transient identities (the web's domain name system) as something that should persistently identify something. Adding hacks like this doesn't fix the underlying mismatch but creates new issues as seen in the article. Or to put it another way: Domain names changing hands is how the web works. If you design your system to support web identities in a way that domains ca…

Even though naively I treat my own domain as my online identity I see what you mean since they can be taken away by actions outside of our control.

What would work better though? Like are we talking a more hardened identification system tied to personal data that can't change? If that's the case are there negative privacy effects of that, especially with whatever system controls that data?

Post reply on HN