ActivityPub could be the future
blog.digitalscofflaw.com
blog.digitalscofflaw.com
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.
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.
[0]: https://techcrunch.com/2018/02/13/amp-for-email-is-a-terribl... [1]: https://www.eff.org/deeplinks/2018/07/between-you-me-and-goo...
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.
It does not help.
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 agree that if Facebook implemented ActivityPub completely then people would not block it, and indeed they shouldn't.
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.
- 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.)
This behavior is so common it needs a name. Embrace and Switch? Embrace, grow and switch?
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.
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.
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.
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.
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.
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'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.
(Oops, I just saw toomim already posted the same thing.)
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.
Yeah, modern and shiny JSON. IT is now a subdivision of the fashion industry. Suck it up ;)
For what is this neccessary?
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.
{
"built_in": "value",
"org.example.my_extension": "value"
}
If you want to validate it, you might need to jump through some JSON schema hoops, of course.Facebook could use a format based on brainfuck and we would have to support it.
Tangent: I hate the use of "rocks" as a generic "is great" trend in our langage.
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.
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.
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).
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.
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.
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.
Maybe it's a good starting point?
JSON-LD: https://www.w3.org/ns/activitystreams.jsonld
Human-readable: https://www.w3.org/ns/activitystreams
[1] https://github.com/w3c/activitystreams/tree/master/implement...
For Webmentions on static sites, people use https://webmention.io
You can actually probably combine that with https://fed.brid.gy to interact with ActivityPub sites as well!
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.
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 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.
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.
There's some info here:
https://www.w3.org/wiki/Socialwg/2016-06-06-minutes#AS2_impl...
https://wordpress.org/plugins/activitystream-extension/#desc...
Some more basic Mastodon stats that I recently collected: https://davepeck.org/2018/05/03/mastodon-stats/
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.
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.
With all these standards, the successful ones need to find some magic moment to take off - like HTTP did.
Too early to tell if ActivityPub (which I like as a protocol very much) will be an HTTP or an XML.
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.
- The web app is very well made, although the space utilization could be a bit better
- There doesn't seem to be any concept of friends, but there is something called "follows".
- Almost every post in my timeline was in a language I couldn't understand.
All in all, nice experience but looks identical to twitter. Not really sure of any benefits over twitter.
I have the feeling that people confuse 'federated' (aka provides API access) with 'distributed' (aka does not rely on specific nodes).
Edit: meant to say Twitter and not Mastodon, to get the point across.
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.
At least you would have choices of who to trust on Mastodon, or if you trust no one then run your own instance.
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.
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.
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.
No. That's true only for some users. Also tools like Mastodon are implementing multiple accounts / account migration.
Then why did you write this sentence and not "ActivityPub is like email"?
Mastodon would be like Hotmail, right?
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.
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.
One nice side effect is that you get less of this kind of person on the fediverse.
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).
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 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.
'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.
[0]: https://tools.ietf.org/id/draft-cavage-http-signatures-01.ht... [1]: https://w3c-dvcg.github.io/ld-signatures/