Live data from Hacker News

A Social Filesystem

overreacted.io

211–220 of 243 posts

Re: A Social Filesystem

#211
post #159

Earlier quoted context omitted.

yeah, I was one of them. developers are not the endgame, though. true social media needs people who are not going to do anything more complicated than "go to website, sign up". there's no world where setting up your own pds is that simple without an organized piece of software to do that kind of thing. personally, I could probably get behind recommending something like umbrel[0], if it included something like a "incl…

and you expect these “go to website, sign up” people to take the extra step to select a provider for repoing data? these people can barely pick a mastodon instance, what sort of data ownership integration work do you expect? it’s a consideration that’s more niche than the current status quo. unless you’re fine with people defaulting to onedrive or similar.

no, I expect them to go to a store to buy the same product that their friend bought. then I expect them to use that product by scanning a QR code that comes up on their TV, and then registering an account using the site linked by that code (or, just using their tv's remote to sign up, with an on-screen keyboard, or whatever).

not "a server so simple, anyone could host it"; "a set top box that gives me a private social media storage, network data storage, secure external connections, and effortless integration with all of my other iot devices". note that the former requires you to know what hosting is, while the latter only requires that you know what you want to do, without having to understand the details of how its done.

Re: A Social Filesystem

#212

Earlier quoted context omitted.

Well, this doesn't prevent the "flagship" app from shipping things and doesn't slow it down. So it's at least not slowing down development which is the argument the parent post was making. I've actually observed the exact opposite thing. Since Bluesky is open source, it's often visible when developers start working on a feature. And they often check in lexicon changes early on. As a result, there's been a few cases w…

Moxie's argument is that even if something has a flagship app, this doesn't help because if you use a new feature and then your friend complains that they can't see what you posted, the experience is just that the flagship app itself is broken. People don't experience this as, oh well, my friend should just have picked a better client. They experience it as, that's annoying, the video feature doesn't work reliably on…

There is always one party "in control" of the lexicon and its canonical version.

I think it's important to distinguish this from the "every client adds their own features" thing. Technically yes, each app can add their own things to the open union that they support better. But it's also on each implementer's to consider how this would affect UX in other clients (e.g. if you add your own embed type, it seems reasonable to also prepopulate a link embed that acts as fallback). The problems you're describing are real, but I think we should give a bit more credit to the app builders since they're also aware that this is a part of their user experience design.

But still, whoever "owns" the lexicon says what's canonical. Then yes, some other software might not catch up to what's canonical but that's similar to what's happening with any platform that supports multiple clients today. Unless your outlook is that alternative clients in general are not competitive for this reason. I think that's a grim outlook, and if that were true, services wouldn't go to extra lengths to intentionally shut down their APIs, which so has been the trend with every network.

I think in longer term the bet is that the benefits unlocked by interop and a more competitive product landscape will become clearer to end users, who will be less interested in joining closed platforms and will develop some intuitions around that. This would not happen soon, so until then, the bet is that interop will allow creating better products. And if that doesn't happen, yes, it's pretty hard for open to compete.

Re: A Social Filesystem

#213
post #207
post #186

Earlier quoted context omitted.

That's great, but also Mastodon is just there and has been for quite some time. I see no added value in Bluesky/ATProto beyond the layer of that "social as a service" which looks like a walled garden / app store of sorts in the making. I may be wrong, of course...

I never managed to get into mastodon because mastodon isn't a single space. It's a bunch of separate, linked spaces. Which server you're on matters a lot, and I never found one that really had the vibe I was looking for. Bluesky, though, is one big pool. There's no seam between servers. The experience is much nicer. Also, bluesky caught on among my peers in a way that mastodon never did, which was always going to be…

> There's no seam between servers.

This is false, if we're to believe it's possible to exist outside the moderation control of Bluesky corp.

It's also false today while everyone is still on the same "instance" - e.g. ICE joining Bluesky and being verified is making waves... apparently being _that_ is not enough to violate Big Blue's community guidelines.

Re: A Social Filesystem

#214

Earlier quoted context omitted.

Moxie's argument is that even if something has a flagship app, this doesn't help because if you use a new feature and then your friend complains that they can't see what you posted, the experience is just that the flagship app itself is broken. People don't experience this as, oh well, my friend should just have picked a better client. They experience it as, that's annoying, the video feature doesn't work reliably on…

There is always one party "in control" of the lexicon and its canonical version. I think it's important to distinguish this from the "every client adds their own features" thing. Technically yes, each app can add their own things to the open union that they support better. But it's also on each implementer's to consider how this would affect UX in other clients (e.g. if you add your own embed type, it seems reasonabl…

Well, I never personally formed a strong opinion on Moxie's take, although I do understand it. Basically yes his outlook is that any service that doesn't actively ban alternative clients will be outcompeted by those that do.

The reason is that if alt clients are possible then some fraction of the userbase will adopt them. And if some users adopt them that means the experience of other users of the service gets worse, because new features become unreliable and flaky. You think you understand what another person sees and can do, but you don't, and this leads to poor experiences.

Viewed another way the client is an integrated part of the platform and not something that you can enable users to change freely, any more than they could be allowed to change the servers freely. We don't allow the latter because users would do things that broke the service, and so it is also for the former.

Empirically Moxie seems to be correct. Of the 90s era open protocols the only ones that survive are the web and email. The web survives but it's never been truly open in an extension sense - the definition of HTML has always been whatever the dominant browser of the era accepts, and this has become moreso over the time not less. There are no more plugin APIs for instance. SMTP survives, barely, because it's the foundation of internet identity. But many people even in corporate contexts now never send an email. It's all migrated to Slack or Teams. And if you look carefully at the Slack API it's not possible to make a truly complete alternative client with it, the API is only intended for writing bots.

This is grim but I'm not sure it's false and I'm not sure it can be changed. Also, Moxie's essay ends on a positive note. He observes that competition between mobile social networks does still work well despite the lack of federation, because they coalesced around using the user's phone number as identity and address book as the friends list, so you can in fact port your social network to a different network just by signing up. The notification center in the OS provides the final piece of the puzzle, acting as a unified inbox that abstracts the underlying social network.

This is rather mobile specific but seems basically correct to me. So that suggests the key pillar isn't file formats or protocols but ownable identity. It works because telcos do the hard work of issuing portable identities and helping people keep them, and ownership can be swiftly verified over the internet.

Re: A Social Filesystem

#215
post #188

> Identity -- This is a difficult problem. My hope is that in 5 years, I will not have anything in my feeds that have not been signed in a way that I can assign a trust level. Here in the Nordics, we are already seeing messaging apps such as [hudd] that require government issued ID to sign in. I want this to spread to everything from podcasts and old-school journalism to the soccer-club newsletter, so that I can alwa…

So you're simply not interested in reading any random website by random people who don't see a benefit of establishing any form of trust, especially if should not be connected to their official government IDs? Or to put it differently: Where should this come from, and which issuer would you trust? And why should anyone else agree with you that this is good?

Trust is subjective! Let's establish trust in each other rather than rely on one-size-fits-all solutions.

Personally, I trust my friends, family, and some public figures and institutions to varying degrees. I want to see social experiences that reflect that.

Re: A Social Filesystem

#216

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 ( h…

I'm saying it would be a lot simpler to just provide an API to download the data. I don't think it's worth the complexity and network of PDS' to preserve this data in perpetuity, but even if I did, nothing would stop me from using the download API and storing tapes in Iron Mountain or whatever.

I think there's also weird cases where you don't really want things replicated: revenge porn, snuff, CSAM, etc. Like, if someone we're like "yes it's true we lose all data forever if we shut down, but we're not indiscriminately pushing some of the worst content to everyone replicating" I'd take that tradeoff immediately.

Re: A Social Filesystem

#217

Earlier quoted context omitted.

Is it really so different in the service context? You could also reverse engineer the HTTP endpoints and formats used by Word Online to export data from the service. It doesn't feel all that different, except perhaps that the online service can try to detect your custom tooling and block you, whereas with static data that isn't possible. But other than that admittedly real extra problem, the bulk of the work would st…

Hmm, Word Online isn't what the article is about. I'm not sure if you've read the article, but it is about social apps — like Tumblr, Reddit, HN itself, etc. I'm using file formats as a metaphor to explain how apps built on AT protocol work (lexicons are like "social file formats"), and what this way of building enables (interoperability between social apps by default).

I did read it. I think myself and other people are getting tripped up by the title and the filesystem-oriented argument. The article opens with an icon of a .doc file, so it's natural to think about MS Word, which these days is a social app via its collaboration features.

Re: A Social Filesystem

#218

Earlier quoted context omitted.

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

We can have both a directory and use content addressable storage and give people the option of using their own keypairs. They are not mutually exclusive. Bluesky chooses to have a central directory and index.

what would you do about the at-uri?

Re: A Social Filesystem

#219

Earlier quoted context omitted.

We can have both a directory and use content addressable storage and give people the option of using their own keypairs. They are not mutually exclusive. Bluesky chooses to have a central directory and index.

what would you do about the at-uri?

at://hash at://pub i guess I don't know why we need at:// that seems like something we'd need in Beaker Browser.

After reading the docs at https://atproto.com/specs/at-uri-scheme and building applications that integrate with the Bluesky API, it’s clear why this format is useful for interacting with their system. For developers working outside the ATMosphere, however, it may feel less familiar compared to more conventional REST API patterns.

Re: A Social Filesystem

#220
post #101

Earlier quoted context omitted.

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?

I think there's a massive difference between "some might be capturing" and "reliable, e.g. hashed records"

Again, there may be some VALUE in the fact that "some might be capturing" WOULD BE inherently unreliable. The ability to "muddy the record" could make some SAFER.

Post reply on HN