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

111–120 of 243 posts

Re: A Social Filesystem

#111

Post by pcthrowaway »

danabramov wrote: post #71
yladiz wrote: post #64

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

From my perspective, there is no chaff. I've already the read the entire thing from top to bottom over 20 times (as I usually do with my writing), I've done several full edit passes, and I've removed everything inessential that I could find. The rest is what I wanted to be included into this article. I know my style is verbose but I try to include enough details to substantiate the argument at the level that I feel c…

For the commenters who have made similar comments, I'd be curious to hear what they think could be cut. I suspect different readers will have different opinions on this, which means it's probably a good thing you didn't make cuts.

Re: A Social Filesystem

#112

Post by danabramov »

camgunz wrote: post #108

I'm skeptical of these kind of like, self-describing data models. Like, I generally like at proto--because I like IPFS--but I think the whole "just add a lexicon for your service and bickety bam, clients appear" is a leap too far. For example, gaze upon dev.ocbwoy3.crack.defs [0] and dev.ocbwoy3.crack.alterego [1]. If you wanted to construct a UI around these, realistically you're gonna need to know wtf you're buildi…

Not sure I fully get you... In your example, isn't the problem that nobody cares about this data? So there is no motivation to build a client. Whereas if these were beloved notes or minisites or whatever that got wiped out by the latest acquisition (e.g. see https://bento.me/ shutting down), people would know exactly what those are, and there would be incentive for someone to compete for the userbase.

