Let's talk about ActivityPub

(Sean Tilley) #1

I wanted to follow up on this Github Issue, in the hopes of furthering useful discussion with the people who presently work on Diaspora.

Diaspora has not historically supported using any protocol implementations other than its own. This in and of itself is not necessarily a bad thing. In fact, Diaspora federation has greatly improved since the original core team stepped away because an emphasis has been placed to improve the way federation works.

The development of the Diaspora federation gem is also significant in this respect, as there is some implication of federation being implemented in a more modular fashion than before. This does open up some interesting opportunities.


The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

The most compelling thing about ActivityPub, from my own point of view, is that it presents an opportunity where all of the platforms within the federation (including the fediverse) could all cross-communicate with one another. In principle, this would increase the utility of being on a federated network - there is a larger pool of more people using it collectively. For many people, it would make much more practical sense to participate, since federated subscriptions in theory would have a lower barrier of entry.

So far, the following projects are talking about implementing it:

It is also possible that Friendica, PostActiv and Hubzilla will support it as well, through the form of plugins. My point is, as time goes on, more platforms within the space might consider adopting it, especially if other platforms support it already.

Here’s the latest upstream of the draft, if you’re interested in reading more about it.

Social Web WG - Account Systems and Webfinger Feedback
(Dennis Schubert) #2

(My opinion on this topic is controversial, and I am not sure if I even like my own opinion. This is written wearing my personal hat, not the diaspora* dictator hat. ;))

As written yesterday on GitHub and as I’ve also mentioned on IRC, I am currently working on reading through all the specifications written by the W3C Social Web Working Group.

I am much for cross-compatibility between all social networks. In theory. In practice, this seems hard and almost impossible. Even within the SocialWG, there are two trees of specifications, which somewhat compete with each other. On one hand, there is ActivityPub and ActivityStreams (one of the two trees) and used as an example here. On the other hand, there is WebSub and WebMention, which is an entirely different stack that also gets maintained by the W3C Communtiy Group.

Surprisingly enough, those two are not compatible with each other. Sure, it is technically possible to support them both, but they are really different protocols, with different naming for items, different types of payloads, different flows.

Both have their ups and downs - as usual. So, in principle, yes, you are right, supporting ActivityStreams may increase the range of our posts. Maybe. In theory. In reality, most WebSub/WebMention/WebWhatever based implementations are not compatible with ActivityPub/ActivityStreams unless they implement both stacks. And they have to implement both stacks in both directions (incoming and outgoing), or otherwise it would be a mess for users (“Why can I read Alices posts but she is not able to read mine?”)

Cross-posting from everywhere to everywhere would be a nice thing. Maybe we’ll get there eventually. We’re not there yet. Surely, someone has to start somewhere, but I do not see us in the position to do that. We have a hard time keeping the lights on anyway, we have a protocol that works for us and some others (like Friendica, for example), we have a clear and open documentation and everyone is welcome to join if they have suggestions.

For us, to implement a second stack or to replace our stack would mean a huge effort with a guaranteed negative outcome since we will have bugs in our new implementation. So, to justify such a change, there needs to be a huge improvement that is visible to users. At this point in time, neither Activity{Streams,Pub} nor their “Web”-prefixed counterparts provides those.

Activity* (for the lack of a better group naming) has some nice points, but it also has some flaws. One example that breaks it for us is the missing encryption support. They provide signing for items, but they do not support encrypting them with previously exchanged keys, they rely on HTTPS for that. As proven by recent history, that’s maybe not the smartest idea, at least from our point of view.

By design, a lot of entities inside AS are named differently. Polls are called “questions”, posts would be “notes”, … While we could hide that internally, using AS as a client API wouldn’t really make much sense to us since matching the names of API entities to something visible in the UI is somewhat important.

There are a lot of issues we to need invent solutions for, or to collaborate with the CG to get them specified. As mentioned earlier, I am not done reading everything yet, so please take everything I wrote with a grain of salt - I might be wrong and I might change my opinion on some points. However, since you picked the worst possible timing for creating this post and I felt the urge to reply, here we are.

As you kinda mentioned, nobody is really using AS2 yet, which is mainly caused by the fact AS2 isn’t even a published spec yet. It’s a draft, and I am doing my best to treat it as such. I’ll continue idling/participating in the SocialWGs IRC channel and I will start joining their meetings. Maybe, I’ll even start playing around with an isolated AS2 implementation, to further explore its limits and to help moving it forward.

I don’t feel good with suggesting diaspora* to move to something other than our own stuff. Yet. This might very well change.

(Flaburgan) #3

Ideally, we should participate to the draft creation to be sure every diaspora* use cases are covered by the ActivityPub protocol. Then we will be able to implement it inside diaspora* if other projects are doing so and we have the resources to do it.

