
ActivityPub: a federated social web standard - paroneayea
https://www.w3.org/TR/activitypub/
======
smarx007
The standard is awesome and looks well-designed. The biggest issue is that it
was lead _solely_ by the people around Mastodon/Pump.io/Mediagoblin. While not
a bad thing per se (on the contrary, it shows a commitment to a free
internet), it means that there is little chance for it to penetrate the
general (social) networking scene (Facebook, LinkedIn, Twitter, VK etc.).

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](https://github.com/OpenSocial/spec)

~~~
tomphoolery
> Did you try reaching out to each of those major social networking websites
> to offer collaboration on this standard?

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.

~~~
BugsJustFindMe
> _but in reality they just want Facebook without Facebook actually owning
> their data_

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.

~~~
dnel
Decentralisation provides no benefits to users, only burdens. Federation is
there to provide scalability and resilience to admins and designers of the
network. The ultimate federated social network is the one that does not need
to mention it at all to users because it has zero impact on how they use it.

------
windlep
Small section about how Spam should be handled somehow by a server. Sigh. How
about we build a federated spam/harassment prevention system first?

I have little hope that a spec not designed to reduce/stop harassment up front
can have it bolted on later successfully.

~~~
ForHackernews
It's only a "candidate" so far, maybe you can add some suggestions?

~~~
graphememes
I believe they did give a suggestion, to build it before making the assumption
that it works.

~~~
placeybordeaux
It might be higher value to submit a github issue:
[https://github.com/w3c/activitypub/issues?utf8=&q=is%3Aissue...](https://github.com/w3c/activitypub/issues?utf8=&q=is%3Aissue%20spam)

~~~
graphememes
Why haven't you done it then?

------
devrandomguy
So, about that federated DELETE operation. In a decentralized network, we
can't unilaterally delete a shared piece of content; that is one of the main
features of decentralization. Even providing that verb seems kind of deceptive
to me; it implies that content that enters the network, could conceivably be
purged, which will affect how people use the network. Perhaps DISOWN would be
a more accurate verb, especially if it would only be accepted from the
original owner.

~~~
HerraBRE
If the social contract says "delete things when you see a delete message",
then that's useful in a federated environment.

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.

~~~
nercht12
>> most bad actors don't own a time machine

You mean besides me, of course. XD

EDIT: It's a joke people, for Pete's sake.

~~~
devrandomguy
Actually, this is a real issue. For one, there is the Wayback Machine, which
could very well see increased usage and mindshare as legally mandated content
takedowns increase. For another, if, say, Facebook wanted to harvest data from
this network to create shadow profiles and flesh out missing patterns in their
analytics, then they could easily follow everything, keep the raw data/content
internal, and never develop the ability to retroactively un-analyze that data
when a delete request comes in.

~~~
HerraBRE
This is a legitimate concern.

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.

------
bct
We know how to build protocols for federated systems - there must be at least
a dozen serious efforts at federated social media by now.

What we don't know (or what we've forgotten) is how to get people to use
federated systems.

~~~
paroneayea
It's tricky, though people are using them. Mastodon probably is seeing the
most success at the moment. Over half a million users by current estimates.
Not everyone who signs up stays around, but there's still quite a bit of
retention. We could do better.

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...](https://media.libreplanet.org/u/libreplanet/m/solving-the-deployment-
crisis-with-gnu-guix-f8fd/)

~~~
dmd
> Over half a million users by current estimates

For context, that's 3 days' worth of Twitter signups.

------
deft
Cool, open standards are a good thing :) good discussion going on here:
[https://github.com/w3c/activitypub/issues/](https://github.com/w3c/activitypub/issues/)
if anyone has questions on the protocol or just doesn't understand some of the
writing.

------
NoGravitas
This is neat stuff. I see immediately how it interacts with things like
Mastodon and MediaGoblin. I'd like to see how it could be made to interact
with IndieWeb stuff. Particularly, how minimal could you make an ActivityPub
server and still have it federate with the things you want it to federate
with?

~~~
floatboth
Hopefully someone will make a brid.gy type thing that would just convert
ActivityPub server-to-server notifications to Webmentions…

------
avivo
Social networks function in the context of society. Which is messy. Developing
a system that doesn't have very harmful failure modes is not easy. And if it's
a federated standard, there is no easy way to fix it after the fact. I'd
recommend that anyone working on something like that (or really any social
network) read this:
[https://www.twitterandteargas.org/](https://www.twitterandteargas.org/)

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.”

------
j4pe
I really like the idea of a social web standard.

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.

~~~
epeus
Have a look at the related w3c spec WebSub that is designed to deal with this
issue: [https://www.w3.org/TR/websub/](https://www.w3.org/TR/websub/)

~~~
detaro
Which many may know as Pubsubhubbub, with only minor changes and a new name.
(Which is a good thing: no need to make up a new protocol if there is already
one in the wild that works)

------
max_
I think It looks more like a mashup of Facebook & Twitter.

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

------
benwerd
ActivityPub is awesome, and I'm excited that it's reached this stage. Looking
forward to the core Known platform supporting it.

~~~
praveenster
Adding a link to Known to get more context regarding comment above:

[https://indieweb.org/Known](https://indieweb.org/Known)
[https://withknown.com/](https://withknown.com/)

------
Mike101
"They just want to be in control of their data"

sure .. 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.

re: opensocial

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.

------
devrandomguy
Looking at the ID format in the first example, I have to recommend against
including the protocol ("https:") in a key/ID. This makes it hard for people
to later upgrade from HTTP to HTTPS, because it breaks all of those
references. It also makes it hard to try out new protocols side by side, like
IPFS.

~~~
blowski
A URL _always_ includes the scheme.
`[http://www.example.com/1/](http://www.example.com/1/) ` and
`[https://www.example.com/1/`](https://www.example.com/1/`) could represent
different content. If you want to change the scheme but keep the old links
working, you need to redirect from the old to the new.

~~~
Filligree
That is the definition of a URL, but not a law of nature. If these keys would
be more useful with the scheme being implicit, then perhaps they shouldn't be
URLs.

------
Jaruzel
I like this. Very Much.

Adding 'Build ActivityHub test server' to my ever growing to-do list! If we
build it, THEY* will come.

*Everyone else, obv.

------
eevilspock
I don't see any mention of encryption in this standard. Are all messages
public? I'd like to see this using public and private keys so that it is
guaranteed only intended recipients (e.g. people on my friends list) can read
my messages. This is especially important given the federated nature of this.

------
crudbug
The BuddyCloud [0] project also came up with a standard proposal. Is this
related to that work ?

[0] [https://github.com/buddycloud/buddycloud-
xep](https://github.com/buddycloud/buddycloud-xep)

~~~
clacke2
Not at all. ActivityPub comes from pump.io, which was based on the experiences
with OStatus.

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.

------
fergazen
Interesting standard. I'm also working on an app that you would categorize as
an open source social media platform:

SubNode -> [http://sbnode.com](http://sbnode.com)