E.g. Blento (https://blento.app/) is atproto Bento that I only saw a couple of days ago. But the cool thing is that if it shuts down, not only someone else can set it up again (it's open source), but they're also gonna be able to render all of the users' existing content. I think that's a meaningful step forward for this use case.

Yes, there's gonna be tons of stuff on the network that's too niche, but then there's no harm in it either. Whereas wherever there is enough interest, someone can step in and provide the code for the data.

Re: A Social Filesystem

#113

Post by danabramov »

swyx wrote: post #110
skybrian wrote: post #13

This article goes into a lot of detail, more than is really needed to get the point across. Much of that could have been moved to an appendix? But it's a great metaphor. Someone should write a user-friendly file browser for PDS's so you can see it for yourself. I'll add that, like a web server that's just serving up static files, a Bluesky PDS is a public filesystem. Furthermore it's designed to be replicated, like a…

> So, much like with a public git repo, you should be comfortable with the fact that anything you put there is public and will get indexed. whats the sota on atproto encryption dan? just publish encrypted stuff with sha 256 and thats it?

AFAIK nothing special for it at this point, so whatever you would do with a public cleartext broadcasting platform.

Re: A Social Filesystem

#114

Post by danabramov »

itmitica wrote: post #105

To share is to lose control. You can't undo, even once shared, it can't be undone. You can't retract a published novel. You can't retract a broadcast music or show. What makes you think you can do it over internet?

I don't think my article makes any claims that one can undo sharing. What I'm saying is that we benefit collectively from being able to untether data from applications. It's the same logic as https://stephango.com/file-over-app but applied to the aggregating web applications.

Re: A Social Filesystem

#115

Post by jrowen »

danabramov wrote: post #67
jrowen wrote: post #57

Earlier quoted context omitted.

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

Thanks for your thoughts. I do feel like this is all very specifically connected to Twitter. Which tech people really adopted, but I never used much, so it is interesting that these different perspectives are somewhat tied to one's megaplatform(s) of choice. I don't know of another social network that has inspired such a consistent effort to be forked or cloned. I do kind of feel like "change the category" and create a new network with the traits you want to see is the right move.

For better or worse, Twitter built their network. That many people willingly signed up and posted and continue to post there. I don't think anyone really should be able to fork it, because the users didn't collectively agree to that, and they don't all agree on what a good road or a bad road is. Ultimately, they can choose to leave if and when they want. Are these networks rather sticky, yes of course, but that's life.

We've seen lots of social networks come and go, things do change over time, there's ample opportunity for new ideas to flourish. In that sense, AT is perfectly welcome to throw their hat in the ring and see if that resonates and sticks. If people want their social network to be forkable, that concept will succeed.

I do think it misses what a lot of people find valuable about the tangibility and constraints of "I am making this content specifically for this platform and this audience at this point in time." I don't think most people think of their social media posts as a body of work that they want to maintain and carry over in an abstract sense independent of platform, and give open license to anyone to cook up into whatever form they can dream of.

Re: A Social Filesystem

#116

Post by pcthrowaway »

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…

In theory it should be possible to allow users to upload ciphertext that they can then share a decryption key with their intended audience. I believe atproto has dissuaded against this with the argument that ciphertext shouldn't be in public view, but this seems to hinge on the idea that the cipher is insecure, or will be in the future. I don't see why using a post-quantum encryption scheme shouldn't provide the appropriate security, which may still not be foolproof, but it certainly would make indexing the data much more difficult

Re: A Social Filesystem

#117

Post by zahlman »

swyx wrote: post #92

> Apps may come and go, but files stay—at least, as long as our apps think in files. yes: https://www.swyx.io/data-outlasts-code-but all lasting work is done in files/data (can be parsed permissionlessly, still useful if partially corrupted), but economic incentives keep pushing us to keep things in code (brittle, dies basically when one of maintainer|buildtools|hardware substrate dies). when standards emerge (forcin…

Indeed. My first reaction was:

> Files are the source of truth—the apps would reflect whatever’s in your folder.

Now that the "app" is a web site that supports itself with advertising revenue, it has no incentive whatsoever to work this way.

Re: A Social Filesystem

#118

Post by zahlman »

christophilus wrote: post #102

I’ve been reading “The Unix Programming Environment”. It’s made me realize how much can be accomplished with a few basic tools and files (mostly plain text). I want to spend some time thinking of what a modern equivalent would look like. For example, what would Slack look like if it was file (and text) oriented and UNIXy? Well, UNIX had a primitive live chat in the form of live inter-user messaging. I’d love to see a…

Unix gave the world a lot of good ideas about architecture, but I think it really hamstrung itself by treating all the data as plain text and resisting the idea of having any kind of structured, formatted data passed within a pipeline. It's nice to be able to serialize to something human-readable and -editable, but constantly re-parsing and re-formatting it becomes a real pain.

Re: A Social Filesystem

#119

Post by danabramov »

jrowen wrote: post #95
dameis wrote: post #68

Earlier quoted context omitted.

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.

The data is not transferring, but the user is. When I sign up for e.g. Twitter, I don't want to sign up for Mastodon, or Bluesky, or Truth Social, or whatever other platform someone might create later. Thus I would not choose to put my data in a PDS. I feel like that would actually leave me with less ownership and control than I have now. My point is that I don't believe the separation of frontend and data is desirab…

Do I understand correctly that your main concern is that some random service would serve a page when asked for /your-handle, and so, given a link, someone may assume that you actively use that service? Just trying to understand the exact scenario.

Generally it's good practice for AT apps to treat you as not signed up if you have not explicitly signed up to this app before. So I think a well-behaved site you never used shouldn't show your profile page on request. If this is right, maybe it needs to be more emphasized in docs, templates, etc. Same as they should correctly handle lifecycle events like account getting deactivated.

Realistically it's possible some services don't do this well but it's not clear to me that this is going to be a major problem. Like if it gets really bad, it seems like either this will get fixed or people will adjust expectations about how profile pages work.

Re: A Social Filesystem

#120

Post by ninkendo »

danabramov wrote: post #100
ninkendo wrote: post #94

Earlier quoted context omitted.

> Do you have a more pointed criticism? Sure. After taking the time to re-read the article since I initial posted my (admittedly shallow) dismissal, I realized this article is really a primer/explainer for the AT protocol, which I don't really have enough background in to criticize. My criticism is more about the usefulness of saying "what if we treated social networking as a filesystem": which is that this doesn't a…

I think there was a bit of a communication failure between us. You took the article as a random "what if X was Y" exploration. However, what I tried to communicate something more like: 1. File-first paradigm has some valuable properties. One property is apps can't lock data out of each other. So the user can always change which apps they use. 2. Web social app paradigm doesn't have these properties. And we observe th…

The problems with social media are not at all the fact that things are “locked up in apps”.

Again, you missed my point. Data sharing is the least interesting thing imaginable, has already been solved countless times, and is not the reason social media sinks or swims.

Social media sinks or swims based on one thing and one thing only: is it enjoyable to use. Are all the people on here assholes or do they have something interesting to say? Can I post something without being overrun by trolls? How good are the moderation standards? How do I know if the people posting aren’t just AI bots? What are the community standards? In short: what kind of interactions can I expect to have on the platform?

The astronaut types look at the abysmal landscape social media has become, and think “you know what the fundamental problem is? That all this is locked up in apps! Let’s make a protocol, that’ll fix it!”

Never mind that the profit seeking platforms have zero interest in opening up their API to competing sites. Never mind that any of the sites that are interested in openness/federating all univerally have no answer to the problem of how you address content moderation, or at least nothing that’s any different from what we’ve seen before.

The problem in social media is not that things are locked up behind an app. There are apps/readers that combine multiple platforms for me (I remember apps that consolidated Facebook and twitter fully eighteen years ago. It’s not hard.)

The problem with social media is that it’s a wasteland full of bots and assholes.

A HN poster said it best 8 years ago about twitter, and I think it applies to all of social media: it’s a planetary scale hate machine: https://news.ycombinator.com/item?id=16501147

Post reply on HN