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

71–80 of 243 posts

Re: A Social Filesystem

#71

Post by danabramov »

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 confident it fully stands for itself. If others find something useful in it, I trust that they can riff on those bits or simplify.

Re: A Social Filesystem

#72

Post by danabramov »

James_K wrote: post #59

AT Proto seems very overengineered. We already have websites with RSS feeds, which more or less covers the publishing end in a way far more distributed and reliable than what AT offers. Then all you need is a kind of indexer to provide people with notifications and discovery and you're done. But I suppose you can't sell that to shareholders because real decentralised technology probably isn't going to turn as much of…

Why so much cynicism? The people working there genuinely care about this stuff. Maybe you disagree with technical decisions but why start by projecting your fantasies about their motivations?

RSS is OK for what it does, but it isn't realtime, isn't signed, and doesn't support arbitrary structured data. Whereas AT is signed, works with any application-defined data structures, and lets you aggregate over millions of users in real time with subsecond end-to-end latency.

Re: A Social Filesystem

#73

Post by danabramov »

EGreg wrote: post #60

As someone who explicitly designed social protocols since 2011, who met Tim Berners-Lee and his team when they were building SOLID (before he left MIT and got funded to turn it into a for-profit Inrupt) I can tell you that files are NOT the best approach. (And neither is SPARQL by the way, Tim :) SOLID was publishing ACLs for example as web resources. Presumably you’d manage all this with CalDAV-type semantics. But o…

To be clear, I'm using files in a relatively loose sense to focus on the "apps : formats are many-to-many" angle. AT does not literally implement a full filesystem. As the article progresses, I restrict some freedoms in the metaphor (no directories except collections, everything is JSON, etc). If you're interested in the actual low-level repository format, it is described here: https://atproto.com/specs/repository

Re: A Social Filesystem

#74

Post by ahussain »

It seems like the biggest downside of this world is iteration speed.

If the AT instagram wants to add a new feature (i.e posts now support video!) then can they easily update their "file format"? How do they update it in a way that is compatible with every other company who depends on the same format, without the underlying record becoming a mess?

Re: A Social Filesystem

#75

Post by harvey9 »

dameis wrote: post #68
jrowen wrote: post #66

Earlier quoted context omitted.

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.

This sounds like I need to host my PDS. Easy for me with no public profile but if I was someone famous wouldn't that mean I needed enterprise class hosting?

Re: A Social Filesystem

#76

Post by __MatrixMan__ »

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…

If that's your threat model, then I think the way forward is to maintain separate identities. There are trade-offs there also of course: fragment yourself too much and the people who trust you will now only trust a portion of what you have to say... unless you have the time and energy to rebuild that trust multiple times.

Of course that's the same with the web we have today, the only difference is that you get control over which data goes with which identity rather than having that decision made for you by the platform boundaries.

Re: A Social Filesystem

#77

Post by dzaima »

dameis wrote: post #62
Spivak wrote: post #61

Earlier quoted context omitted.

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.

> people shouldn't be posting their location or sensitive information publicly if they don't want it exposed like that

They shouldn't, but they still could: accidentally paste in the wrong browser tab; have been stupid when they were 12 years old; have gotten drunk; or a number of other things.

Re: A Social Filesystem

#78

Post by danabramov »

ahussain wrote: post #74

It seems like the biggest downside of this world is iteration speed. If the AT instagram wants to add a new feature (i.e posts now support video!) then can they easily update their "file format"? How do they update it in a way that is compatible with every other company who depends on the same format, without the underlying record becoming a mess?

That's a great question!

Adding new features is usually not a problem because you can always add optional fields and extend open unions. So, you just change `media: Link | Picture | unknown` to `media: Link | Picture | Video | unknown`.

You can't remove things true, so records do get some deprecated fields.

Re: updating safely, the rule is that you can't change which records it would consider valid after it gets used in the wild. So you can't change whether some field is optional or required, you can only add new optional fields. The https://github.com/bluesky-social/goat tool has a linting command that instantly checks whether your changes pass the rules. In general it would be nice if lexicon tooling matures a bit, but I think with time it should get really good because there's explicit information the tooling can use.

If you have to make a breaking change, you can make a new Lexicon. It doesn't have to cause tech debt because you can make all your code deal with a new version, and convert it during ingestion.

Re: A Social Filesystem

#79

Post by danabramov »

harvey9 wrote: post #75
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.

This sounds like I need to host my PDS. Easy for me with no public profile but if I was someone famous wouldn't that mean I needed enterprise class hosting?

You don't need to host your own PDS for any of this to work. It works the same way regardless of who hosts your PDS.

I think what may be confusing you is that Bluesky (the company) acts in two different roles. There's hosting (PDS) and there's an app (bsky.app). You can think of these conceptually as two different services or companies.

Yes, when you sign up on Bluesky, you do get "Bluesky hosting" (PDS). But hosting doesn't know anything about apps. It's more like a Git repo under the hood.

Different apps (Bluesky app is one of them) can then aggregate data from your hosting (wherever it is) and show different projections of it.

Finally, no, if you're famous, you don't need enterprise hosting. Hosting a PDS can be extremely cheap (like $1/mo maybe)? PDS doesn't get traffic spikes on viral content because it's amortized by the app (which serves from its DB).

Re: A Social Filesystem

#80

Post by __MatrixMan__ »

heyitsaamir wrote: post #70
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.

We want more control over data that we've created, and more control over data that's about us. I'm not sure either of these concepts align well with "ownership" though. Property and data are concepts that don't mix.

Language nitpicking aside... you subvert the walls of their gardens and aggregate the walled-off data without the walls, so users face a choice not between:

- facebook

- everything else

but instead between

- facebook and everything else

- just facebook

But that approach only works if we can solve the "data I created" problems in a way that doesn't also require us to acknowledges facebook's walls.

Post reply on HN