1. 29
  1.  

  2. 11

    Maybe we can save ActivityPub by extending it to be properly capability-based and eventually dropping support for the ActivityPub of today. But this will require coordination between all the vendors. And with 40+ projects out there, it’s not going to be easy. And do we even care about those 40+ projects anyway?

    This reminds me of a quote from one of Signal’s devs regarding the lack of federation in Signal (found during our last Mastodon-related thread):

    Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all…it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving.

    1. 9

      It’s a cop-out though: Platon’s Philosopher King would be a nice thing to have, but absent that (and the foresight to know whether you really picked the right one), we opted for democracy.

      XMPP found a way to bring everybody up to speed by having a sizable part of the ecosystem agree on certain XEPs (protocol extensions) to be mandatory from a given, future date. That way we get the experimentation, and once things stabilized, the sharks in the pond convened and declared what everybody needs to move to.

      HTTP software simply continues to support old versions. I guess servers and clients in 2030 might drop support for HTTP 1.0, but until then, everything has a fallback.

    2. 11

      The messages I share only with my friends should be handled in a secure manner. I should be able to depend on the software to not compromise my private posts.

      This will probably not fly in the real world, but I’ve been thinking that publishing and private sharing are fundamentally different, and should be handled by different protocols.

      • For public posts, we want… well, maximum publicity?
        • Webmention conversations between websites work perfectly well for this. (ActivityPub is sort of similar and we can bridge them anyway.)
        • would be nice to add some sort of mirroring-archiving thing that would use IPFS, Dat etc. to maximize availability and preserve the posts for the future
      • For private posts, we want… well, maximum privacy?
        • This is where Scuttlebutt comes in!
          • the protocol is designed to replicate an append-only log of posts among a trusted network
          • so it’s a bit rubbish for public posting — “pubs” are “public peers” that “become your friend” and replicate a ton of random junk to you
          • but it seems like an awesome friends-only network

      The ideal distributed social network should somehow combine all these aspects.

      1. 5

        This article makes some good points, and I’ve heard similar points made by a number of security professionals.

        However I have to ask - are they trying to build something fundamentally different from what the Fediverse currently is?

        I would argue that there are a whole host of activities where the capability model described in the article and elsewhere really isn’t that important.

        As far as I’m concerned, I’d be quite fine with the whole thing being flat out public with no security at all beyond that which the individual instance maintainer chooses to enforce.

        There is still a place in the world for shared trust.

        1. 5

          As far as I’m concerned, I’d be quite fine with the whole thing being flat out public with no security at all beyond that which the individual instance maintainer chooses to enforce.

          This. I’ve always been fairly confused when people complain about the “privacy” of mastodon. It’s foolish to expect a social platform for the public to be oh so private in the first place. Because when the social network (no pun intended) grows large, the people involved are far more likely to fail from a security standpoint than the technology. When your posts go out to large lists of people, across a large chain of servers, how do you reasonably trust every single one of those people, every single one of those servers, and each of their operators, to not share the information you’ve sent out so gratuitously, in ways you prefer them not?

          All it takes to break these “security” schemes is a press of the “Print Screen” button, and any sort of infrastructural security applied (even end to end encryption, in the case of “follower only” posts and blocked instances) is made completely moot.

          And if you’ve been on any social network for a short period of time, you’ll find this isn’t really a hypothetical. It happens regularly. Block evasion, private messages and posts getting leaked, all the social problems of sharing with a large audience are far more immediate than dorky concerns over “protocol design principles”.

          1. 2

            I think I alluded to the core issue here in my first response. Security minded people want something else.

            They don’t want the Fediverse, they want a truly secure federated protocol that will allow them to have closed, super private networks offering various services. I’d always heard them discussed in terms of “peer to peer” but I suspect the goals are the same or very similar.

        2. 4

          These requirements sound reasonable, right? And of course, ActivityPub mostly gets the job done. After all, the main use of social media is shitposting, posting selfies of yourself and sharing pictures of your dog. But would they be better served by a different protocol? Absolutely.

          Gotta mix the jokes with the seriousness, lol. Shitposting must be done securely!

          An example of this is with instances you’ve banned being able to see threads from your instance still: what happens with this is that somebody from a third instance interacts with the thread and then the software (either Mastodon or Pleroma) reconstructs the entire thread. Since there is no authentication requirement to retrieve a thread, these blocked instances can successfully reconstruct the threads they weren’t allowed to receive in the first place. The only difference between Mastodon and Pleroma here is that Pleroma allows the general public to view the shared timelines without using a third party tool, which exposes the leaks caused by ActivityPub’s bad design.

          The warring of two popular AP implementations. It seems like Pleroma is going to end up as the reference implementation of AP despite the qualms with AP.

          1. 2

            It seems like Pleroma is going to end up as the reference implementation of AP despite the qualms with AP.

            Yeah, I’ve gotten this feeling, too. Mainly because it’s the least opinionated implementation (except for the opinion that Linked Data is a mistake). Mastodon’s use of ActivityPub is very Mastodon-specific. Which is actually fine, but leaves the reference implementation space wide open.

          2. 3

            The article in general just doesn’t feel constructive, but destructive.

            In an ideal world, the number of ActivityPub implementations would be zero. But of course this is not an ideal world, so that leaves us with the question: “where do we go from here?”

            The general points of failure presented for ActivityPub seem reasonably valid, and it’s a Pleroma dev, probably knows a thing or two about ActivityPub.

            But the way the article is redacted isn’t respectful for the ActivityPub ecosystem and draws a very negative world in which the existence of ActivityPub is a tragedy, when in reality it have enabled a free social revolution.