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

131–140 of 243 posts

Re: A Social Filesystem

#131

Post by dharmatech »

dharmatech wrote: post #128
theturtletalks wrote: post #84

POSSE and AT Protocol can be understood as interoperable marketplaces. Platforms like Reddit and Instagram already function this way: the product is user content, the payment is attention, and the platform’s cut is ads or behavioral data. Dan argues that this structure is not inevitable. If social data is treated as something people own and store themselves, applications stop being the owners of social graphs and bec…

Was going to ask this but then I found openship in your profile. Will check it out. Thanks!

This is a nice introduction:

https://openship.org/about

Re: A Social Filesystem

#132

Post by skybrian »

extraduder_ire wrote: post #126
skybrian wrote: post #109

Earlier quoted context omitted.

Are these just guidelines or is this enforced in some way? I guess readers could validate and skip anything that doesn't match their schema.

Most apps reading records will validate a record against the schema for that type. e.g. there's nothing stopping you from making a app.bsky.feed.post record with more than 300 graphemes in the "text" field, but that post won't appear in the "official" app/website because it fails schema validation. Similarly, there's nothing stopping you from adding another field in your post. It'll just get ignored because the app y…

I'm tempted to make an alternative app that shows only posts with more than 300 characters. :-)

Re: A Social Filesystem

#133

Post by bigyabai »

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…

I think that's an overly charitable take. Giving Google/MSFT/OpenAI/Anthropic what they want does not guarantee a return on dividends. Standards are nice, but Apple is a giant testament to the fact that all the standards in the world won't move an adequately entrenched business.

Re: A Social Filesystem

#134

Post by ximeng »

verdverm wrote: post #104
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…

Private data will come to ATProto, it's not a finished protocol

What’s the plan for this? Sharing with a specific group (DM, group chat, feeds from people you follow) are critical to social media.

Re: A Social Filesystem

#135

Post by danabramov »

dameis wrote: post #124
danabramov wrote: post #119

Earlier quoted context omitted.

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

I think part of the issue is that humans are hyper conditioned to expect a certain UX and set of conditions thanks to the past 3 decades of the internet + legacy social media. It only feels weird that you could publish content on Bluesky and have it show up on some other app without your consent because of how we've been conditioned. There will be a lot of unconditioning and reconditioning that has to take place over…

FWIW, I think Anisota is a bit different because conceptually people see it as a Bluesky client. So it is expected that you're "projecting" Bluesky, for better or worse. Whereas if it's some fanart exchange service or something, maybe it makes less sense. Maybe it just depends on what you think the user would expect.

Re: A Social Filesystem

#136

Post by echoangle »

Is there anything stopping me from backdating my own records? Since the createdAt is just an arbitrary field, I can just write whatever I want in there, right? Is there a way for the viewing application to verify when the record was created (and not modified since), maybe by looking at the mentioned signing?

Re: A Social Filesystem

#137

Post by sroerick »

Interesting - I just spent all day on this on an app which I'm using. My architecture is a little different (probably worse).

The app lives on a single OpenBSD server. All user data is stored in /srv/app/[user]. Authentication is done by accessing OpenBSD Auth helper functions.

Users can access their data through the UI normally. Or they can use a web based filesystem browser to edit their data files. Or, alternately, they can ssh into the server and have full access to their files with all the advantages this entails. Hopefully, this raises the ceiling a bit for what power users of the system can accomplish.

I wanted to unify the OS ecosystem and the web app ecosystem and play around with the idea of what happens if those things aren't separate. I'm sure I'm introducing all kinds of security concerns which I'm not currently aware of.

Another commenter brought up Perkeep, which I think is very interesting. Even though I love Plan 9 conceptually, I do sort of wonder if "everything is a file" was a bit of a wrong turn. If I had my druthers, I think building on top of an OS which had DB and blob storage as the primary concept would be interesting and perhaps better.

If anybody cares, it's POOh stack, Postgres, OCAML, OpenBSD, AND htmx

Re: A Social Filesystem

#138

Post by danabramov »

zahlman wrote: post #117
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.

I think it's on open social apps to show that they're actually meaningfully better products, and that is possible because they're open. With luck, this may lead to an ecosystem where it's worth staying compatible and interoperable, and where users scoff if someone is trying to break it, and where users have an easy way to walk away. I know this sounds super idealistic but this did essentially happen with open source over a long time. At some point, people were just as skeptical of open source as we might be about open social.

Re: A Social Filesystem

#139

Post by danabramov »

echoangle wrote: post #136

Is there anything stopping me from backdating my own records? Since the createdAt is just an arbitrary field, I can just write whatever I want in there, right? Is there a way for the viewing application to verify when the record was created (and not modified since), maybe by looking at the mentioned signing?

You can indeed backdate records. Since the application knows when it has first seen (i.e. indexed) your record, it can decide what to do with that information. If there's a difference, the Bluesky app, for example, shows its own indexing time, but also shows a separate panel saying the post is backdated to some other date. Other apps could choose to show something else.

It is possible to create links asserting a specific version by making a "strong ref" which includes content hash.

Post reply on HN