
ActivityPub: decentralized social networking protocol - ingve
https://www.w3.org/TR/2018/REC-activitypub-20180123/
======
kemenaran
This protocol is a successor to OStatus (GNU Social), and mostly made by the
same people.

From what I remember, Mastodon switched from OStatus to ActivityPub a few
releases ago. In the past they had to extend the OStatus protocol for private
messages, which meant some clients may not honor the private status of theses
posts. ActivityPub has private messages defined properly in the spec.

It seems PeerTube
([https://github.com/Chocobozzz/PeerTube](https://github.com/Chocobozzz/PeerTube))
will also use ActivityPub.

~~~
carussell
Last summer I tried untangling the OStatus/pump.io/ActivityPub/ActivityStreams
nest hoping to piece together a big picture mental image based mostly on what
Wikipedia has to say, and found it mostly frustrating.

For anyone who's similarly curious or confused, LWN published a pretty great
overview last month—their "Federation in social networks" article:

[https://lwn.net/Articles/741218/](https://lwn.net/Articles/741218/)

~~~
Xeoncross
Thanks! After reading that article I'm curious where public key cryptography
fits into this.

~~~
rogerbraun
In AP, messages are signed with http signatures
([https://tools.ietf.org/html/draft-cavage-http-
signatures-09](https://tools.ietf.org/html/draft-cavage-http-signatures-09)).
OStatus has a similar mechanism called salmons, which are signed XML payloads.

~~~
Xeoncross
server-to-server signatures are a good start, but what about encrypting
messages end-to-end? I assume the servers already talk over HTTPS.

~~~
paroneayea
Hello! Co-editor of ActivityPub here. I wrote a paper for Rebooting Web of
Trust on how this could be done: [https://github.com/WebOfTrustInfo/rebooting-
the-web-of-trust...](https://github.com/WebOfTrustInfo/rebooting-the-web-of-
trust-fall2017/blob/master/final-documents/activitypub-decentralized-
distributed.md)

~~~
Xeoncross
Thank you! Important part starts half-way down:
[https://github.com/WebOfTrustInfo/rebooting-the-web-of-
trust...](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-
fall2017/blob/master/final-documents/activitypub-decentralized-
distributed.md#end-to-end-encryption)

The ideas about using DID's ([https://w3c-ccg.github.io/did-
spec/](https://w3c-ccg.github.io/did-spec/)) and moving off a common transport
like HTTP was also interesting.

------
jeswin
From my quick read of the spec, server-to-server federation assumes that
servers can be trusted. That need not be the case; unless a message is signed
it should not be assumed to have come from a specific user. I don't know if
there's an easy way to share keys in a decentralized way, but that'd be an
interesting problem to solve (some blockchain maybe).

The other question is whether we want server-to-server federation at all
instead of a P2P network like bittorrent. With the decreasing cost of compute,
I am also optimistic of everyone being able to run a little sandbox on the
cloud to exchange data with others, instead of routing it via FB/Twitter.

~~~
rakoo
> I don't know if there's an easy way to share keys in a decentralized way,
> but that'd be an interesting problem to solve (some blockchain maybe).

This is exactly what namecoin tried to solve. Buy an identifier, put whatever
you want in it. Example:
[https://nameid.org/?name=rakoo](https://nameid.org/?name=rakoo)

> The other question is whether we want server-to-server federation at all
> instead of a P2P network like bittorrent.

We want something in between. The best model I know is the one of scuttlebutt
([http://scuttlebot.io/more/protocols/secure-
scuttlebutt.html](http://scuttlebot.io/more/protocols/secure-
scuttlebutt.html)): Each peer is identified by an asymetric keypair, and
writes posts/comments/photos to a local ledger. Everything is signed and
potentially encrypted if the message is to be read only by select people.
Diffusion follows the peers' connections: stuff is sent from peer to peer as
they connect together, friends can be used as a third leg (ie a common friend
can carry stuff even if it's not for them), and you also have pubs where more
people can connect and get more stuff faster. This system is different from
bittorrent in that everything depends on the human connections: information
spreads along human acquaintances, names aren't globally unique, they depend
on how your friends agree to name you, etc...

It's better than naive server-to-server federation because pubs can be simple,
stupid message forwarders yet still have all the advantages of being always-up
servers.

~~~
Crespyl
Scuttlebut is, so far, the most interesting decentralized social media tool
I've seen. Even Mastodon and Matrix still require a server of some form, while
SSB will continue to work offline and via truly local peer to peer
connections.

The only issue is client support and the fact that I don't have a good sense
of the state of development/stability/soundness for SSB.

If you (or anyone) has experience actually using SSB or similar true P2P
platforms, I'd be very interested to hear what did or didn't work well.

~~~
ChristianBundy
SSB is rock-solid in that the community _encourages_ the use of diverse client
and server implementations rather than having a monolithic interface that's
meant to do everything.

On the other hand, the underlying libraries are opinionated in that they
usually use depject and a handful of other tools/techniques that aren't super
familiar to those outside the SSB community, which makes it harder to write
brand new clients.

I'd use SSB exclusively if they offered a web client (as I'm on a Chromebook),
but we're slowly getting there.

~~~
xj9
> ssb webclient

[https://github.com/ssbc/patchfoo](https://github.com/ssbc/patchfoo)

you do need to host your `sbot` somewhere tho

------
Shoothe
ActivityPub is like JWT. Simple on the outside but complex inside. For example
I wanted to implement a simple server to connect to Mastodon. JSON via HTTP,
what could be simpler? Actually it's JSON-LD not JSON. But it doesn't matter
as JSON-LD is JSON, right? No, as the standard requires normalizing JSON-LD
for purposes of signing that includes all of RDF canonicalization, of course
the standard do not require it [0] but it's akin to unencrypted HTTP2,
theoretically it exists but practically doesn't.

What's interesting is that ActivityPub requires signing the data twice, first
on a HTTP request level, then the JSON-LD itself. It seems like the designers
tried to make it simple (let's use JSON-LD and HTTP) but after several edge
cases the standard got out of control.

[0]: "Linked Data Notifications also supports a number of RDF serializations
which are not required for ActivityPub implementations. However, ActivityPub
implementations which wish to be more broadly compatible with Linked Data
Notifications implementations may wish to support other RDF representations."
source:
[https://www.w3.org/TR/activitypub/](https://www.w3.org/TR/activitypub/)

~~~
daveid
HTTP signatures and LD-signatures serve different purposes. HTTP sigs
authenticate server-to-server requests, while LD-signatures allow to forward
verified messages in the network. The forwarding part is a good extra for UX
purposes but it's not necessary for your implementation, you can just stick to
HTTP sigs which are really simple. I agree that LD-signatures are very
complicated to implement. If you avoid LD-signatures then you don't have to
mess with JSON-LD canonicalization either, you can just treat the JSON as
simple JSON (though it's still a bit fiddly because a value can often be
either a URI string, an array of URI strings, an object, or an array of
objects).

~~~
Shoothe
I know what the signatures are for but I wonder if there's a simpler way to
achieve these objectives.

Server authentication: For example XMPP uses client certificates to
authenticate servers to other servers (TLS server certificates usually can be
used for client authentication too).

Message authentication: maybe exchanging OpenPGP messages would be easier?
They already are signed and the payload can be anything. Of course it's not as
easy to list a collection of these messages as it is with JSON (just collect
into an array).

> If you avoid LD-signatures then you don't have to mess with JSON-LD
> canonicalization either,

I want to be interoperable with existing software so avoiding it is not a
practical option (although allowed by the ActivityPub spec). Just like having
non encrypted HTTP2 is not a practical option (although allowed in the spec).

------
jordigh
The FSF announcement about it:

[https://www.fsf.org/blogs/community/victory-for-libre-
networ...](https://www.fsf.org/blogs/community/victory-for-libre-networks-
activitypub-is-now-a-w3c-recommended-standard)

Look in particular at that cool video in it. Someone posts a video to
Peertube, which gets federated to Mastodon. People comment on Mastodon and the
comment gets federated back into Peertube. People reply on Peertube, and the
comment goes back to Mastodon. Kinda nifty:

[https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a...](https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a-4ec8cbdca701)

Btw, I have been greatly enjoying Mastodon. I'm @JordiGH@mathstodon.xyz in
case anyone feels like chatting to me there.

------
jelv
PeerTube with Mastodon comments. Powered by ActivityPub.
[https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a...](https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a-4ec8cbdca701)

~~~
NetOpWibby
Comments are disabled.

------
grizzles
The thought process behind ActivityPub seems fanciful to me. To paraphrase:

Here is a spec for something no one currently uses, please take a risk and
invest your time to understand ActivityPub, build an impl of ActivityPub, and
then build your thing on top of it. Then, if many others also do this, it
might have a chance at success.

Heed the lesson of OStatus. Open source has killed RFC style development. If
the backers of ActivityPub genuinely want people to use it then they should
publish a reference grpc microservice porcelain on docker so people can use it
from any language, without thinking about it. Otherwise the cost to implement
ActivityPub is just too high.

~~~
gargron
Did you miss the part where a million people use ActivityPub via Mastodon?
There are already numerous implementations, such as Mastodon, Hubzilla,
Pleroma, PeerTube, Kroeg, and more.

~~~
grizzles
Perhaps I should have said "that no one uses directly".

I tried out Mastodon but didn't become a regular user. So I'm just curious,
are you claiming a million monthly active users or a million accounts created
since inception?

A million a month is roughly what serverfault.com gets. If you have
1MAU/month, that's a nice achievement, though it's still 1/130th the market
share of twitter.

I hope Mastodon keeps growing to level out the playing field. That's why I
suggested a way to make it easier for other sw engineers to support it.

~~~
treve
By that logic no one uses email directly either.

------
stevedekorte
Federated is not decentralized.

If you feel this is a small point, please consider the centralization which
has happened with email, jabber, and other federated systems.

~~~
dpc_pw
Anything web-based is a dead end at this point. There is many, many reasons
why any web-based solution will degenerate into centralized system. People
behind Urbit got it right. I don't know if Urbit is going to succeed, but the
they have pointed out the issue brilliantly.

------
hateful
My only question is: Is this a Twitter or Facebook replacement? Because if
it's only about someone status and you can't post something on someone's
wall/timeline, then it will never truly complete with Facebook.

It was the only thing missing from Google+ IMO.

~~~
NoGravitas
It actually contains sufficient primitives to implement either. Mastodon uses
it in a Twitter like way, but there are projects being worked on that are more
similar to Facebook.

------
amelius
Imho, any such document should start with a requirements-analysis.

It's difficult to tell what requirements they have considered, and what they
have forgotten without reading (and re-reading) the entire spec.

------
eximius
Misread as 'Decentralized Pub', am sad I was wrong.

(although, that now just sounds like 'drinking alone')

~~~
ytjohn
You should check out Scuttlebutt

[https://staltz.com/an-off-grid-social-network.html](https://staltz.com/an-
off-grid-social-network.html)

[https://www.scuttlebutt.nz/getting-
started.html](https://www.scuttlebutt.nz/getting-started.html)

[https://scuttlebot.io/docs/basics/install-the-
database.html](https://scuttlebot.io/docs/basics/install-the-database.html)

------
EGreg
I have been in touch with Tim Berners-Lee and his Solid project since late
2016. Since then, I've run across many people who work at W3C and in the
protocol space, and it's inspired me to open up and publish protocols derived
from our platform (eg
[https://github.com/Qbix/auth](https://github.com/Qbix/auth))

But I believe that, in the end of the day, mass adoption can only be done when
there is a popular platform. Whether it's closed source like Facebook or
Twitter, or open source like Qbix, it needs to be actually used. That's how,
for instance, oAuth came to be so widely adopted, and many others.

Here is an overview of what I mean:
[https://vimeo.com/252105786](https://vimeo.com/252105786)

Protocols like Scuttlebutt or ActivityPub can be bolted on after the actual
infrastructure is there.

~~~
davexunit
Mastodon is used by a million people across a lot of instances and supported
ActivityPub before it was a W3C recommendation, so I'd say it is definitely
being used.

------
maufl
Reminds me of my own attempt to design a decentralized networking protocol
FOSP ([https://github.com/maufl/fosp-
specification](https://github.com/maufl/fosp-specification)). I now think that
a peer to peer solution would be more user friendly, it's sometimes difficult
to explain to some of my peers that there can be a difference between an app
and an service.

------
marknadal
We need P2P not federated. Federated still requires trusting a server which is
not good. We've tackled this problem and produced an insanely simple API for
creating fully P2P apps, even the cliche Twitter/todo app can be built in
4min: [https://scrimba.com/c/c2gBgt4](https://scrimba.com/c/c2gBgt4)

------
Xeoncross
Does anyone have a reference to all the expected/discussed use-cases?
[https://github.com/jasnell/activitystrea.ms/blob/master/READ...](https://github.com/jasnell/activitystrea.ms/blob/master/README.md#usage)
shows a number of activity types.

~~~
Xeoncross
Found the [https://www.w3.org/TR/activitystreams-
vocabulary/](https://www.w3.org/TR/activitystreams-vocabulary/)

and the older
[https://www.w3.org/wiki/Activity_Streams/Examples](https://www.w3.org/wiki/Activity_Streams/Examples)

------
m3kw9
Does anyone know if say you have Facebook level of activity, wouldn’t the
block chain be in the orders of petabytes to download? I’m sure you may want
to know your history all the way back, or does the protocol is smart to know
how much you need to download?

~~~
NoGravitas
ActivityPub does not use a blockchain.

SSB uses an append-only log similar to a blockchain, but it only contains
things your identity knows about (you and your friends and channels).

------
simula67
Similar earlier attempt by Google :
[https://en.wikipedia.org/wiki/OpenSocial](https://en.wikipedia.org/wiki/OpenSocial)

------
ivanceras
I'm looking for the specs of the message format used, but couldn't find it. Is
it gonna be like email message format? html perhaps?

------
gizmogwai
Is it just me or does this recommendation reads more like a medium blog post
from some developer advocate than like a formal specification ?

------
OriPekelman
and it only took 10 years to come up with the spec !
[https://www.w3.org/2008/09/msnws/report.html](https://www.w3.org/2008/09/msnws/report.html)

------
omarforgotpwd
Yeah, let's send my social media data to a bunch of servers automatically
through a distributed protocol with no practical means to enforce compliance
with privacy settings. But that's okay, nobody ever posts anything on social
media that they end up regretting, right?

~~~
Kequc
I'm reasonably secure in my feeling that centralisation isn't the problem.

As much as people far too freely giving up information about themselves
online. Decentralisation can work as an anti-censorship measure but I wouldn't
expect something I send out over Bittorrent (for example) to remain my
personal private info.

------
rocky1138
Does GNU Social support this? AFAIK ActivityPub is a successor to OStatus.

~~~
Torgo
No.

------
snissn
Can I build a blockchain on top of it?

~~~
jlarky2012
my thought exactly! At least add work of proof to fight with spam :)

------
freeduck
ELI5 ActivityPub vs xmpp semantics

~~~
eeZah7Ux
AFAIK XMPP is more geared towards IM than microblogging and it's very complex
and difficult to get right due to many extensions.

~~~
JepZ
Actually, I never did any XMPP coding but from what I belief it is more
difficult to get it 'complete' then to get it 'right'. I mean you get it
'right' even with a minimal/core implementation but 'complete' only with about
the 50 most common extensions. Getting it 'right' seems to be a problem when
the XEP definition is open to interpretation.

Nevertheless, I agree that it would not fit the XMPP ecosystem to be used as a
micro blogging service. It's like using e-mail for IM: Possible, but not
recommended.

~~~
ppjet6
> I never did any XMPP coding but from what I belief it is more difficult to
> get it 'complete' then to get it 'right'.

I don't think there is a point in getting it complete. You choose the XEPs you
want by looking at what your client/server goals are. Also if you need help in
choosing, there are pointer XEPs, like the Compliance Suites, or the mailing
list, or the chatrooms. See
[https://xmpp.org/community/](https://xmpp.org/community/)

> Getting it 'right' seems to be a problem when the XEP definition is open to
> interpretation.

When in doubt, ask the author/council.

~~~
JepZ
Fair enough, 'complete' might be the wrong word here too (as you do not have
to support all XEPs), but currently my biggest problem is, that Conversations
(Android XMPP client) works pretty good (something I would consider 'complete'
in terms of messaging), but I could not find any desktop client which works on
a similar feature level.

For example how many desktop clients support OMEMO, MAM and Carbon copies?
Those are just 3 XEPs all related to secure multi device communication. Yes,
they haven't reached the status recommended yet, but I think that is more a
symptom than the root of the problem.

~~~
SamWhited
Desktop client support is lacking, but I think Dino (a relative newcomer) does
a pretty good job of being compatible with Conversations and being "modern"
(for some handwavey value of "modern") messenger based on XMPP:

[https://dino.im/](https://dino.im/)

~~~
JepZ
Last time I tried Dino was 4th August, but I can't remember what made me stick
with Pidgin. But hey, if Sam Whited suggests Dino I will try it again :-D

I love the XMPP and Golang stuff you are doing.

And far as I can see it Dino seems to have pretty good XEP collection
nowadays:

[https://github.com/dino/dino/wiki/Supported-
XEPs](https://github.com/dino/dino/wiki/Supported-XEPs)

~~~
SamWhited
> Last time I tried Dino was 4th August, but I can't remember what made me
> stick with Pidgin.

Dino's still relatively new software so it may not be all that stable yet (I
don't actually use it enough to know). I hope it works out for you though; it
looks nice if nothing else!

> I love the XMPP and Golang stuff you are doing.

Thanks! It's still very early days and I don't get a lot of time to work on
it, but I'm glad someone has seen it and found it useful.

------
yellowsir
how can anything be verifyed?

~~~
daveid
With cryptography.

~~~
yellowsir
how? in the example the data is not signed, what is stopping a other server
from changing the content i posted?

~~~
daveid
The exact methods of authentication are simply "out of scope" for the
ActivityPub standard itself. As far as I understand simply for bureaucratic
reasons. In reality there's already agreed upon mechanisms for doing this.

Each actor has an RSA keypair. Server-to-server requests are authenticated
using HTTP signatures (that's a different spec), so you know a delivery is
legit and on behalf of which actor it is. For messages that are passed
directly between origin and destination there is no reason to believe the
sender has tampered with the message (SSL is a prerequisite anyway). For
messages that are about other messages, such as reblogs, you would _not_ trust
the sender, you would look up the message by its ID on its origin server
instead. This is always possible because ActivityPub prescribes IDs to be
resolveable URIs. There's also another method to verify the authenticity of a
passed message, called Linked-Data Signatures (that's a different spec). It's
a way of signing JSON inside JSON, it's a bit of a bother to implement though
(To make sure the signature works regardless of how the payload is re-
formatted or re-ordered in transit, the JSON is "canonicalized" using RDF)

------
cuckcuckspruce
All of these social networking protocols feel like we're just re-inventing
UUCP at a higher level.

~~~
NoGravitas
I've considered that, as well. I _enjoy_ Mastodon, and am working on another
ActivityPub project. But in a lot of ways it's not a significant advantage
over Usenet.

~~~
cuckcuckspruce
Mail over UUCP and Usenet over UUCP are optimized for short(-ish) messages,
and deal with packet loss, dynamic IP addresses on remote connections, partial
transfers, and synchronization scheduling as part of their implementation.

It would seem to be a good base to build something like ActivityPub on top of.

