RIP botsin.space

Original Article ↗ Hacker News Discussion ↗

Emotional response & value of botsin.space

  • Many express sadness; botsin.space was a long‑running source of joy, creativity, and experimentation with bots.
  • People thank the operator for hosting, appreciate the long sunset period, and discuss finding new homes for their bots.
  • Some note that, despite technical usefulness, it never gained strong network effects beyond being “just some server in space.”

Running federated instances: cost, complexity, burnout

  • Operating Mastodon/Lemmy instances is portrayed as hard: time, money, moderation, and legal obligations (DMCA, privacy laws, possible subpoenas).
  • One commenter initially overstated subpoena frequency, later corrected to far lower rates; others note subpoenas usually don’t mean the operator is “in trouble.”
  • Cloud costs (especially storage and bandwidth) and Mastodon’s Rails stack are seen as heavy; alternatives like Pleroma/Akkoma/GotoSocial/Honk are cited as lighter.
  • Suggestions to charge users or move to cheaper hosts (e.g., Hetzner) meet pushback: that turns a hobby into a business with billing, fraud, tax, and support burdens.
  • Some say expiring old posts or self‑hosting at home can control costs.

Federation, centralization, and user power

  • Several argue federation doesn’t fully fix power imbalances: users are still at mercy of admins, and most won’t self‑host.
  • Others stress the benefit of being able to choose providers, akin to email, even if most people pick a few large instances.
  • Mastodon is criticized for poor portability: instance moves often lose post history, and federation quirks make migration and search frustrating.
  • Defederation “wars” and UX hurdles (choosing a server, broken trending/search) are seen as barriers to mainstream adoption.

Protocol & architecture debates (ActivityPub, ATProto, Matrix, etc.)

  • ActivityPub’s heaviness is attributed more to specific implementations (e.g., Mastodon/Rails) than the protocol itself; some servers run efficiently.
  • Performance debates span languages (Ruby vs Rust/Scala/etc.) and architectures (push vs pull, fan‑out, media retention).
  • Comparisons:
    • ActivityPub/Mastodon: many small “Twitters,” federation by servers.
    • ATProto/Bluesky: portable identities via DIDs and domains; identity decoupled from hosting; seen by some as closer to email/web’s durability model.
    • Matrix: criticized for slow federation and uneven server implementations; some users retreat to XMPP.
    • Nostr and P2P ideas are discussed but seen as hard on mobile and for large‑scale querying.

Long‑term sustainability & the “death of sites”

  • Commenters expect more shutdowns in the fediverse: volunteer‑run services can’t guarantee permanence.
  • Some accept this as normal internet churn; others find frequent migrations and “islands” of community discouraging.
  • Archive/“deathwatch” efforts are linked as a way to track and preserve dying services.