6 Matching Annotations
  1. May 2022
    1. instead of the “Mastodon appraoch” we take the “Replit approach”

      I'm confused by the continual references to the Replit. Once you have Replit-style power, you can do Mastodon interop—but it keeps you dependent on third-party SaaS. Continuing to violate the principle of least power isn't really any improvement. If you're going to shoot for displacing the status quo, it should be to enable public participation from people who have nothing more than a Neocities account or a static site published with GitHub Pages or one of the many other providers. Once you bring "live" backends into this (in contrast to "dead" media like RSS/Atom), you've pretty much compromised the whole thing.

    2. What happens if - maybe! - there’s a model of decentralization that feels more like a bunch of weird Replits networking with each other.

      Get rid of the networking, and make it more like the RSS/Atom model.

      ActivityPub, for example, shouldn't really require active server support if you just want publish to the clear Web (i.e. have no use for DMs). Anyone, anywhere can add RSS/Atom "support" to their blog—it's just dumping another asset on their (possibly static!) site. Not so with something like Mastodon, which is unfortunate. It violates the Principle of Least Power at a fundamental level.

    1. I wrote about my idea for Library.json a while back. It’s this idea that we might be able to rebuild these monolithic centralized services like Goodreads using nothing by a little RSS.

      See also this thread with Noel De Martin, discussing a (Solid-based) organizer for your media library/watchlist: https://noeldemartin.social/@noeldemartin/105646436548899306

      It shouldn't require Solid-level powers to run this. A design based upon "inert" data like RSS/Atom/JSON feeds (that don't require a smart backend to take on the role of an active participant in the protocol) would beat every attempt at Solid, ActivityPub, etc. that has been tried so far. "Inert"/"dead" media that works by just dumping some content on a Web-reachable endpoint somewhere, including a static site, is always going to be more accessible/approachable than something that requires either a server plug-in or a whole new backend to handle.

      The litmus test for any new proposal for a social protocol should be, "If I can't join the conversation by thumping on my SSG to get it to produce the right kind of output—the way that it's possible with RSS/Atom—then the design is fundamentally flawed and needs to be fixed."

    1. Theoretically, there are many plugins for webservers adding support for scripting using any scripting language you can name. These are sometimes used to host full-blown web applications but I don't see them being used to facilitate mildly dynamic functionality.

      All in all, despite its own flaws, I think this piece hints at a useful ontology for understanding the nuanced, difficult-to-name, POLP-violating design flaws in stuff like Mastodon/ActivityPub—and why BYFOB/S4 is a better fit, esp. for non-technical people.


    2. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.

      Unnecessary violation of the Principle of Least Power.

      No active server component is necessary for this. It can be handled by the user agent's content negotiation.

  2. Aug 2021
    1. RemoteStorage requires the server to support a subset of OAuth, and that's the only kind of authentication supported. It also requires WebFinger support