we have a protocol that works for us and some others (like Friendica, for example), we have a clear and open documentation and everyone is welcome to join if they have suggestions.

Maybe we should promote that more?

(Michael Vogel) #4

I do have some problems with AP and AS2. AS2 is built to describe nearly all possible activities that someone could do with someone else - which does make it very complex.

With AP I have the problems that is really unspecific when it comes to the interesting parts: The distribution of comments. For me it seems as both ways (the way OStatus and Pump.io is doing and the one that Diaspora and Friendica is doing) are possible - which doesn’t make the communication easier between the different systems.

In OStatus and Pump.io the comments are distributed by the creator of the comment to the followers of the commenting person. In Diaspora and Friendica a comment is always only transferred to the thread creator which then distributes the comment to the followers of the original thread creator.

My biggest problem is that the whole signing thing is totally left out. And private mails were not in the original plans.

Additionally I have a personal problem with the specification: I do not understand this type of english very well. I’m no native speaker, I have huge problems with theoretical stuff (which is why I never had been in a university) - and this both combined with each other does make it nearly impossible for me to create some useful. I’m better in the reverse engineering of implemented protocols. This is the reason why I will wait with AS2 and AP until someone else had done this job.

(Flaburgan) #5

Is there any news on that subject @denschub? I don’t have time to read all the discussions and I’m not a protocol specialist… It looks like mastodon is going with ActivityPub but the use case is very different than ours.

(Dennis Schubert) #6

Quite frankly, no. My initial opinion still stands and I have no idea on how we could map our stuff to AP without reengineering… everything, although I confess that this is something we should discuss in a larger round. I plan on doing some initial discussions with @supertux88 since we will meet soon’ish anyway, and, if we decide it’s worth it, try to plan a group call for us to have discussions.

Will update you all as soon as I have something to say…

(Flaburgan) #7

Should we go the other way? Contributing to the social WG to explain that the protocol doesn’t feed all the needs and should evolve?

(Dennis Schubert) #8

That’s not a question. It’s doing that anyway. And it’s also not something the WICG or the WG can “evolve” into. AP uses entirely different flows, different terminology, different concepts. It technically does fit all our needs, except that some things would be an upright mess. The mere concept of aspects is handled (and, fwiw, called) entirely differently than we do and why we could, in theory, create a wrapper level, wirting that glue code would probably take ages and we’d end up with using multiple terminologies for same stuff.

At the end of the day, we are only sending messages and AP is only sending messages. Devil’s in the details…

(Benjamin Neff) #9

We already have a protocol that fits all our needs now (which is already supported by different other projects: friendica, socialhome, hubzilla, …). I re-implemented and improved our own protocol for the last two years and it was a huge amount of work and I don’t really have the time to do this a second time (I’d rather add a few new features that are now possible with the improved protocol and after all the refactorings).

(Dennis Schubert) #10

I totally agree with you, @supertux88. However, I at least want to spend a good amound of time thinking about AP, since unifying communication would be a nice goal, if it’s something we could achieve.

(Christopher Allan Webber) #11

Hi! As you all probably know, I’m ActivityPub co-editor.

I’d like to understand if there are specific things that would be challenging for Diaspora to adopt ActivityPub. It seems to me the things that the relevant bits raised on this thread are:

  • lack of signatures on objects: valid criticism, though we’re starting to see some convergence on the right approaches in practice (at minimum, http signatures across http requests; maybe linked data signatures to sign the objects themselves)
  • It’s a lot of work to rewrite and map concepts (understandable)

Are there other things? It would be good to know and discover issues before we hit the point where changes can’t be made.

(Christopher Allan Webber) #12

Oh yeah and FYI, ActivityStreams2 (ActivityPub’s vocabulary, not ActivityPub itself) is now an official W3C recommendation; that’s one different thing between when this post was made and now. :slight_smile:

(Dennis Schubert) #13

So, I thought I might follow up on this one.

Since AP is now an official rec, the chance of me accidentally hindering the SocialWGs efforts is really low. I published a rather long blog post with all my thoughts on ActivityPub, ActivityStreams, and its adoption in diaspora* (at least from my point of view).

As you might realize, my main issues with AP/AS are based upon the very core concepts, so publishing it earlier could not have changed it in any meaningful matter, but I wanted to be sure I do not accidentally delay the W3C approval, which given some of my contacts, might have happened if I posted this full thing earlier. :slight_smile: I’m sure you understand.

I really appreciate your and everyone elses work on AP, AS and related specs, and I hope it gets some traction and, just maybe, a bit more … distinct overhaul in the future. As of the current state of these specs, I highly doubt it would fit us as a project, and I honestly do not think our contents and our paradigms would be compatible with other implementations.

This is, as usual with my opinions, based on the current state, and might very well change in the future.