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

31–40 of 198 posts

Re: I was right about ATProto key management

#31

Post by NoraCodes »

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…

Thanks for responding, Brian. While I don't agree with a lot of decisions Bluesky and the broader ATProto community have made, I am very excited that progress towards real decentralization is happening; Blacksky's app view, for instance, was the trigger for me to try to finally try to set up an account. I would love to see more of a focus on the parts of the system that make this difficult, so that myself and other people who are tired of coupling ourselves to centralized systems can participate. It's hard for me to trust that this is the direction the community is interested in moving, but I hope you prove me wrong.

Re: I was right about ATProto key management

#32

Post by direwolf20 »

echelon wrote: post #22
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.

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…

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.

Re: I was right about ATProto key management

#33

Post by robcohen »

direwolf20 wrote: post #32
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…

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.

Re: I was right about ATProto key management

#34

Post by direwolf20 »

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 to run both nodes at once contrary to the explicit instructions in the docs which say not to do so.

I wouldn't be surprised if half of all blockchains were vulnerable to some kind of trivial double–spend attack because it's not possible that all the complexity has eyes on it.

Edit: you're supposed to download a 2GB JSON file containing the state as of the last migration.

The normal way to set up most blockchain nodes these days is to rsync someone else's node's working directory. Obviously this is worthless as far as a decentralised and trustless system goes.

Re: I was right about ATProto key management

#35

Post by direwolf20 »

jrm4 wrote: post #30

This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs. Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?

Isn't that literally Bluesky? A PBC must act in the public interest.

Re: I was right about ATProto key management

#36

Post by wmf »

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…

It seems backwards to worry about attacks when basic functionality is undocumented/broken.

Re: I was right about ATProto key management

#37

Post by direwolf20 »

Kwpolska wrote: post #9
wmf wrote: post #8

Earlier quoted context omitted.

If Bluesky wants to be taken seriously they need to invest in decentralization themselves and not leave it as an exercise for the reader.

How many users actually care about decentralization?

None, and it's okay to make a centralised platform but I wish people wouldn't fall for the decentralised marketing hype.

Re: I was right about ATProto key management

#38

Post by direwolf20 »

danpalmer wrote: post #24
bramhaag wrote: post #12

Earlier quoted context omitted.

Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.

Bluesky has been asymptotically approaching full decentralisation. A few years ago the gap was everything except a decentralised design, then it was AppViews, now it's "tooling and documentation" for the bit of the PKI that only 50 entities have done. Meanwhile I lost my Mastodon account history because I moved once, couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance, lo…

I honestly can't tell if this comment is trolling.

Re: I was right about ATProto key management

#39

Post by RobotToaster »

jrm4 wrote: post #30

This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs. Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?

Twitter but run by a bunch of NGO PMCs sounds even worse than twitter.

Re: I was right about ATProto key management

#40

Post by echelon »

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.

This is one of the most interesting properties of peer-to-peer networks.

You can run your own ingestion algorithms, and one of the things you can do is set up inbound rules that incorporate micro transactions.

We have to build a lot of infrastructure to make this work, but it seems ideal for a world full of agents and autonomous systems acting on our behalf.

Post reply on HN