A Social Filesystem

Original Article ↗ Hacker News Discussion ↗

Scope and goals of AT Protocol / “social filesystem”

  • Many comments engage with the idea of treating social data as “files” outside apps, accessed through Personal Data Servers (PDS).
  • Proponents highlight:
    • App-independent data ownership and portability (social graph, posts, likes) so users can switch or “fork” products without losing history.
    • Real-time, signed, structured data that supports large-scale aggregation across apps.
    • Existing examples: self-hosted PDSs, PDS browsers/mounters, and apps like a git host built on top of AT.

Skepticism: overengineering and wrong problem focus

  • Several see the filesystem metaphor and AT’s layering (lexicons, collections, DIDs, repos) as architecture-astronaut territory.
  • Critique: modeling social media as files doesn’t address core problems—moderation, harassment, bots, incentives, and “hate machine” dynamics.
  • Others argue protocols aren’t the bottleneck; they’re worried AT becomes just another Twitter clone and a business play rather than genuine decentralization.

Usability, adoption, and who runs the servers

  • Concern that expecting users to run their own PDS is unrealistic; mass adoption needs “plug-in appliance” simplicity.
  • Counterpoint: most people will use hosted PDS providers; hosting text data is cheap, heavy operations (video, indexing) are separate services.
  • Comparisons: Solid, remoteStorage, Nostr, RSS, and XML; AT is framed as targeting public-data aggregation first, with app-defined schemas (lexicons) instead of RDF.

Privacy, permanence, and surveillance

  • Strong worries that AT’s design creates a near-perfect, easily-mined, lifelong public record of activity.
  • Some see Mastodon’s fragmentation and friction as a privacy feature (harder to fully index).
  • Others respond that anything public on the internet is effectively permanent already; AT simply makes the reality explicit (“assume everything is scraped”).
  • Suggestions include separate identities, encryption, and being explicit that AT is a public broadcast medium; private data is planned but immature.

Lexicons, evolution, and product forking

  • Discussion of lexicons as “file formats”:
    • Additive changes are allowed; validation happens on read, so apps can ignore unknown fields or invalid records.
    • New lexicon versions can be introduced for breaking changes.
  • Example use cases: alternative frontends rendering the same data, resurrecting or forking shutdown services while preserving users’ content.
  • Some remain unconvinced that self-describing schemas meaningfully reduce client work or solve social-network quality issues.