Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Social Filesystem

overreacted.io

Post reply on HN
Print view View original

61–70 of 243 posts

Re: A Social Filesystem

#61

Post by Spivak »

case0x wrote: post #26
jrm4 wrote: post #22

The more I read and consider Bluesky and this protocol, the more pointless -- and perhaps DANGEROUS -- I find the idea. It really feels like no one is addressing the elephant in the room of; okay, someone who makes something like this is interested in "decentralized" or otherwise bottom-up ish levels of control. Good goal. But then, when you build something like this, you're actually helping build a perfect decentral…

>helping build a perfect decentralized surveillance record a record of what? Posts I wish to share with the public anyway?

It's not about the access, it's about the completeness. Imagine this paradigm takes off (I hope it does!), everyone has their own PDS and finally owns their data. Social apps link into their PDS to publish and share data exactly as they're supposed to.

Well now someone's PDS is a truly complete record of their social activity neatly organized for anyone that's interested. It's not a security issue, after all the data was still public before, but the barrier to entry is now zero. It's so low that you can just go to stalker.io, put in their handle, and it will analyze their profile and will print out a scary accurate timeline of their activity and location leveraging AI's geoguesser skill.

Re: A Social Filesystem

#62

Post by dameis »

Spivak wrote: post #61
case0x wrote: post #26

Earlier quoted context omitted.

>helping build a perfect decentralized surveillance record a record of what? Posts I wish to share with the public anyway?

It's not about the access, it's about the completeness. Imagine this paradigm takes off (I hope it does!), everyone has their own PDS and finally owns their data. Social apps link into their PDS to publish and share data exactly as they're supposed to. Well now someone's PDS is a truly complete record of their social activity neatly organized for anyone that's interested. It's not a security issue, after all the data…

That is how it works, but people shouldn't be posting their location or sensitive information publicly if they don't want it exposed like that. That's basic opsec. Private data is currently being worked on for ATProto and will hopefully begin existing in 2026.

Re: A Social Filesystem

#63

Post by skeledrew »

jrm4 wrote: post #22

The more I read and consider Bluesky and this protocol, the more pointless -- and perhaps DANGEROUS -- I find the idea. It really feels like no one is addressing the elephant in the room of; okay, someone who makes something like this is interested in "decentralized" or otherwise bottom-up ish levels of control. Good goal. But then, when you build something like this, you're actually helping build a perfect decentral…

When it comes to the internet, tech is law. There is no way to publicly share something and maintain control over it. Even on the Fediverse, if either a client or server wants to ignore part of the protocol or model, it can. Like a system message to delete particular posts for anti-surveillance reasons can simply be ignored by any servers or clients that were designed/modified for surveillance. Ultimately the buck lies with the owner of some given data to not share that data in the first place if there's a chance of misuse.

Re: A Social Filesystem

#64

Post by yladiz »

I know this is somewhat covered in another comment, but, the concepts described in the post could have been reduced quite a bit, no offense Dan. While I like the writing generally, I would consider writing and then letting it sit for a few days, rereading, and then cutting chaff (editing). This feels like a great first draft but without feedback, and could have greatly benefited from an editing process, and I think using the argument that you want to put out something for others to take and refine isn’t really a strong one… a bit more time and refinement could have made a big difference here (and given you have a decently sized audience I would keep in mind).

Re: A Social Filesystem

#65

Post by danabramov »

skeledrew wrote: post #56

I've been thinking of this for some time, conceptually, but perhaps from a more fundamental angle. I think the idea of "files" is pretty dated and can be thrown out. Treat everything as data blobs (inspired by PerKeep[0]) addressed by their hashes and many of the issues described in the article just aren't even a thing. If it really makes sense, or for compatibility sake, relevant blobs can be exposed through a files…

I'm using filesystem more as a metaphor than literally.

I picked this metaphor because "apps" are many-to-many to "file formats". I found "file format" to be a very powerful analogy for lexicons so I kind of built everything else in the explanation around that.

You can read https://atproto.com/specs/repository for more technical details about the repository data structure:

The repository data structure is content-addressed (a Merkle-tree), and every mutation of repository contents (eg, addition, removal, and updates to records) results in a new commit data hash value (CID). Commits are cryptographically signed, with rotatable signing keys, which allows recursive validation of content as a whole or in part. Repositories and their contents are canonically stored in binary DAG-CBOR format, as a graph of data objects referencing each other by content hash (CID Links). Large binary blobs are not stored directly in repositories, though they are referenced by hash (CID).

Re: apps, I'd say AT is actually post-app to some extent because Lexicons aren't 1:1 to apps. You can share Lexicons between apps and I totally can see a future where the boundaries are blurring and it's something closer to what you're describing.

Re: A Social Filesystem

#66

Post by jrowen »

jrv wrote: post #51
motoxpro wrote: post #40

I've always thought walled gardens are the effect of consumer preferences, not the cause. The effect of the internet (everything open to everyone) was to create smaller pockets around a specific idea or culture. Just like you have group chats with different people, thats what IG and Snap are. Segmentation all the way down. I am so happy that my IG posts arent available on my HN or that my IG posts arent being easily…

> I think I don't really understand the benefit of data portability in the situation. Twitter was my home on the web for almost 15 years when it got taken over by a ... - well you know the story. At the time I wished I could have taken my identity, my posts, my likes, and my entire social graph over to a compatible app that was run by decent people. Instead, I had to start completely new. But with ATProto, you can do…

