Did you try reaching out to each of those major social networking websites to offer collaboration on this standard?
P.S. I understand that ActivityPub represents a radical shift from the centralised social networking, but if I remember correctly Facebook, Google and IBM previously collaborated on open widgets and related functionality until the efforts fell apart: https://github.com/OpenSocial/spec
What possible benefit would it give companies whose entire business value revolves around their data...to just give that data away to anyone?
Here's what I learned from working on the DIASPORA* project: The only people that federated/distributed social networking benefits are the 1% of nerds who know how to use it. Everyone else is hopelessly, and willingly, attached at the hip to their social network of choice. Most of the issues or feature requests fell into the following two categories:
1.) I need $FEATURE otherwise I can't use DIASPORA* at all.
2.) Why doesn't $FEATURE in DIASPORA* work like /Facebook|Twitter|Google/? If we made it work exactly like that, regardless of the fact that it makes no sense on a distributed network, we'd be able to actually compete with a $100bil social network! Wow!
Both of these are pipe dreams. With #1, the person is convincing themselves that they want to use D*, but in reality they just want Facebook without Facebook actually owning their data. #2 is the notion that a company like Facebook or Google, who both simultaneously and independently got rid of the last remaining "interoperable standard" in their business: XMPP. Yes, XMPP...once the golden boy of federated discussion platforms...has been totally deprecated by the top two implementors.
Why? Because building their own, centralized IM service is not only more lucrative, it's also a lot easier and less expensive.
The fact that anyone actually sat down and took the time to build specs for federated social networking is a miracle to me...considering there's practically zero business value in it.
You are right, but inviting them is still worth doing. BTW, diaspora* should have also been invited, but as I understand, they were.
> federated/distributed social networking benefits are the 1% of nerds
I actually tried to understand how can I benefit from a distributed social network and did not (I almost stopped using FB as well, not for the privacy reasons, but because of little utility given the time it consumes).
> Yes, XMPP...once the golden boy of federated discussion platforms...has been totally deprecated by the top two implementors. Why?
For Google it was primarily because Microsoft used their XMPP integration in Outlook but refused to allow Google to have a similar Skype integration. Somewhere on HN Googlers were writing about this. Don't remember, but I think FB also integrated Google Talk as well without allowing reciprocal integration for Google.
> The fact that anyone actually sat down and took the time to build specs for federated social networking is a miracle to me...considering there's practically zero business value in it.
Again, I agree, but there is zero value in a good spec that is followed by a single product. At least diaspora* and GNU Social should agree on this standard so that we can in future use different federated social network distros.
Truer words-. Thank you both for working on diaspora* and also for your subsequent realization that completely-unnecessary-decentralization-just-for-its-own-sake is not actually what 99.9% of people want. They just want to be in control of their data.
In any case, as other people have said, perhaps these companies didn't see the business case to participate. This baffles me a little. I can see why as the market leader Facebook wouldn't necessarily benefit financially from helping the effort, but if I were them, I'd want to at least have someone in the room, paying attention. And if I were anyone else, I'd probably see the value in teaming up and helping. But that's not what happened, so I'm clearly wrong about something. It's possible they just thought the problem was too hard and the group would never succeed, so it wasn't worth paying it any attention. My sense is it's done well enough that with more help it might have done great. But it was touch and go at many points, and I personally thought it would go nowhere until our Paris meeting, about 8 months in. It's also possible they just didn't have anyone senior enough to handle the job who had any desire to do it.
And yes, OpenSocial were one of the big motivators for this work starting at W3C (as the news announcement says). But, aside from IBM, they never actually showed up in the group. Someday, I'd like to understand that, too.
I have little hope that a spec not designed to reduce/stop harassment up front can have it bolted on later successfully.
But the Social Web Incubator Community Group has made anti-spam/anti-abuse stuff part of our mission, but that's hard stuff. ActivityPub does include federated blocklist support, but I think it's not enough. I've written about possible directions though: https://dustycloud.org/blog/possible-distributed-anti-abuse/
Vouch is a pretty clever scheme — as the sender, you include a link to someone who linked to you, who the receiver also linked to. So your server can detect, essentially, "randos" — unknown sites that might be spam, harassment, or good replies from someone who found your site accidentally.
I haven't yet implemented Vouch in my server software https://github.com/myfreeweb/sweetroll but my idea is to eventually have a settings switch that determines what to do with mentions from randos — reject, require pre-moderation or accept. Depending on your situation you'll be able to change it — e.g. set it to pre-moderation when some spam appears, or set to reject when a harassment campaign attacks you.
Only bad actors will disobey and they will have to modify their software in order to do so. This doesn't provide absolute protection against bad actors, but since most bad actors don't own a time machine, it reduces the scope of the harm they can enact.
Consider the adversary "angry ex-boyfriend." Let's assume he wasn't always angry and isn't a sociopath. By the time he has become angry, the sensitive posts have already been deleted. This makes a difference in real life to real people.
There is indeed a user-interface concern, to not over-promise to the end-user. But that doesn't justify leaving such a useful thing out at the protocol level.
I have an hourly bup backup for each of my servers, that goes to a backup host. I am not a bad actor, have not modified any software, and yet if I run an activityhub server I will have a complete timeline at 1hr granularity, so basically anything not deleted within minutes of posting.
(Considering a switch to borg backup when I have the time to really evaluate it)
You mean besides me, of course. XD
EDIT: It's a joke people, for Pete's sake.
I would not put it past Facebook (or other businesses which are addicted to harvesting user data) to behave badly against networks like this. However, for the sake of their reputations they'd still probably do it quietly, which means many of the person-to-person attacks that deletion protects against would still be thwarted.
This is a problem the same way Facebook's privacy controls are a problem. Facebook themselves are not bound by them, but they're still useful if you want to protect your data from other users of the platform.
And FWIW, I think most of the big crawlers respect robots.txt - this is the same sort of thing.
Reasons to be skeptical of it: well there's the obvious ones, you might want to hold on to some content coming your way and lots of people are disappointed to see things disappear. Mutating networks have some dangers for sure.
Reasons it to want it, or that it's there: well, this is how all the existing federated social networks work. ActivityPub was designed in the context of standardizing basically something that projects like Mastodon, Diaspora, MediaGoblin, GNU Social, etc can use. And that is how things work now... mutation and federated deletion has been part of the existing federated social web for a decade. And we're trying to build something people can hook into their existing systems. People may also change their minds about things. Should they have the authority to remove their own posts? An open question, but at the very least, whether a server removes the content or not, a Delete is a request to do so across the network.
However, yes, there is an alternative structure one can imagine for these things, and that's something a bit closer to something git-like in the way that branches point at commits, but may change at which commit they point to over time, but the commits themselves never change. That's a desirable thing to explore, and I've blogged about it: http://dustycloud.org/blog/an-even-more-distributed-activity...
And we're even looking at exploring it, possibly, in the Social Web Incubator Community Group: https://www.w3.org/wiki/ActivityPub_extensions#Possible_futu...
BTW, if you're interested in such things, the community group is open to everyone and is hosting weekly meetings https://www.w3.org/community/swicg/ and we'll be hosting a meeting next week https://www.w3.org/wiki/SocialCG/2017-05-31
However, I think one of the big things that cryptonerds and other people deeply involved in developing this type of technology overlook is that most people don't want a system that tells them "good luck retracting anything you ever publish". Integrating this as a "feature" is actually an active barrier to adoption.
Yes, it's true that you can't ever guarantee all copies of something have been destroyed after they've disseminated, but you can still provide the facilities necessary to signal that the content owner wants that to happen, and create an expectation that blessed clients will observe that signal internally.
We need to provide mutability at least on par with the current experience if we expect one of these alternate social protocols to pick up steam. These are popping up like flies recently, and most overlook this.
Additionally, though the technology can't force other instances to delete things, other concerns perhaps can. Consider the potential legal implications of deliberately ignoring delete requests.
What we don't know (or what we've forgotten) is how to get people to use federated systems.
We need to make these things easier to host and deploy though. Having worked on MediaGoblin for many years now, I've found the most depressing part of it is that not only is it hard for people to start hosting things, it's even harder for them to keep it running... and it's not just MediaGoblin; you'll find this of most social network things. Most especially, people become afraid to upgrade their systems. I'm hopeful that systems like Guix will help in that regard, but that's a whole direction to explore itself: https://media.libreplanet.org/u/libreplanet/m/solving-the-de...
For context, that's 3 days' worth of Twitter signups.
Evan Williams, a Twitter founder recently said: “I thought once everybody could speak freely and exchange information and ideas, the world is automatically going to be a better place. I was wrong about that.”
It would really be good is some of the actions e.g liking, following, were more generalized.
For instance, instead of "like" you could have an entity called "Response" that could refer to a comment/like/upvote/downvote etc
MicroPub and ActivityPub grew out of the same working group, because the two camps couldn't find shared ground.
I don't know if they managed to get a decent mapping between ActivityStreams2 and Microformats2 at least.
This seems like a very constricting protocol, though: the one-to-one correspondence between a user and a server means I need to individually post my activity to the "inbox" of everyone who wants to read it (or they poll my "outbox" - I'm not sure). Not a recipe for an efficient system. It's called ActivityPub, so this was clearly a design decision to meet the goal of being decentralized.
But I probably wouldn't implement this standard in a project unless I modified it a bit so that many clients could share a server.
That way the receiving server can only get POST'ed to once and distribute to the appropriate followers.
Of course, for more limited distribution posts, you still have to distribute individually, but that's no different than how email works.
but that's not a problem massive centralised services can solve.
If you put your data on someone else's computer then who REALLY has control of it?
whom you trust is of course your choice
and theres no "one size fits all" re any of it.
That wasn't about federation.
the scope of it was closer to webapps.
remember Google Gadgets?
it was pretty much based on and extending that.
btw I think from memory Myspace was part of that group and implemented some parts of the opensocial spec.
I don't remember Facebook being involved with Opensocial.
While someone else pointed out the rest of the URL could conceivably point to different content, in practice, it seems like most deployments have a 1:1 correspondence and will redirect from http://(.) to https://(.) when SSL is deployed so this is not so critical for the http(s) case imho..
Adding 'Build ActivityHub test server' to my ever growing to-do list! If we build it, THEY* will come.
*Everyone else, obv.
BuddyCloud is a parallel track to OStatus, possibly inspired by the OStatus predecessor OpenMicroBlogging, but I don't know that. Both tracks came about around the same time a decade ago.
SubNode -> http://sbnode.com