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

231–240 of 243 posts

Re: A Social Filesystem

#231

Post by James_K »

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

RSS is signed because it's served over HTTPS which involves an SSL certificate exchange. It is also real time. You fetch the feed and get the most up to date content on it. You can host any XML document you want on your website and there are W3C recommended standards that allow the integration of rich data structures within web pages.

The sole interesting part of ATProto is the aggregation part, which can also be solved in the same way with existing web technologies, that is a web indexer. Google allows you to set up notifications whenever a link is created to your website, which is essentially the unique offering of AT. None of the ideas it presents are new, but they are all incompatible with existing Web technologies. That is why I dislike it. I already have a website. I already have a set of RSS feeds that I follow. I do not want another website hosted on a strange and convoluted service in a bajillion different JSON records when there is a folder of XML on my computer called “my-website” which I can copy to any server and have all I need. Yet, in the name of a federated internet, the BSky folks have herded people away from the real distributed internet and into a crappy Twitter knockoff. Perhaps there are some business-unaware programmers very passionate about the idea of a distributed web and I commend them for that but it already exists and, in every real aspect, they are harming it. If this ATProto thing is successful in its goals, it will cause much inconvenience to me and greatly diminish my ability to publish my works on the internet.

Re: A Social Filesystem

#232

Post by trizuz »

japanuspus wrote: post #162

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

[dead]

Re: A Social Filesystem

#233

Post by Diti »

danabramov wrote: post #65
skeledrew wrote: post #56

I've been thinking of this for some time, conceptually, but perhaps from a more fundamental angle. I think the idea of "files" is pretty dated and can be thrown out. Treat everything as data blobs (inspired by PerKeep[0]) addressed by their hashes and many of the issues described in the article just aren't even a thing. If it really makes sense, or for compatibility sake, relevant blobs can be exposed through a files…

I'm using filesystem more as a metaphor than literally. I picked this metaphor because "apps" are many-to-many to "file formats". I found "file format" to be a very powerful analogy for lexicons so I kind of built everything else in the explanation around that. You can read https://atproto.com/specs/repository for more technical details about the repository data structure: The repository data structure is content-add…

But you don’t need the AT protocol and lexicons to describe semantics. Ontologies have been a thing for decades, and search engines (the “rich results”) and ActivityPub use them.

Why use the lexicons you described, instead of the more supported https://www.w3.org/ns/activitystreams ontology that ActivityPub uses, for example?

If you allow me to, I would be interested in re-writing your article but by using ActivityPub concepts instead. Maybe I will learn about a fatal flaw in one of the protocols during that process.

Re: A Social Filesystem

#234

Post by mike_hearn »

skeledrew wrote: post #225
mike_hearn wrote: post #205

Earlier quoted context omitted.

FWIW the Look Up feature, whilst built in to macOS, can also be implemented using "services" which are a way to plug in to other apps and system features like text rendering and highlighting. I can also select text in your message, right click, services -> "Add to music as spoken track". That's a plugin offered by an app. It's only one extra click. My perspective on why OpenDoc/OLE failed are different to yours. The…

