This website is hosted on Bluesky

Original Article ↗ Hacker News Discussion ↗

Hosting an entire website out of Bluesky’s AT Protocol blob storage is prompting curiosity about how far the platform’s “personal data servers” can be pushed beyond social posts. Commenters explore the technical underpinnings (content-addressable data, CSP lockdown, lack of auth, IPFS influences) and weigh opportunities such as decentralized file sharing, RSS-style feeds, and app-specific data (e.g., game mods) against clear risks like phishing, malware hosting, copyright abuse, and content moderation burdens. The conversation also situates Bluesky within broader questions about sustainable business models, federation, and whether AT Proto can evolve into a general-purpose, user-controlled data layer for the web.

Static Site Generators & Personal Tooling

  • Several comments tangent into static-site tooling: Hugo, Jekyll, Astro, MkDocs, and fully custom generators.
  • People note that many Hugo/Jekyll sites hide their “Powered by” footer or generator meta tag.
  • Some prefer minimal or custom themes, others use docs-focused tools (MkDocs + readthedocs theme).
  • One person describes a heavily customized Python/Jinja/FastAPI pipeline to build a personal/private site from various data sources.

Security, CSP, and Blob Hosting Endpoint

  • A responder inspects the blob URL headers: rate limiting, permissive CORS (*), strict CSP (default-src 'none'; sandbox), and no JS execution.
  • Discussion clarifies: sandbox doesn’t block all external resource loads; default-src 'none' does. Data URIs would also be blocked.
  • Some argue that fully containing apps with CSP basically requires blocking all JS; CSP can reduce but not eliminate exfiltration.
  • WebAssembly is mentioned as safer by default because it lacks direct DOM/global access unless explicitly wired.

AT Protocol, IPFS, and PDS Design

  • Bluesky’s stack reuses components from IPFS (CIDs, DAG-CBOR) but not its global P2P network or libp2p; they wanted user-controlled hosting, easy edits/deletes, and collections.
  • One former IPFS lead says Bluesky is effectively a streamlined IPFS-like implementation; repo data can be imported into IPFS.
  • ATProto content is described as fully public, content-addressed, merkle-tree-based, and mirrorable; moderation is mainly at the app layer.

Abuse, Phishing, and Moderation Concerns

  • Multiple comments predict phishing, malware, CSAM, copyright issues, and eventual blocking of *.bsky.network by security vendors.
  • Some note that any upload/hosting platform is eventually abused in this way; “parasitic data storage” is proposed as a term.
  • There’s debate over whether hosting HTML on an official-looking Bluesky domain is materially worse than any other hosting provider.
  • Comparisons are drawn to Matrix’s need for authenticated media to curb abuse; similar tradeoffs complicate client interoperability.

Business Model & Sustainability

  • Some see ATProto’s “centralize-by-default, decentralize-when-needed” approach as more realistic than Fediverse-style models.
  • Concerns are raised about VC funding, especially from crypto-focused investors, and the need for sustainable revenue.
  • Suggested models: premium PDS tiers (more storage, higher-quality media), Nitro-like subscriptions, or app-level services that monetize access or media.
  • Others argue social media ad models are weakening; a smaller core team plus open-source community could keep costs manageable.

Data Ownership, AI Training, and Privacy

  • Bluesky’s ToS reportedly say users retain ownership of their content, but the protocol exposes public data that’s easy to scrape.
  • One reading of the ToS suggests Bluesky can “utilize” user content broadly, which might include training LLMs, though this is debated and not explicit.
  • Someone notes campaigns encouraging artists to move to Bluesky to avoid AI training may be misleading if all public data is easily ingestible.

Ecosystem Ideas & Potential Applications

  • Commenters brainstorm uses of blobs/PDS beyond blogs:
    • Doom WADs and game mod “workshop” distribution via accounts/lists.
    • RSS-to-Bluesky bots already exist; basic implementations are small scripts in languages like Rust using low-level SDKs.
    • Ideas for federated Strava-like services using ATProto to store GPX/FIT files, but lack of private/limited-visibility records is seen as a blocker.
    • Suggestions that third-party PDSes could expose other protocols (e.g., git read-only access) alongside ATProto.

Social Dynamics & Onboarding

  • Debate over cutesy post names (“skeets”) versus neutral terms (“posts”); some find bodily-function metaphors alienating and juvenile.
  • Bluesky’s official term is “post,” and many expect that to win out as the userbase grows.
  • The invite-only period is criticized for creating an in-group feel and shaping culture; some perceive the main instance as ideologically skewed.
  • Others counter that Bluesky spans a broad political range, minus the most toxic behaviors, and is currently less polluted by bots and engagement hacks than X/Twitter.
  • There’s disagreement over speech suppression: some say Bluesky defaults to chronological feeds with only illegal content removed; X/Twitter is accused of opaque, revenue-motivated throttling of outbound links.

Parasitic Storage & Historical Parallels

  • Several note a recurring pattern: any service that stores bytes eventually gets used for arbitrary data (Gmail/Drive backups, YouTube-as-storage, etc.).
  • Links are shared to “cloud storage abuse” project lists and the “inner platform effect” as conceptual parallels.
  • Some see this as inevitable and even fun (e.g., hosting Pong or entire texts in data URIs on Twitter); others emphasize the moderation and reputational costs.