reb00ted

We can sustainably, fairly, do better. Let's go.

Tech

By Johannes Ernst

https://reb00ted.org/tech/

  • 2023-06-28

    ActivityPub everywhere?

    In previous posts, I argued the EU’s Digital Services and Digital Markets Acts are the most likely reason why Meta is implementing ActivityPub in its upcoming Twitter competitor “P92”, and that ActivityPub is really the only game in town that meets Meta’s requirements for interop for “P92”, as they require protocols that are proven to work and governed in a lawyer-vetted process by a legitimate standards organization.

    But if that line of reasoning is correct for for why Meta would pick ActivityPub to meet its interoperability obligations under EU’s new rules, it is likely also correct for all other social networking products, by Meta and others, that are required to interop by the same new rules, notably:

    • Facebook (also Meta)
    • Instagram (also Meta)
    • Snapchat (Snap)
    • LinkedIn (Microsoft)
    • Twitter
    • and perhaps even YouTube (Google).

    (The full list is here although I think the EU puts them in different markets. Update 2023-06-30: Actually, this is the wrong list; the list of “gatekeepers” will only be established in a couple of months under the Digital Markets Act. Chances are it’s very similar to this list of “Very large on-line platforms”, however.)

    Let me say this again. The product teams of all of those products are very likely asking themselves the very same question right now that Meta asked itself: what are we going to implement to meet our interop obligations, and when are we going to do it?

    I believe most will arrive at the same conclusion: they will look for protocols that can demonstrably work for these kinds of interop requirements, and that are maintained by a well-understood standards organization. And will find that ActivityPub is the only game in town that meets those requirements.

    (It is possible that one or two of the organizations above come up with a “spoiler” strategy developing or picking an alternate protocol. To make up a random example, say, Microsoft might buy Bluesky and declare it to be its interop architecture. They would have to turn that protocol over to a standards org, however, before its competitors would even consider it. And that might not gain them much; sticking with ActivityPub is simpler.)

    (It is also possible that some of the above organization will choose to fight the EU in court; Twitter comes to mind. I’m not a lawyer, I don’t know how likely this might succeed; however, the EU has shown to be tenacious and unstoppably moving forward in this direction, so I wouldn’t bet on that strategy if I were them.)

    Which means a number of things – starting with the ActivityPub standardization process in the W3C:

    • Meta, Microsoft and others will suddenly show up in the W3C ActivityPub community. It’s easy for them to do, they already have been spending significant amounts of time in the W3C.

    • They will show up with requirements currently considered out of scope by the W3C SWICG, but driven by the need that the entire stack is standardized that is necessary to enable interop between, say LinkedIn and Facebook. If they decide that real interop is actually necessary – my premise – then an “assembly required” standard (like ActivityPub is today) is not sufficient for them.

    • Therefore the official Social Web Working Group will need to be re-constituted, and its charter will need to be broader than it was before.

    • There will be loud screaming in the existing W3C social community. (Because many of the members of the current SWIGC are extremely strongly in opposed to surveillance capitalism – the prevailing business model of most of the companies above – or, in some cases, that any kind of business has any role in desirable forms of social media at all.) An accommodation will have to be found, as the W3C as an organization wants to serve all willing participants in a standards process, not just those with a certain value system.

    But there more intriguing, and exciting possibility is this:

    • When everything is said and done and my line of reasoning is reasonably correct, interoperability via ActivityPub indeed might be “everywhere”: Facebook, Instagram, P92, LinkedIn, Snapchat, even Twitter.

    Social media would end up being a radically different beast. A potentially much better, beast as I believe. Ponder this.

    Updated 2023-06-30:

    • Added Digital Markets Act in addition to the Digital Services Act; it’s really both and the intent behind them that drive this.

  • 2023-06-27

    Meta, ActivityPub and the EU’s Digital Services and Market Acts

    Imagine you are Meta executive management, and one day your lawyers come to you and say:

    “We assess it as very likely that within a year or two, Meta’s social networking products will need to interoperate with social networks from other vendors, such as Twitter, LinkedIn, Snapchat and the like. Europe’s Digital Services and Market Acts have come in effect, they apply to us, and while we think we can delay enforcement for a while, ultimately we will need to interoperate with other social networks if we don’t want to leave the entire European market or get sued out of existence. These Europeans are not kidding.”

    You might argue with them for a bit, but if they insist that their assessment is correct, and there are no viable legal options to avoid doing this, if you were the Meta executive team, what would you do?

    I think there are two key questions:

    • What exactly are you going to implement?
    • When are you going to implement it in which product?

    Let’s start with the second question. Whatever you end up doing, it’s novel: nobody has ever federated social networking products at the billion+ user population level. And so nobody has any experience what kinds of problems might occur – whether technical, moderation-wise, protocol governance, fixing interop problems by collaborating with your competitors, cross-jurisdiction issues if content seeps from another social network that’s banned there etc etc. Nobody even knows what the list of potential problems even could be. So even if you are not trying to drag your feet, you will want to start small, and gain some experience how to do this, before scaling up to billions of users. I think even the most zealous regulator will probably accept that a gradual approach is warranted.

    But: your existing social networking products, notably Facebook and Instagram, have billions of users. It’s not obvious how you can start small and not confuse the heck out of everybody. Works only in the EU? What if people travel or move? And the EU with its almost half a billion people is too large anyway as an initial user population.

    As luck has it, you also just decided you were going to compete with Twitter. With a completely new product which currently has a user population of … zero! And given you haven’t really built it yet, you can architect it from the get-go to be interop friendly. Much easier than to refactor Instagram at the billion user scale. So why not start there?

    Back to the other question: what exactly are you going to implement? Let’s assume the lawyers have also advised to you that mere lip service is not going to be good enough, the interop actually needs to work, work well, and be a reliable, supported feature, for many years to come.

    It also needs to work not just with one competitor, like, say, Twitter, but at least a half dozen of them, and new ones show up from time to time you will need to interop with, too. So bilateral deals won’t work, and it needs to be based on an industry standard; either one that exists already or that is to be created. And that industry standard needs to be maintained by some standards organization that you understand, that does not give any one vendor outside influence, one whose process you have vetted and perhaps have experience with.

    Enter ActivityPub. It seems to work, at least at the million-user level. And it’s the only social networking interop standard around that has been created by a bona-fide standards organizations, the W3C. None of the other protocols – like Bluesky, Nostr etc – meet those requirements; ActivityPub is really the only (existing) game in town for what you need.

    Ergo: you end up with ActivityPub in your upcoming Twitter competitor, pretty much from the very beginning. Which is the most plausible reason I found in a previous post why Meta might do this completely out-of-character thing and implement ActivityPub in its new “P92” product.

    Updated 2023-06-30:

    • Added Digital Markets Act in addition to the Digital Services Act; it’s really both.
    • Feedback from the Fediverse correctly points out that so far, only interop requirements for messaging services (“Whatsapp” etc) are prescribed in detail (in the Digital Markets Act). However, IMHO that misses the larger picture: I read the aim of the text of the acts as applying to all “commonly used digital services that mostly directly intermediate between business users and end users” and “where concerns about weak contestability and unfair practices by gatekeepers are more apparent and pressing from an internal market perspective” which arguably applies more to social networking than messaging services. Also, Twitter-like services are very much also used as direct messaging services as well.

  • 2023-06-25

    Why would Meta implement ActivityPub? 1½ reasons are compelling, another is not

    Meta has gradually locked down all of its apps. Now they are coming out with a Twitter competitor that, according to all reports, will have ActivityPub standards support. This promises to make it interoperable with other social networking apps like Mastodon in the broader Fediverse decentralized social network.

    The Fediverse is in uproar, debating fiercely how to react to it, with a sizable group of operators already promising to block them out of the gate, mostly on the grounds that Meta is the personification of everything that the Fediverse is against: tracking, surveillance, manipulation, advertising.

    But why would Meta support ActivityPub in the first place? It is completely out of character for them. I would suggest that only if we understand Meta’s goals with ActivityPub support can we make a rational assessment what, if anything, we should do to react.

    First, let’s dispense with this first commonly cited reason why they do this. It does not pass muster.

    1. Meta wishes to leverage today’s Fediverse to get started, and then embrace and extinguish it.

    No, it does not. Two good arguments:

    • Numbers: Alex Heath is reporting that “Meta is hoping for at least tens of millions of users within the first few months of availability”. The Fediverse currently has between 1 and 2 million active monthly users. So Meta is expecting at least 10x of those numbers by the end of the year.

      (If you think of it, of course they want those kinds of numbers. Both Facebook and Instagram have far more than a billion users each. Why would they build another app if they didn’t think they would get at least 100 million users?)

      Embrace and extend is an entirely ineffective strategy if what you want to embrace and extend has only a tenth of the users you want “in just a few months”. It is not worth to embark on such a complex strategy if it only works for a month or two at best.

    • Would you really go to market focused on an initial customer segment that contains all the people – and perhaps only those people – most actively hostile to you as a company?

    Verdict: NO.

    Let’s move on to a more likely reason:

    2. Meta observed that Elon cut off many third-party apps from Twitter, and wants to attract those third-party developers to the new app so the new app can more effectively compete with Twitter.

    This is a more compelling reason. Building an ecosystem of complementary apps and services is a tried-and-true, successful strategy to compete against a product that does not have them. And which just burned its bridges with the developer community by cutting them off out of the blue.

    However: if that was goal, why would they implement standardized ActivityPub, as opposed to simply creating a (proprietary) API, like Meta has for its other products? It’s not like the cut-off Twitter app developers will require a standard API to come to Meta: not losing their business is good enough for them. Also, implementing a standard protocol comes with substantial costs and risks to Meta, including its inability to change it on a whim when Meta’s business circumstances should change.

    Verdict: INSUFFICIENT as an explanation.

    3. The European Union is coming down hard on Meta, demanding all sorts of interoperability as part of its Digital Services and Digital Market Acts. By implementing a bona-fide W3C interoperability standard as part of a new app, Meta can signal both cooperation with the EU authorities, while delaying opening its core business as long as possible.

    In the US, we tend to ignore changes in European law. We also seem to consider it inconceivable that any meaningful jurisdiction would actually pass the kinds of laws that they have been passing left and right. But they have, and the EU commission is not kidding with enforcement either. While Meta may decide to leave Canada to not have to comply with certain Canadian laws, they cannot afford to leave an affluent, almost half-billion people market.

    I’m sure Meta is embarking on a multi-pronged strategy to resist, including lobbying, lawsuits, dragging their feet, and all sorts of other things. This multi-pronged strategy probably also means they have to throw the regulators a bone, on occasion. What better than to do this with a new product where there is no downside to an existing business, because there is no existing business? And if that helps with improving brand image – which it does – and appeal to 3rd-party developers, which the incumbent just turned against themselves, why not?

    Verdict: MOST PLAUSIBLE.

    If this analysis is more or less correct, this has consequences both for what Meta will doing going forward, and what today’s Fediverse should do to prepare and react. More in another piece. Follow me in the Fediverse to stay in the loop.

    Updated 2023-06-30: Added Digital Markets Act in addition to the Digital Services Act.

    Some selected comments:

  • 2023-05-22

    Meta implements ActivityPub? Not so fast.

    The Fediverse is in a state of (nervous!) excitement about the second leak this past week (after the first one back in March) that Meta is building a “text-based social app” for “creators and public figures”, variously code-named P92, Barcelona, or “Instagram for your thoughts” and which “could comes as soon as June”.

    Why the nervous excitement? Because both leaks state it “will be compatible with some other apps like Mastodon”.

    Many commentators have jumped to the conclusion that Meta will implement ActivityPub and participate in the Fediverse just like other ActivityPub-enabled app (even if it might bring ads or such). I believe this conclusion is wrong.

    Meta is much more likely to use this “compatibility” story as:

    1. a public relations / positioning coup to create good vibes for the new app among important thought leaders (it’s already working, see above!); and

    2. to present itself as the good guy in its fight with Twitter, which is the real target here.

    3. Use it as an avenue to siphon of current (and prospective) Fediverse users into their own app.

    Let’s see what the evidence there is for my belief. I’m working mostly off the more recent “primary” leak source here:

    1. Last week’s leak does not say “will implement ActivityPub”. The term “ActivityPub” does not appear at all. (The March leak does have the term, but it is unattributed and the Meta spokesperson they quote does not mention it.)

    2. The leak does not say “Meta will implement one (or more) standard protocols for connecting social applications”. There is nothing about favoring a standards-based approach in the leak, and certainly not a commitment to it, like they would have for other standards in other areas.

    3. The leak says “Will be compatible with some other apps like Mastodon”. Carefully parse this, specifically:

      • It does not say how it will be compatible. It could be, for example, by using the Mastodon-specific client API, or a combination of client and server/ActivityPub API. That might be helpful to Mastodon (maybe?) but not the rest of the Fediverse.
      • It gives no hint as to what they mean by “compatible”. If you think nicely working, bidirectional exchange of social media posts with everybody in the Fediverse you are jumping to a conclusion that is not backed by what has been said.
      • Why do they say “compatible with some other apps like Mastodon”, instead of “compatible with all other apps speaking ActivityPub”? This sounds far more selective, and subject to bilateral business agreements, than “any app that speaks the standard”.

    4. And then there is this: “Users on other apps will be able search for, follow and interact with your profile and content [on the Meta app]”. Were you looking for the inverse: “Users on the Meta app will be able to search for, follow and interact with any Fediverse profile?” Because it’s not there. Indeed it would have been much simpler to say “Users in all compatible apps will be able to …” but they don’t say that.

    This latter point is important: On Facebook, famously, you can post links “out” to any web page on the internet. However, you cannot link “in” from any page on the internet to an arbitrary Facebook post. Unlike other social networks like Twitter, Facebook is very asymmetric.

    Facebook/Meta has a history of asymmetric implementations of what everybody would otherwise think are and should be symmetrical systems. This very much reads to me like Fediverse users can follow Meta users, but Meta users cannot follow Fediverse users. If they do this, it would wreck the value proposition of the Fediverse, I would think.

    –

    Now these are all leaks, and as such, we should have very limited confidence in their truth, accuracy and completeness, and the accuracy of any analysis based on them such as mine. The proof will be in the app when they release it.

    But: in the meantime, we should be asking ourselves the question: what if Meta does not play a fair game here? What if they implement things to favor themselves to the detriment of everybody else, such a asymmetric implementations, all under the guys of playing nice with open-source apps such as Mastodon? Certainly that’s what we should expect based on their behavior in the past.

  • 2023-04-17

    Growing the Fediverse

    If you owned Twitter, how would you grow it? I think you have basically two choices:

    Increase tweeting and reading per user Increase number of users

    1. You can try to grow the number of users who use Twitter on a regular basis.

    2. You can try to increase the number of times each user tweets and browses others’ tweets.

    Is that the same for the Fediverse?

    Turns out the answer is a resounding No! We have far more options.

    Increase tweeting and reading per user Increase number of users Increase the number and diversity of Fediverse apps New categories of use cases (4D! Yay!)

    1. Yep, we can try and grow the number of users who regularly use the Fediverse.

    2. Yep, we can try to increase the number of times each user posts and reads other people’s posts. (Except that we don’t actually want to do that so very much, otherwise the Fediverse would have to become addictive, and not wanting to be manipulated is one of the things that got us off the big centralized social platforms in the first place.)

    3. We can do more things than just “tweeting” in the Fediverse. Because unlike on Twitter, every Fediverse-enabled app can – and usually does – add new features that go way beyond just posting “What’s happening”. And there are so many of them already! PeerTube for video, PixelFed for photos, FunkWhale for audio, Mobilizon for events, OwnCast for streaming, Bookwyrm for reading, Micro.blog for blogging and more … and all interoperating on the same network. Each new feature like that grows the Fediverse, as I can now do more things, and will if it is easy enough. Each of those tools grows the use of the Fediverse with the same number of users and the same number of “tweets”. Practically, Twitter does not have this option.

    4. Which, together, enables entirely new categories of use cases that go way beyond of what a social media platform like Twitter has ever done (or dreamt of!), or what any one Fediverse app can do on its own. Many of those will turn out to be much more valuable and useful than mere sharing “What’s happening”. And they will be possible because all of those apps can be combined in various ways on the same, free, ad-free, manipulation-free, open, rich communications network called the Fediverse.

    For this to work, however, we need to work to make the interactions between the various Fediverse apps much smoother than they are today. Yes, of course, ActivityPub lets us send notes and likes and comments and various other things around from one app to another.

    But much more can and should be done, such as:

    • Seamless single-sign-on across the Fediverse apps that I’m using. So if I see a Mobilizon event shared on Mastodon, I want to be able to click “Yes, RSVP, I’m coming” and identify myself with my Mastodon-issued Fediverse handle. There is no reason why I should have to sign up for a separate Mobilizon account first.

      The same, of course, should be true about videos, music, bookmarks, and so many other things in so many Fediverse apps. (Before you get concerned, yes, you should be able to have multiple non-connected “personas”, like work and play, in the Fediverse, but we still need single-sign-on within the scope of a single persona.)

    • My social network should come with me when I use different Fediverse apps. So if I decide to start using Pixelfed, I should be able to instantly follow all the photo streams of all the friends I’m following somewhere else, such as on Pleroma or Mastodon. After all, if I’m interested in the photos that my friend Joe shares, why would I make a distinction whether he shares them through one app or the other? The Fediverse can do this if we want to; no other social network can do this.

    • And and and…

    Imagine when data flows freely, data of many, rich kinds, across an open network, directly from your friends to you. Not just some social media data, but most data you care about! With nobody in the middle to manipulate you, or charge you, or advertise to you, or censor you … and no unnatural hoops that you need to jump through.

    We got to work on that last bit, and on that note, I’m very happy that a Fediverse Developer Network is coming together with participation from many excellent Fediverse developers working on a variety of apps. Our goal here is to connect the people well who work on this, so their apps can connect well, too! It’s early days, but very promising.

  • 2023-04-05

    Wish list for Fediverse standardization and other Fediverse technical “commons” activities

    This is an update to my previous wish list, now incorporating discussions of a recent meeting I helped put together of the the W3C Social Web Incubator Community Group (SWIG) and FediForum, as well as discussions in several other FediForum sessions as well as various one-on-one conversations.

    This wish list enumerates the work that I believe needs to be done by the technical Fediverse community to put the Fediverse on a more solid foundation, and make it ready to attract more developers and users. Note that obviously, not all these items are of similar importance and urgency. Note also this list does not include less-technical work, such as on moderation or culture.

    Your feedback – and help making it so – very much appreciated!

    Standards maintenance work on the core specifications

    Fixes to the the core spec

    • According to reports, ActivityPub as-is is incompatible with common shared hosting environments (e.g. typical WordPress host), as it requires HTTP content negotiation.
    • Issues backlog

    A design to reduce certain loads

    • Reduce protocol chattiness
    • Fan-out
    • Video
    • (Not my area of expertise, so I don’t have details)

    Decide on the future of ActivityPub Client-to-Server

    • Split the C2S spec from the S2S spec?
    • Standardize the Mastodon API instead?
    • Invest in convincing developers to implement it?

    Significant extensions of the core specifications with a view on standardizing them

    Improved security and privacy

    • Signed content
    • Private messages

    A standardized way to express terms under which content is provided

    • As I understand it, Bob Wyman calls that a Rights Expression Language
    • This probably should start with a use case collection

    Profiles

    A single-document basic [Fediverse] interop spec, ie.

    • when I have written code for everything it says, my code will interoperate in some basic fashion with all other software that has implemented this document
    • no need to consult or understand other implementations
    • may be quite basic, e.g. text content only, only a minimal set of activity types
    • enables implementors to have a “MVP”-style interop at lowest-possible engineering effort (including the time required to read/understand the specs!)
    • This could be done as a “minimal profile” of a stack that contains a subset of AP [ActivityPub], AS [ActivityStreams], and Webfinger

    Other profiles for specific use cases

    • E.g. propagation of event / calendar invites / RSVPs

    Documentation and test

    A test suite for the minimal profile

    • suitable to add to automated test suites
    • over time, this test suite can grow beyond the minimal profile

    Documented behavior of leading ActivityPub implementations

    • What subset of the spec does each implement
    • What extensions does it implement, and which are required
    • Document the “folk wisdom” how to interact with a given implementation, so not every new developer has to learn everything from scratch
    • Get out of “trial and error mode” when attempting to interoperate with another ActivityPub implementation

    A branding program for products that have passed the test suite

    • As an implementor, you get to put the sticker on your product.
    • In particular, in the places in the product where users “connect” to other servers in the Fediverse, like “Visa” is displayed at the POS terminal
    • I believe this will become critical if/when larger orgs with potentially different value systems connect to the Fediverse

    JSON-LD conformance

    • Tests to make sure implementations are JSON-LD conformant

    Libraries in the major languages

    • Full stack, not just ActivityPub

    User expectations and usability across the Fediverse

    A set of web “intent buttons” for Like, Follow, Post, etc that work across sites

    • like they exist for centralized social media
    • as easy to use for the user
    • we can argue how this can be accomplished technically. I have opinions, but for this wish list, they are immaterial, as long as I get those buttons :-)

    A design for search that meets the requirements of all relevant parties and points of view

    • This is probably far less a technical problem than one of successful communication

    Best practices for content propagation

    • E.g. resolve the “It has 5 likes here but 10 over there” issue and related.

    Improved identity management across the Fediverse

    • Easy-to-use single-sign-on across servers. Use case: I use several apps for different content types (like micro blog and video). Bonus: they all post from the same identifier
    • Easy-to-use persona management. Use case: I have a personal and a work account, bonus if they can be on the same server
    • Identifiers not tied to the domain name system

    Attract more participants

    • Get major implementors involved (e.g. Mastodon)
    • Make the place where technical work is done welcome and the work pleasant