I like Mastodon and ActivityPub, and I like that they're seeing relatively broad adoption. That said, I'm not hopeful for the future. If it ever actually sees broad adoption beyond the tech community, all Facebook or whatever comes next has to do is incorporate ActivityPub posts into Facebook, perhaps even send back Facebook comments to those posts, but not publish Facebook-originated content. At that point, you can either be on Facebook and follow all your Facebook and ActivityPub friends, or use Mastodon or whatever and only follow your ActivityPub friends.
And even if Facebook does not do that, if a particular ActivityPub client becomes wildly popular, it could do the same, much like how Google Talk started out as interoperable with XMPP, only to ditch it when Google Talk was popular.
I think that most instances would block Facebook if they tried to do something like that. They'd have nothing to gain and everything to lose by allowing FB to get away with it.
As for your other point, it's also possible it will go the way of GMail, which is still compatible with other email providers. I think a large part of it depends on how big ActivityPub gets before a GMastodon appears.
Email is pervasive and decently well diversified on the web, with multiple email providers, and many businesses and users not being on GMail, partially due to inertia (they already had an email before GMail became big). Maybe GMail could afford to cut off emails from external providers, but it would be a big risk, and it would definitely break a large part of the web.
If ActivityPub does the same, with websites integrating it into their user experience, and news organizations and businesses self-hosting or joining various instances, I expect it would gain the same kind of resilience as email for when a GMastodon shows up.
So I'm not too pessimistic about this. The more pressing concern is increasing adoption, IMO.
Also its virtually impossible to be smaller than a few hundred mails to gmail a day as a server and not have your mails instantly spamboxed. Yes, i have gone through the laundry lists of things it could be, and stuff i should set up.
If Google wanted true lock-in they could implement a Gmail-only end-to-end encrypted protocol. Ironically, that's the only thing they don't want to do.
"I think that most instances would block Facebook if they tried to do something like that."
I don't think so. Doing so would mean that their users wouldn't be able to get events from the biggest network; the one where most people are on. While today, most users of ActivityPub are likely to be people who are against Facebook and not wanting to interact with it, if ActivityPub becomes huge, then more people would be using it that are ambivalent about FB or even users of it. Blocking FB would mean that those people leave the instances, because they're no longer able to get a significant amount of their messages.
I've thought about it more, and it's a tough question. If Facebook did allow Facebook users to see and interact with ActivityPub posts, but didn't allow other ActivityPub instances to see Facebook posts, there would be three types of instances.
There would be FB itself, of course. Then there'd be AP instances, short for ActivityPub instances that don't block Facebook. And finally, there'd be AP-FB (AP minus FB) instances, short for ActivityPub instances that do block Facebook.
FB accounts can interact with AP but not AP-FB. AP-FB can interact with AP but not FB. AP can interact with AP-FB, and only partially with FB.
If there aren't many people on AP-FB instances, then the incentive for people on AP is to jump straight to FB, because that's where you have the most reach.
If there are a lot of people on AP-FB instances, then there's some incentive to jump to AP accounts, because then you can interact with AP-FB and Facebook people can see your posts, even though you can't see theirs. It's not clear how strong this incentive would be, though, because people being able to see your posts might not matter if you can't see theirs.
If every instance is AP, they lose users to FB, so they have an incentive to coordinate to make a strong AP-FB block. But if there's a strong AP-FB block, AP-FB people would have incentive to jump to AP. This is likely to stabilize with FB winning, if the incentive is strong enough, so we could have a Bad End.
This means the correct game-theoretic solution, as far as I can tell from my armchair, would be for the AP-FB block to coordinate and block not only FB, but also AP instances, so that there'd be no incentive to jump to AP.
So it would all depend on how well instance owners can coordinate, and how willing they'd be to block AP instances, who could be framed as "defecting". I have no idea how that would turn out; humans have been known to coordinate, but also been known to fail to coordinate. It's something we'll see in the future, if Facebook ever partially implements ActivityPub.
Well, what would probably happen is that Facebook interactivity would be some kind of plugin, which instance runners would have to enable (and possibly configure). Convincing them to do so may not be easy.
The big challenge for publishers right now is censorship. Platform censorship happens in many ways:
- Visibility hidden because an algorithm in a non-chronological news feed thinks your content won't get enough engagement
- Visibility hidden because you aren't buying advertising
- Account banning or throttling because of grey area content (everything from nipples to politics)
- "De-monetization" (Youtube specific)
Most people using the internet are now aware of these problems. It used to be a fringe issue that like people doing SEO and spammers thought about.
Will it be easy for a platform to convince content publishers to return after it has chased them off the platform?
Facebook's usage exploded just as Myspace's was struggling to keep their servers up and was users were being hammered by very invasive ads. Once those users started logging on to Facebook instead, they never looked back. May be it was inevitable, but there was a very clear value proposition to users and it benefited Facebook immensely. The users were literally chased off of Myspace, by Myspace, and went to Facebook.
My hope is that we will get open protocol adaptation instead of startups building another walled garden to replace Facebook/Twitter/Instagram/Youtube. Open protocols are better for everyone, including startups.
(and few things scare me more than a startup that is going to "fix email" by creating a new walled platform.)
Censorship is not the root problem. The root problem is spam. For example, the main reason that we all choose one of the giant tech corps to host our email is because of spam. Spam defenses are why it's so difficult to run your own mail server these days. Thus spam causes email provider centralization even though though there is no network effect lock in. Then with centralization you get the secondary problems such as censorship.
ActivityPub really needs some decoupling of identity from server. If a server I'm using starts acting up, the answer is to move servers, right?
But, wait, my 50K followers from Server A won't be following me on Server B. Essentially, you only get to pick your original server once, without having to rebuild your network. So choose wisely!
This obviously isn't an easy problem to solve. You'd need to separate identity from hosting, and have some way to look up "identity A is on server D" so peope following identity A know where to get the content.
I truly believe it's essential to the success of the protocol, though.
I'll take it a step farther. One of the consequences of building a distributed network is that individual nodes are much more likely to fail than a centralized node. The overall network health is going to be better, but for a given random article or person you find online somewhere, the odds that the server does something screwy are a lot higher because the server is smaller and has less backing.
It's not just about separating identity from hosting so that content creators can move around - content itself needs to be separated from its hosting. I want to be confident that if I share a link to some content, that content is still going to be available at that link 4 or 5 years from now. Minus that solution, in some ways ActivityPub actually makes my life worse because it means content moves around more often.
Mastadon and PeerTube are great examples of this - instances are not an implementation detail of these platforms that we could swap out later for something more robust - they're a core concept that's talked about at a user-facing level. That's insane to me. Why on earth do we even have the concept of an instance or a server? Why is it baked so hard into our protocols as to guarantee that we can't possible get rid of it in the future?
Sure, someday maybe IPFS will completely solve the problem and we'll switch off of URLs. But probably not soon. So we should be trying to find mid-term solutions that allow us to separate identity and content from a location regardless of whether or not we're using IPFS. We should be designing everything around that constraint.
I think there are a lot of blockchain projects working on exactly that issue now - I like to think about an internet that is totally distributed yet (because of blockchain) totally secure. I'd like to think it would make the internet at large even more secure, avaliable, and faster, but I don't know enough of the technicals to know if that is actually feasible or just a pipe dream.
This is what the whole IndieWeb movement is about -- being distributed rather than merely federated. I'm mildly concerned that the two camps seem to be building their own protocols rather than working together (excepting the existence of Bridgy Fed, perhaps).
Good point -- it would actually be simple to combine IndieWeb + Mastadon and solve this problem.
IndieWeb's solution is to own your own domain: https://indieweb.org/personal-domain. If you control your DNS, you can move your data to a different back-end provider and just update your DNS entries.
To combine this with Mastadon, just make your own domain, like https://chipotle.coyote, and point it at Mastadon-Server-A. Then if you want to move everything to Mastadon-Server-B, just copy the data and update DNS.
I agree with you but for the general social medial user updating the DNS records sounds scary and complicated. And for such user even if the idea of owning their own domain might sound compelling, how many will simply forged to renew the domain, be done with it and move to the next facebook.
I'm not sure it does solve the problem. Extreme example, but when you die, won't your domain registration lapse?
And you can argue that doesn't matter at that point, but it kind of does if I want to be able to use a social network for something like collective scrapbooking or time capsules. Or even just if I want to make sure that essays, projects, and Open Source work are permanently accessible to people who care about them.
Competition is good, but cooperation is also good, and protocols benefit enormously from network effects. (No pun on network protocols intended.) I suppose this isn't zero sum, though, strictly speaking.
It is social media, why does this need to be handled at the protocol level? Post a final message on the "You@ServerA" account saying "This is my last post here, keep talking to me with my new account: You@ServerB"
Anyone who visits your old account will see the last message. Anyone who sees that message and can't muster the effort to make 2 mouse clicks probably isn't a follower except from a numbers perspective.
If you're content losing 90% of your followers because the server you host on decides to implement draconian censorship or start charging $50/mo, then yeah, be my guest and use the protocol as it is.
I personally think tying identity to a particular server instance is the wrong approach, whether you can beg your followers to come find your new location or not.
Also, your method only works if the server is still up. If your host server is taken down indefinitely, then you truly do get to rebuild your network again. Fun.
As a human, social, user of Mastodon, yes that's totally fine with me. 50k followers is absurd, I have maybe in the 100's of social connections, and realistically only maintain in the dozens of meaningful conversations with people. I just want a means to have those connections that's not feeding some omnipotent beast.
I'm assuming your values are something else. Do you monetize your social media followers/follower count in some way? For some professions it's smart and necessary, but for my career it's not relevant in any way at this point.
I'm thinking of business use-cases, yes. For instance, I agree with you, if my personal twitter was lost, I wouldn't lost any sleep over it. But if my business twitter was lost, which has almost 1500 followers and took years to build up, I'd be pretty upset. And I don't have a deep connection with all of those followers, but if 10% of them see each post I make, that's a lot of marketing value to me.
Damn, let's ditch all the XML protocols then, XHTML first :D
What does "age of JSON" means exactly? Those are two different technologies for different purposes.
Even if XMPP tried to move to JSON, how can you do namespaces in JSON for example?
You want ActivityPub in XMPP ? Just take Pubsub and put Atom in it, those are two stable and proven technologies, they fits perfectly (it's just one namespace in another) and with many many benefits.
Here is a news feed built on top of XMPP Pubsub https://nl.movim.eu/?node/pubsub.movim.eu/Movim, and yes there's also an Atom 1.0 feed generated from it, because it's easy to just extract the (validated) Atom content from Pubsub and put it back to a proper HTTP page.
Nsmespaces allow XML file formats flexible and extensible in interesting ways: each namespace is tied to an independent schema, allowing for a very natural nesting of validatable XML in arbitrary formats. The namespaces avoid name collision between XML tags from different schemas. The grandparent gave a good example of this kind of nesting.
JSON is incapable of the same kind of nesting because there are no explicit namespace to identify nested data formats and to avoid name collisions.
Yes, it's a nice option for some settings. But why is it neccessary in this context? Where there is a defined data-exchange format which would not have name collisions happen?
XMPP as an extensible protocol (it's even in the name!) relies on XML namespaces to avoid collisions between extensions. Were it to use something like JSON, extensions would all have to be aware of each other so that no naming collisions or other awkward behaviour can occur.
Not necessarily. With the right controls implemented, you can decide how much you want your instance to interact with other instances, but it depends on the implementation. I don't know if masotodon is able to control this, and it might not make sense for them to do it.
In Peertube at least, you need to manually specify which other peertube instances you want to 'follow'. Other instances can also unilaterally follow your instance.
I don’t know. It feels like SOAP - or XML-RPC. These protocols that are just layered on top of HTTP keep coming, but they never seem to gain adoption. In part because - what are static websites supposed to do to participate?
This was the beauty of RSS. I didn’t love RSS, because it eliminated all the styling from blog posts - but it did achieve real widespread usage.
You can syndicate static websites with ActivityPub, pretty much the same way as you do with RSS, except you're generating JSON-LD (ugh) rather than XML (ugh). I've seen a proof-by-example, but I don't have the URL where I can easily find it. The downside is that Mastodon, the most used AP server, doesn't provide a way of subscribing to a static AP feed (it might work if you also had a simple webfinger script to point to it).
I actually like the 'eliminate all the styling' feature of RSS. It's kind of a pleasure to read blog posts and news articles in my mobile feed reader (tt-rss for android).
Except for when the content wasn’t included. That was the problem with RSS. It could never decide whether it was supposed to be distributing the content or distributing notifications of the content.
That decision was made by the drive for “pageviews” both by ad-driven pages and others that just wanted to know how many people were reading.
It was also made because quite a few services used RSS feeds for uses like auto posting bots and what not, where they got information from a blog/news site and posted about on their forums/social media service. In those cases, you didn't want it to post the full article.
I appreciate the pointer! I expect that ActivityPub is the right idea, but just needs to be refined by competitors. Much like XML-RPC and SOAP eventually gave way to REST. It could be the real deal, though.
I wouldn't mind if AP-using projects like Mastodon also let you subscribe to RSS feeds. That way RSS could keep doing what it's good at while AP handles everything else.
> what are static websites supposed to do to participate?
Yes the challenges of hosting applications (anything that serves dynamic data, like an ActivityPub server) on the internet is a real problem. Hosting a static site is easy, you have lots of choices, and it's highly portable. Don't like your host? Move.
But at the moment, hosting anything dynamic is an order of magnitude more complex to set up and to maintain. You either have to spin up a whole VM, or go to closed "serverless" providers.
I just started working on a project that I hope will make hosting personal server apps trivial.
I saw the article and thought I'd add ActivityPub support to my site, but it looks like static sites can't really do ActivityPub, is that right? I'd need a server to do the posting/receiving.
While that's true of ActivityPub, the data format it uses (ActivityStreams, which a form of JSON) could be hosted on a static site separate from the HTML version people are reading, which would at least make the content reference-able on the ActivityPub federated network.
Yes, it's about medium effort if starting from scratch with no background knowledge. Mainly because I'm not sure there's any good existing tooling to convert articles to AS. And it wouldn't be complex to implement, but does require some solid time learning the vocabulary, which is intimidating.
Third party services are very helpful and I'm grateful for them, but I wish it were easier to host personal server applications on the internet. I'd like to be able to host an ActivityPub server myself with only a minimum amount of fuss.
To my knowledge, yes. Though in theory it should be possible to cobble together a static file version that is atleast capable of returning enough data that other users can see it as an AP post and share it, though liking or replies won't work.
I wonder what is the best practice for building a search engine or mining data around ActivityPub. Centralization comes naturally when a search engine or analytics is needed.
I imagine a good search engine can be open sourced and data be available to anyone to analyze but the eyeballs and ads will end up in a search engine like Google.
Search - or more importantly, discovery of content - in a decentralized/federated ecosystem is where google should experiment on a bit more. This is where there is a gap in the decentralized/federated arena. (I acknowledge this even though I am a proud supporter of decentralization!) If google can bring value in this arena, then they can pivot their G+ product and offer it as an underlying platform to provide ActivityPub clients, etc. It could be used to undercut facebook, etc., and make G+ less of a ghost town. For example, people use GSuite to use the gmail email front-end, but leverage their own domain name. What if google pivots G+ to be an activityPub server, allowing paying customers to leverage their own domain name (on google's infrastructure) to interact with the fediverse? And for those users who don;t know/care about decentralization, they think they're getting their own "instance of a social network maintained by google".
I think there is a market for this.
The short version would be that AP would mean you could get the benefits of both having an RSS Feed and a Comment Section without having to run either as a seperate plugin.
If WP had an AP Plugin, people could follow your blog from their Mastodon Account or Plume or any other platform that allows following. They can share and like your blog and that gets federated back, you get those directly to your blog.
People can respond to your blog and it would show up as comments and they could discuss it off and on your blog.
Though I don#t think AP is panacea, I do think it could enable a lot of interop between previously disconnected platforms.
As the author says, you can follow my blog from your Mastodon account, so you see my posts as Mastodon toots, and you can reply to them and leave a comment on my post. I don't know why there isn't a Wordpress plugin, I guess nobody wrote one yet.
And will all of your followers’ comments show up too?
Is this essentially just the same as the trackbacks I already get from other Wordpress posts that link to my page, but with every single tweet (or rather, “toot” (oh, pardon me, how rude. Can you please tell me where the bathroom is?)) generating a trackback?
If you don't want a specific person's comments? You'll need moderation or blocking tools.
If you don't want any comments from the fediverse in general? Well then activity pub doesn't benefit you at all and you have no need for it.
> Is this essentially just the same as the trackbacks I already get from other Wordpress posts that link to my page, but with every single tweet (or rather, “toot” (oh, pardon me, how rude. Can you please tell me where the bathroom is?)) generating a trackback?
You can interact with people's content from any interoperable website/service/client basically. It's not just a link on some site or a meaningless metric that gets bumped up. The comments may very well be from people who actually did read your blog post and genuinely want to interact. They just don't have to actually visit your site to do any of those things.
Mastodon reports ~110k weekly active users and 121M "toots" across its 2+-year lifetime. That's impressive for a federated social network but, for comparison, 121M new tweets are generated on Twitter about every six hours.
How many tweets were generated when Twitter was about two years in? Early growth curves on social networks are exponential, there's plenty of time for Mastodon or an as-yet-to-be-created network to eclipse Twitter as it starts to decline.
EDIT: According to https://blog.twitter.com/official/en_us/a/2011/numbers.html it took about three years and two months for Twitter to hit a billion tweets. That's well within what Mastodon could hit with "exponential growth", though I'm guessing Mastodon will fall a bit short of that rate.
I started using mastodon after realising that SDF had set up an instance, and I only had to activate my SDF account.
So far, so good. Social stuff is neat again, I don't get my bandwidth wasted for ads and I can trust my provider.
Hopefully this becomes the norm!
This makes me realize that I got my SDF account in 2008 when I was 16, no questions asked, and I was unemployed. Now I've got a job and I can finally sign-up for a recurring payment/support account.
The reason behind HATEOAS was that REST was in practice being watered down from how it was originally envisioned, so proponents of the original vision needed a new term.
I don't think that your origin story being "well we needed a way to tell all the practitioners they were consistently doing it wrong" is a good indicator of potential success.
On January 12, 2017, the founders announced that the platform App.net would be shut down on March 15, 2017.[13] However, due to a significant number of user data export failures that deadline was extended until March 16, 2017. App.net finally ceased to operate as a social network at 2017-03-17-06:45UTC. The source code for App.net was made available on their Github Page.
How is a site like mastodon.social different from a site like Twitter? There is no guarantee that the site will continue to operate or continue to provide API access.
I have the feeling that people confuse 'federated' (aka provides API access) with 'distributed' (aka does not rely on specific nodes).
From the customer standpoint, I think the only real difference is that you could host your own instance and take part in the network yet still "own" your posts. I say "own" pretty loosely since they get broadcast across the network.
But in this case, even if mastododon.social went down, your posts would still be available on the network and through your own (and other) mastodon instances.
In terms of the API, this is a open source project and it needs to communicate with other nodes in the network; I believe this puts real limits on how much they can change the API.
But is running your own instance worth anything? People use social media mainly to gather followers and likes. So there needs to be a reputation at play provided by the service provider to make sure those are real. Having a gazillion followers and a trillion likes on your own instance will not make you a celebrity.
Social media doesn't have to be about celebrity, or about promoting a personal brand. The big silos have promoted this use case because it aligns with their advertising incentives. But connecting with people with similar interests is another use case, as is keeping up with your friends and family.
I also think you misunderstand how following works on the Fediverse. My main account is on a small server with about 400 users, about 50 of which are active daily, I guess. But I have around 1000 followers, almost all of whom are on other instances (probably 20 or so are on my instance).
Posts to an individual mastodon server get shared across the network, people from other instances can "follow" your account (on your server) and their instance will subscribe to your posts. They can "like" or re-post your post (with or without a comment) to get your account (on your server) more visibility and possibly more followers. In that regard I think these ideas are present, but now there is more than one server.
This is only my opinion, but I think the gathering of followers and likes is something that the commercial product requires in order to keep people engaging with a product that they might otherwise put to the side.
I can see a celebrity or official or someone wanting to run their own instance to be the "canonical" or "verified" one, like, "This really is The Rock, because the instance is from TheRock.com, their website."
> I have the feeling that people confuse 'federated' (aka provides API access) with 'distributed' (aka does not rely on specific nodes).
I think you mean federated vs. decentralized since federated is also distributed.
And before people jump into a blockchain discussion remember that blockchain ⊂ decentralization, so, in general, you (probably) don't need a blockchain to decentralized an application.
The info 'xyz liked this post' is not distributed as far as I know. It's not cryptographically signed or anything. It's just to be believed based on the reputation of the site the post is on. Or am I missing something?
'Like' is a kind of message on ActivityPub, and it can be sent from one instance to another (decentralized like email, not distributed like BitTorrent). All messages are signed by the originating server (using HTTP Signatures [0]), so you can verify that the message is actually being sent by that instance, that it has not been tampered with, and that the user the message is attributed to is a user on that instance.
There's also an option in the spec to sign message contents with JSON-LD signatures[1] using a key pair specific to the user. Mastodon and Pleroma don't use these because they're considered unnecessary and may have certain drawbacks.
Federated does mean that the network overall does not rely on a specific node.
There is no true Mastodon instance, mastodon.social is merely the biggest. I run my own mastodon instance and can federate just fine.
Federation is distributed to some extend. However, unlike pure p2p where everyone has a node, it's more like little towns and cities where people live together voluntarily. Each one is a different size, each has it's own rules and if people don't like the rules, they can leave and go elsewhere.
You're asking "how is a site like Gmail different from a site like Twitter?" If Gmail goes down, you can get a different email address elsewhere and still talk to everyone. If Twitter goes down, you can't get a Twitter handle elsewhere and still talk to everyone. Mastodon is like email.
What drives people to use social media is gathering followers and likes. You will lose those when your provider shuts down or shuts you out. And you cannot get them back.
> What drives people to use social media is gathering followers and likes.
I don't think that's true for all users, and maybe not even most. I'm not even sure that the people for whom it is true are key to other people's desire to use social media.
OTOH, persistence is key to social media where transssctionality is key to email, so losing a social media handle has a bigger impact on a social media user per se than does losing an email addresses to an email user.
Depends on who you define as 'you'. If you are 'jbb67@mastodon.social' and mastodon.social goes away or kicks you off their server, there is no more 'you'.
You would lose all subscribers, likes, comments etc.
Then you would have to find a way to prove to 'your' old friends that jbb67@someotherodomain.com is the same person as the person that formerly was 'jbb67@mastodon.social'. And have some of them follow you again etc.
The same process as if you changed from Twitter to Facebook.
you make this sound like a big painful process. i have lots of alts on fediverse on servers running difference AP and OStatus implementations and i've moved my main many times over the years. it really doesn't take that long for people to realize that you moved and what your new main is. hell, i used to update my avatar and display name daily while bouncing between different alts and people could still recognize me.
based on my experience on fedi, i think you are exaggerating the fragility of the connections you make on social media. clicking "follow" isn't a lot of effort and people will do it when they recognize your voice coming from a new source.
What you note is not as painful a thing to most...But I'll grant you that to some it still is a thing. Here's where owning your own domain name helps avoid falling into this type of trap.
Having your own domain name represents YOUR identity/persona on the web - nay, overall internet in fact. The focus here is on the portion AFTER the @ symbol. Yes, unfortunately for now, owning your own domain - for the purposes of interacting with other instances and people via these federation-type of technologies - also involves the overhead of hosting your own mastodon, gnu social, pleroma, ActivityPub server, etc. But in the future, it could be that the underlying mechanisms could be made much easier and cheaper both to use and to switch/jump...and for the most part you only need to hold onto your own domain name...and can switch to different underlying mechanisms/technology/providers/whatever...but the top-level identity is preserved as you cross to other instances, etc. Within the indieweb community - a community that supports efforts like ActivityPub, etc. - owning your own domain is usually the first step...because it represents the formal establishment of YOUR identity. An identity that you control, and where your friends/followers can always know and follow. I imagine in the future if more people adopt the practice of obtaining and sticking to using ONLY their domain name as an identifier, much of this will be easier and some it simply a moot point.
The process if you changed from Twitter to Facebook involves everyone you know also changing from Twitter to Facebook. The process of changing from mastodon.social to social.coop does not.
There is currently limited support for account migration in Mastodon, and ongoing discussions about how to improve it. It's not at the level that it's at in Hubzilla, but it's not a lost cause, either.
And even if Facebook does not do that, if a particular ActivityPub client becomes wildly popular, it could do the same, much like how Google Talk started out as interoperable with XMPP, only to ditch it when Google Talk was popular.