Let's talk about ActivityPub

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

ActivityPub

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.

2 Likes
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.

5 Likes
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?

1 Like
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.

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.

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…

1 Like
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?

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…

1 Like
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).

3 Likes
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.

2 Likes
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.

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:

2 Likes
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.

Update 2019-01-13: I published a second post with a bit more ramblings on the general specification process, more thoughts on interoperability, other concerns, and what could have happened if people wanted to work together. It’s not important enough to warrant a new reply, notifying everyone, but I thought it might we worth adding here, anyway. :slight_smile:

4 Likes
14

I noticed on the Friendica issue tracker that they created separate issues for federation with different projects that use AP. So they had an issue for federation between Friendica and Mastodon, between Friendica and PeerTube, and so on. I suggest that anyone who wants to see Diaspora federating with AP apps tries this approach, breaking the problem into specific, manageable chunks.

Initially I criticized Friendica’s approach to this, because I didn’t yet understand what has become clear through this discussion. As @cmrd-senya summarized it on the GH issue in January, although AP is a standardized framework, it doesn’t (yet) make sense to “implement AP” in a generic sense. Especially when the goal is federating with apps like PeerTube, PixelFed, or Mobilizon that are doing something other than (micro-)blogging, which may need AP extensions for handling things like videos, songs, and events, in the fediverse are still in the process of being standardized.

1 Like
15

It’s complicated :slight_smile: Basic communication is working really fine with AP. But every time that someone extends it, then we have to decide whether to adopt these changes or to ignore them.

Indeed it is more complicated than implementing the Diaspora protocol. AP isn’t that fixed. And there are many players out there. You can’t even treat Mastodon as a standard since they haven’t implement everything. So possibly you have to look at other implementations as well - or have to find your own way for stuff that hadn’t been implemented before.

But it is also true that most stuff is working fine. We hadn’t got any serious communication issues in the AP core of Friendica for months now, I think.

And another thing is true as well: Diaspora is very similar to Friendica in some ways. So when eventually Diaspora would adopt AP, then the developers could have a look at how we had done it and could adopt it. Of course not the code itself, but possibly the way the message transfer and relaying is done, how messages are constructed, etc.

1 Like
16

FYI the SocialHub forum continues to serve as a neutral watering hole for developers working on implementing or extending AP. Due the admins abandoning the original Discourse instance, it has moved to a new instance at:

Related discussion also takes place on the forum of Feneas (Federated Networks Association):

1 Like
17

I think there is literally no good point against implementing ActivityPub other than having no power to implement that (but we could start a fundraising to fund the development of AP implementation). There would be like 5 times more users to interact with.
One of the biggest problems when I try to encourage people to try Mastodon or some similar platform is that I hear „but there were many platforms like this and all of them failed”. If I would tell them that they would be able to communicate with Diaspora users from a new platform, that would make it pointless and make them feel like Diaspora actually didn’t fail.
I think finding problems in the fact ActivityPub is not so strict/doesn’t have a strict standard makes no point. There is a de facto standard but Diaspora could take for example Friendica as a reference for AP implementation, as I think these projects on pair with functionality. Mastodon is getting circles (think G+ circles, like Diaspora aspects) soon, so it would not be a UX disaster to combine both of the worlds.
And it would also definitely take shorter to write a proper ActivityPub implementation on Friendica than to explain every time that Diaspora does’t support AP :laughing:

2 Likes
18

Edit: I should add that the reply below is very much my personal opinion. Others in the project might have a different one, I didn’t check.

Then you did not read the whole thread and all linked resources. :slight_smile: You might not agree with everything, but you can’t claim that all of the points here are not “good”.

Then you have no experience in designing interoperable systems. That’s fine, but the problems with “oh just implement AP” have been explained in this thread and linked resources. We’re not talking about theoretical things either, these issues are very real and can be observed very easily in the already existing space of AP implementations. Even AP implementors themselves agree, sooooo … :man_shrugging:

You mean Friendica, the project that

You’re right - diaspora* should take Friendica as a reference. We should take it as a reference of why implementing multiple protocols - and implementing protocols that do not match your own requirements and UX - is a horrible idea.

(Michael appearing out of nowhere and saying “it’s not that bad, you just have to talk to everyone!!” in 3, 2, 1, …)

Friendica is a nice project, and has many friends and users. That’s cool. Unfortunately, it’s also the one project where I constantly see less technical users being completely confused, up to a point where they go back to Facebook because that’s easier (or, in rare cases, they go back to diaspora*, because as it turns out, diaspora* is a lot more stable and usable).

Mastodon, Friendica, and diaspora* are very different projects, and I would not say either one is “better”. Mastodon had perfect timing and is catering a lot to the nerds who want something that feels like twitter but is not. Friendica caters a lot to the small group of people who want a tool that “can do everything” and are willing to spend weeks with learning Friendica. diaspora* caters to people who don’t want to spend weeks on learning how things work, and people who appreciate a simpler UX and are fine with the reduced set of features.

It’s important that there are multiple projects out there (in fact, I personally even suggest people to try different projects regularly), and there’s also a benefit of having multiple protocols out there. Different requirements and different solutions are usually a great source for actual innovation.

But you don’t have to do that, tho. Just go with the “diaspora* is a horrible project, its developers have a strong case of the ‘not invented here syndrome’, and all their arguments are wrong” line. Seems like a fairly popular explanation in some circles. The people who specifically ask why diaspora* does not implement AP are generally not people in my personal target group anyway (i.e. people who know what AP is, and who have not seen or do not want to see our explanations). No hard feelings either way, we’re used to it, and actually quite comfortable. :wink:

(It’s also quite interesting to observe people criticizing diaspora* because it does not implement a protocol defined by a “well-known” standards body, while at the same time, the same people praise Matrix for not implementing XMPP. That… does not quite make sense to me. Not talking specifically about you, but I’ve have this discussion way too often.)

3 Likes
19

So… Diaspora* isn’t adding AP support? TL;DR?

1 Like
20

It’s something of a tangent, but just as the mainstream are starting to get disillusioned with the centralized datafarming platforms, the decentralized social media landscape is getting more fragmented again. For example;

All this is confusing for users, and prevents us from pooling the network effect of all the projects, to make the resulting meta-network a more compelling replacement for the datafarms. Which was the goal of standardizing a social web protocol through the W3C. Perhaps recognizing this, even people from the XMPP world - traditionally just as sceptical of AP as @denschub - have started working on interoperation with AP.

Newbies have started asking me about Diaspora, whether it’s part of the fediverse, and whether they can talk to people using Diaspora from Mastodon. I can just tell them yes but no, never, and send them here. But it would be great to be the bearer of more hopeful news for broad interoperation in the fediverse :slight_smile:

1 Like