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

101–110 of 243 posts

Re: A Social Filesystem

#101

Post by jrm4 »

bee_rider wrote: post #24
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…

This seems like tensions between normal/practical and “opsec” style privacy thinking… Really, we can never be sure anything that gets posted on the internet won’t be captured by somebody outside our control. So, if we want to be full paranoid, we should act like it will be. But practically lots of people have spent a long time posting their opinions carelessly on the internet. Just protected by the fact that nobody r…

Your last point is one that I used to be very strongly favor of, and today?

Nooooooooooo. No. No. No.

It's not going to happen and we shouldn't even consider it. Seriously. This thing we are doing here, which is "connecting people to each other," those forces for MANY will be far more powerful than "let me stop and think about the fact that this is forever." I just don't think we are wired for it, we're wired for a world in which we can just talk?

I think it's better to try to engineer some specific counter to "everything is recorded all the time" (or, as in here, not try to usher it into existence even more) than to try to say "welp, everything is recorded all the time, better get used to it."

Re: A Social Filesystem

#102

Post by christophilus »

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 move back to simpler systems that composed well.

Re: A Social Filesystem

#103

Post by bee_rider »

jrm4 wrote: post #101
bee_rider wrote: post #24

Earlier quoted context omitted.

This seems like tensions between normal/practical and “opsec” style privacy thinking… Really, we can never be sure anything that gets posted on the internet won’t be captured by somebody outside our control. So, if we want to be full paranoid, we should act like it will be. But practically lots of people have spent a long time posting their opinions carelessly on the internet. Just protected by the fact that nobody r…

Your last point is one that I used to be very strongly favor of, and today? Nooooooooooo. No. No. No. It's not going to happen and we shouldn't even consider it. Seriously. This thing we are doing here, which is "connecting people to each other," those forces for MANY will be far more powerful than "let me stop and think about the fact that this is forever." I just don't think we are wired for it, we're wired for a w…

It would be nice to engineer a way around this, but I don’t see it. Fundamentally if we want to be able to talk to random people, we’ll have to expect that some might be capturing communications, right?

Re: A Social Filesystem

#104

Post by verdverm »

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

Re: A Social Filesystem

#105

Post by itmitica »

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?

Re: A Social Filesystem

#106

Post by verdverm »

geokon wrote: post #69
danabramov wrote: post #58

Earlier quoted context omitted.

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…

2. The point of the PLC is to avoid tying identity to keys, specifically for the point that if you lose your keys, you lose your identity. In reality, no body wants that as part of the system

3. The soup means you need to index everything. There is no Bluesky server to send things to, only your PDS. Your DID is how I know what PDS to talk to to get your records

Re: A Social Filesystem

#107

Post by verdverm »

dameis wrote: post #46
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 am so happy that my IG posts arent available on my HN or that my IG posts arent being easily cross posted to a service I dont want to use like truth social. ATProto apps don't automatically work like this and don't support all types of "files" by default. The app's creator has to built support for a specific "file type". My app https://anisota.net supports both Bluesky "files" and Leaflet "files", so my users can…

Except that a lot of the app builders in ATProto seem to think the protocol was designed to make their lives easier when bootstrapping their network from Bluesky userbase.

(Imo, that is a perverse interpretation, it's about user choice, which they are effectively taking away from me by auto importing and writing to my Bsky graph)

re: the debates on reusing follows from Bluesky in other apps instead of their own

Re: A Social Filesystem

#108

Post by camgunz »

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 building (it's a twitter/bluesky clone); there simply isn't enough information in the lexicons to do a good job. And the argument can't be "hey you published a lexicon and now people can assume your data validates", because validation isn't done on write, it's done on read. So like, there really is no difference between this and like, looking up the docs on the data format and building a client. There are no additional guarantees.

Maybe there's an argument for moving towards some kind of standardization, but... do we really need that? Like are we plagued by dozens of slightly incompatible scrobbling data models? Even if we are, isn't this the job of like, an NPM library and not a globally replicated database?

Anyway, I appreciate that, facially, at proto is trying to address lock in. That's not easy, and I like their solution. But I don't think that's anywhere near the biggest problem Twitter had. Just scanning the Bluesky subreddit, there's still problems like too much US politics and too many dick pics. It's good to know that some things just never change I guess.

[0]: https://lexicon.garden/lexicon/did:plc:s7cesz7cr6ybltaryy4me...

[1]: https://lexicon.garden/lexicon/did:plc:s7cesz7cr6ybltaryy4me...

Re: A Social Filesystem

#109

Post by skybrian »

danabramov wrote: post #78
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…

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.

Re: A Social Filesystem

#110

Post by swyx »

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?

Post reply on HN