But what if your entire social graph didn't choose to transfer over as well? What if they don't want to be on that app? What if someone that was very indecent made a compatible app? Would you want your entire Twitter history represented on there?

For better or worse, I don't think it makes sense to decentralize social. The network of each platform is inherently imbued with the characteristics and culture of that platform.

And I feel like Twitter is the anomalous poster child for this entire line of thinking. Pour one out, let it go, move on, but I don't think creating generalized standards for social media data is the answer. I don't want 7 competing Twitter-like clones for different political ideologies that all replicate each others' data with different opt-in/opt-out semantics. That sounds like hell.

Re: A Social Filesystem

#67

Post by danabramov »

jrowen wrote: post #57
motoxpro wrote: post #40

I've always thought walled gardens are the effect of consumer preferences, not the cause. The effect of the internet (everything open to everyone) was to create smaller pockets around a specific idea or culture. Just like you have group chats with different people, thats what IG and Snap are. Segmentation all the way down. I am so happy that my IG posts arent available on my HN or that my IG posts arent being easily…

I agree. I don't understand the driving force here. I have all of the raw image files that I've uploaded to Instagram. I can screenshot or download the versions that I created in their editor. Likewise for any text I've published anywhere. I prefer this arrangement, where I have the raw data in my personal filesystem and I (to an extent) choose which projections of it are published where on the internet. An IG follow…

For me, part of it is that we have no power collectively against products turning their back on users because coordination to "export data all at once and then import it into specific other place" is near-impossible. So this creates a perverse cycle where once you capture enough of the market, competition has very little chance unless they change the category entirely.

What AT enables is forking products with their data and users. So, if some product is going down a bad road, a motivated team can fork it with existing content, and you can just start using the new thing while staying interoperable with the old thing. I think this makes the landscape a lot more competitive. I wrote about this in detail in https://overreacted.io/open-social/#closed-social which is another longread but specifically gets into this problem.

I hear you re: not wanting "weird aggregation", that just be a matter of taste. I kind of feel like if I'm posting something on the internet, I might as well have it on the open web as aggregatable by other apps.

Re: A Social Filesystem

#68

Post by dameis »

jrowen wrote: post #66
jrv wrote: post #51

Earlier quoted context omitted.

> I think I don't really understand the benefit of data portability in the situation. Twitter was my home on the web for almost 15 years when it got taken over by a ... - well you know the story. At the time I wished I could have taken my identity, my posts, my likes, and my entire social graph over to a compatible app that was run by decent people. Instead, I had to start completely new. But with ATProto, you can do…

But what if your entire social graph didn't choose to transfer over as well? What if they don't want to be on that app? What if someone that was very indecent made a compatible app? Would you want your entire Twitter history represented on there? For better or worse, I don't think it makes sense to decentralize social. The network of each platform is inherently imbued with the characteristics and culture of that plat…

The framing of "portability" is a bit confusing. Your data is not actually "transferring" anywhere, it's always in your PDS. These other apps and clients are just frontends that are displaying the data that is in your PDS. The data is public and open, though private data is in the works and hopefully will arrive in 2026.

Re: A Social Filesystem

#69

Post by geokon »

danabramov wrote: post #58
geokon wrote: post #53

Earlier quoted context omitted.

Sure, you'd have something like: {:record {:person-key **public-key** :type :twitter-post :message "My friend {:person-key **danabramov-public-key**} suggested I make this on this HN post {:link **record-of-hn-post-hash**}. Look at his latest post {:link **danabramov-newtwitter-post-hash** :person-key **danabramov-public-key**} it's very cool!"} :hash **hash-of-the-record** :signature **signature-by-author**} So ever…

I have a few questions: - How do you rotate keys? In AT, the user updates the identity document. That doesn't break their old identity or links. - When you have a link, how do you find its content? In AT, the URL has identity, which resolves to hosting, which you can ask for stuff. - When aggregating, how do you find all records an application can understand? E.g. how would Bluesky keep track of "Bluesky posts". Does…

1. It's an important problem, but I think this just isn't done at the Record layer. Nor can you? You'd probably want to do that on the person-key->username service (which would have some log-in and way to tie two keys to one username)

2. In a sense that's also not something you think about at the Record level either. It'd be at a different layer of the stack. I'll be honest, I haven't wrapped my head entirely around `did:plc`, but I don't see why you couldn't have essentially the same behavior, but instead of having these unique DID IDs, you'd just use public keys here. pub-key -> DID magic stuff.. and then the rest you can do the same as AT. Or more simply, the server that finds the hashed content uses attached meta-data (like the author) to narrow the search

Maybe there is a good reason the identity `did:plc` layer needs to be baked in to the Record, but I didn't catch it from the post. I'd be curious to here why you feel it needs to be there?

3. I'm not 100% sure I understand the challenge here. If you have a soup of records, you can filter your records based on the type. You can validate them as they arrive. You send your records to the Bluesky server and they validates them as they arrive.

Re: A Social Filesystem

#70

Post by heyitsaamir »

nonethewiser wrote: post #34

But how do you get people to actually want this? This stuff is pretty niche even within tech.

I think most people do want this. They want to own their data. If you ask someone if they post on IG, if they should own that, or IG, they'll tell you it's them.

The hard problem IMO is how do you incentivize companies from adopting this since walled gardens helps reduce competition.

Post reply on HN