> implemented using "services" Yes that's a pattern offered and used on all modern OSes to various degrees, but most - particularly independent - developers prefer to bundle the capabilities they're offering in such a way that they're only available via their app's interface. I think partly because it's just easier to implement that way, but also because it's in their interest (not the users') to not allow the capabi…

OLE has been dead for decades, yes. When was the last time a new app launched and being embeddable in Office documents via OLE was a key advertised feature? I don't know what even happens if you open a .docx with an embedded OLE object in Word Online.

Obviously the APIs are still there. You can use them if you want. It's just that nobody is writing pure/native win32 apps anymore, outside of browsers and legacy codebases. So, new code isn't being written as OLE controls.

I don't think Jobs killed OpenDoc because of some vision of an ecosystem of Apple's apps. At the time he made that decision Apple was on death's door because it had a culture of architecture astronauts spending years in front of whiteboards, writing features that didn't directly appeal to what the market wanted. He killed many projects at that time for the same reasons, like their line of printers.

If OpenDoc/OLE had been genuinely the right path we'd have seen people outside of MS/Apple try to reinvent them. Plenty of companies have the resources, as does the open source community. In fact KDE and GNOME both did try with KParts and Bonobo. But, both of those are dead too.

To your wider point, yes, it's often the case that what the app developers need/want is in conflict with what the users need want. I don't see that as a problem. Trade always involves tradeoffs, when users and developers trade there is always an implicit negotiation in the background. Sometimes that negotiation falls more on user freedoms and sometimes users choose to give up those freedoms to get other things they want. That's just trade, it's been true since before humans had writing. I don't think there's anything unique or special in computing in that regard.

Re: A Social Filesystem

#235

Post by danabramov »

mike_hearn wrote: post #217
danabramov wrote: post #208

Earlier quoted context omitted.

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.

I see. Well, my point was to start with that to give an intuition of the many-to-many between apps and data, and then transfer this intuition to social aggregated apps (which is what AT enables).

Re: A Social Filesystem

#236

Post by danabramov »

mike_hearn wrote: post #214
danabramov wrote: post #212

Earlier quoted context omitted.

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

All good points.

Maybe I’m optimistic for no good reason. I feel there’s something slightly different at play here but I struggle to put my finger on it.

Overall I agree with the take that a client for somebody else’s product is usually degraded experience. You want to deploy features vertically, and even existence of worse clients is a threat to that. I think one exception to that is when the main client is intentionally worse for the sake of other goals. Eg lots of ads. Or just the company being (or becoming) incompetent at making a client. Then alternative clients inject some new life and competition into the product. But if the product owner is good at making clients, they probably don’t benefit from fragmentation.

And still it feels somehow different to me. I think a part of it is that the space itself is vastly expanded in AT. We’re not just talking about a vertical app with a few offshoot clients that do the same thing but poorly. I mean, that still exists, but the proposition is that things can reach way beyond the original product. Products can blend. When products blend, there’s always this inherent coordination problem. Those who make multiple vertical products have to deal with similar things. At some point you have to stagger rollouts, support features partially or in a limited way, or show a simple version and direct to main app for more. Think Threads “bleeding through” Instagram, different kinds of cross-posting that they experiment with between apps. This is valuable but normally only monopolies can build meaningful cross-product bleeding because otherwise you have to negotiate API agreements and it’s just too risky to build on someone else’s turf.

What AT changes is that every product can cross-bleed into every other product. My teal.fm plays show up on my Blento page. So yes, you do have this fragmentation, but you also get something in return. It’s not fragmentation between the main way to show a thing and a couple offshoots, but between a web of products. And there is always a canonical schema so it doesn’t descend into chaos. I think there’s a “there” there.

I actually agree the key pillar is identity. It’s what AT URIs start with identity first. I think one way to look at AT is that the “contact list” analogy is right, but now that we’ve chosen the identity layer, we might as well put all our data into the contact list.

Re: A Social Filesystem

#237

Post by mike_hearn »

danabramov wrote: post #236
mike_hearn wrote: post #214

Earlier quoted context omitted.

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

All good points. Maybe I’m optimistic for no good reason. I feel there’s something slightly different at play here but I struggle to put my finger on it. Overall I agree with the take that a client for somebody else’s product is usually degraded experience. You want to deploy features vertically, and even existence of worse clients is a threat to that. I think one exception to that is when the main client is intentio…

Riffing off the identity thing, one service I wanted for a while is something that issues X.509 certificates based on verified phone numbers. Phone numbers are a pretty great identity, perhaps the most successful private sector identity system ever, but they're expensive and annoying to verify, and the verification isn't portable across systems. A CA that did SMS verification and then gave you a certificate you could use with S/MIME or bind to passkeys or just use to sign software/documents in general, would democratize stable cryptographic identity. People generally can't handle key management directly, it's too easy to lose keys, but issuing transient keys tied to a phone number is much more palatable.

And PNs have got good features you want in general:

• Can have >1 of them if you want.

• Anonymous if you want.

• Not tied to any specific provider due to number portability laws.

• Hard to lose; phone companies will accept govt issued ID to get your account back if you lose your SIM and it's tied to a contract.

• Verifiable over the internet.

The only problem with them is they don't yield asymmetric keypairs.

The difficulty is business model. The people who want to consume such certificates are people who don't want to pay to verify numbers directly, but users don't want to pay either. So who pays.

Re: A Social Filesystem

#238

Post by evbogue »

verdverm wrote: post #229
evbogue wrote: post #219

Earlier quoted context omitted.

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

Well, when you figure out why at:// exists and why your hand waving away it's role in your "I guess" makes it impossible... we can chat then Until then, you are just slopping about like an ai

dude you represent yourself as a tony the AI worm.

I'll do an:// urls if you bring yourself and your code agent to myproto for an afternoon.

Re: A Social Filesystem

#239

Post by ximeng »

verdverm wrote: post #230
danabramov wrote: post #183

Earlier quoted context omitted.

See https://www.pfrazee.com/leaflets/3lzhui2zbxk2b for some recent thoughts from a team member.

Bnewbold's comment on GitHub is still the best resource. It's far more specific in scope and details. Paul's note is more theoretical / philosophical

https://github.com/bluesky-social/atproto/discussions/3363 - maybe this one?

Re: A Social Filesystem

#240

Post by skeledrew »

mike_hearn wrote: post #234
skeledrew wrote: post #225

Earlier quoted context omitted.

> implemented using "services" Yes that's a pattern offered and used on all modern OSes to various degrees, but most - particularly independent - developers prefer to bundle the capabilities they're offering in such a way that they're only available via their app's interface. I think partly because it's just easier to implement that way, but also because it's in their interest (not the users') to not allow the capabi…

OLE has been dead for decades, yes. When was the last time a new app launched and being embeddable in Office documents via OLE was a key advertised feature? I don't know what even happens if you open a .docx with an embedded OLE object in Word Online. Obviously the APIs are still there. You can use them if you want. It's just that nobody is writing pure/native win32 apps anymore, outside of browsers and legacy codeba…

Because something isn't widely adopted doesn't mean that it's dead. Microsoft continues to use and support OLE today, and there's a non-zero number of non-Microsoft-affiliated persons out there using it (I've seen forums with users asking how to do X regarding it).

KParts too is very much alive, as it's a core part of KDE Frameworks, which is used to build Plasma. And I know for a fact it works very well because I'm a Kubuntu user (11 years).

Post reply on HN