Support ActivityPub

[evanp]

Diaspora should support the ActivityPub ("AP") standard. AP provides a client-to-server API as well as a server-to-server federation protocol. It is the successor to the OStatus standard partially supported by Diaspora already.

Other social networking servers like pump.io and GNU MediaGoblin are moving to AP. There is some more information on the state of the ActivityPub network on the W3C wiki. We're trying to get everyone involved in federated social networking to rally around this standard and get a truly federated network working.

[DeadSuperHero]

Hi Evan, nice to see you here.

This is on our radar, and I think our system is modular enough to support a different federation protocol and schema, in theory. Unfortunately, adapting a new standard is a pretty slow process for us, and we're finally at a point that we are happy with our own federation protocol. However, I think many will agree that we eventually want to move towards greater compatibility with the rest of the federation.

One caveat is that we first need a dedicated person to work on it, which would involve creating a native Ruby implementation of ActivityPub that is compatible with Diaspora. The second is that we want to be certain that ActivityPub can support the privacy features that are leveraged by Aspects and private messages. As those are cornerstone features of our network, it's kind of an important prerequisite.

[evanp]

@DeadSuperHero Hi! I'm glad to be here. I think @cwebber can talk to the aspects and privacy issues. It's one of the big things we wanted to do with AP -- make it possible to share privately across servers.

[annando]

There are some unanswered questions in the protocol like the question how to sign and distribute comments.

Diaspora distributes comments via the thread owner while pump.io (and AP?) Is distributing comments through the commenting account. This is an important difference.

[jaywink]

@annando actually, as far as I've been able to understand (read it a few times!), comments would be delivered by the thread owner. It would be impossible for the commenter to deliver them, that would be a technical impossibility, not sure how pump.io can do it?

When Activities are received in the inbox, the server needs to forward these to recipients that the origin was unable to deliver them to. To do this, the server MUST target and deliver to the values of to, bto, cc, bcc, and/or audience if and only if all of the following are true:

• This is the first time the server has seen this Activity.
• The values of to, bto, cc, bcc, and/or audience contain a Collection owned by the server.
• The values of inReplyTo, object, target and/or tag are objects owned by the server. The server SHOULD recurse through these values to look for linked objects owned by the server, and SHOULD set a maximum limit for recursion (ie. the point at which the thread is so deep the recipients followers may not mind if they are no longer getting updates that don't directly involve the recipient). The server MUST only target the values of to, bto, cc, bcc, and/or audience on the original object being forwarded, and not pick up any new addressees whilst recursing through the linked objects (in case these addressees were purposefully amended by or via the client).

https://www.w3.org/TR/activitypub/#inbox-delivery

AFAICT that means exactly that the content owner is responsible for delivering any follow-ups - just like the Diaspora protocol requires.

[cwebber]

Yup, servers of people higher up in the chain should deliver to their own collections of participants (read, Diaspora aspects or sets of followers) the content of comments they receive following the pattern described above. Indeed, that's exactly for the delivering to groups you don't have access to problem.

That's only for collections; if I add individuals or keep individuals cc'ed on the thread, my server can still deliver to them, and your server doesn't need to do the fancy forwarding behavior.

[cwebber]

As for signatures, there's a signatures usage specification attached to ActivityPub, and this was partly added in response to feedback from Diaspora folks! (I wanted it, but the group thought it was out of scope until Diaspora based commenters declared that it was indeed needed.) It's not mandatory, mainly because the mechanism described has not yet fully matured as the de-facto way to do things at the time of the group, but the mechanism is there... and indeed, that's how I intend to do things (http signatures and linked data signatures).

One downside is that it hasn't been tested, though I did have a prominent member of the linked data signatures team review it before I added it. That's another reason it's non-normative... it needs implementation experience. If Diaspora folks are interested in working with me on implementing this forward, I'd be most eager to do it.

[annando]

@cwebber Yeah, I was one of the people who gave feedback on this.

Concerning this comment distribution via a third party I'm very far from understanding the definition. This is partly caused by language problems (my English is okay for colloquial talks, but not for more), but also caused by my understanding problems of definitions of every kind. I cannot learn by reading definitions, but only by looking at examples.

Concerning AP and AS2, how would the following things be defined with them:

• dislike (not removing of "likes", but disliking something)
• events and participation messages for these events (attend, not attend, maybe attend)
• forums (in OStatus they are called "groups")
• private messages (in difference to posts to a limited amount of users)

[jaywink]

@annando

dislike (not removing of "likes", but disliking something)

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Sally disliked a post",
  "type": "Dislike",
  "actor": "http://sally.example.org",
  "object": "http://example.org/posts/1"
}

Dislike is a core AS2 Activity.

Event is also a core AS2 Object:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Event",
   "name": "Going-Away Party for Jim",
   "startTime": "2014-12-31T23:00:00-08:00",
   "endTime": "2015-01-01T06:00:00-08:00"
}

There is also a Group Actor type. Don't ask me how to use it though ;)

[annando]

I'm definitely lost in these specifications. So there is some "like" and "dislike" in AS2, additionally "Like Activity" and "Like Collections" ... On Diaspora a "like" (or "dislike") is simply this: https://diaspora.github.io/diaspora_federation/entities/like.html - and it is transported like every other message, that's all.

To do anything with AS2 and AP (in Friendica) I will need some "translator" and some existing implementation, that's for sure.

[cwebber]

@annando I'm not sure how it's more complicated... the Diaspora description and the ActivityStreams definition look not too far off from each other. But if you need help, give me a ping.

[annando]

As an example: How do I repeat a post? In the current Diaspora protocol it is described here: https://diaspora.github.io/diaspora_federation/entities/reshare.html

In the AS2 description (and the vocabulary) I haven't found clue to do this.

I guess that I have to contact you very often :-)

[cwebber]

Well you're welcome to contact me... as co-editor of ActivityPub, I even encourage it. :)

You're right that the (re)share bit was missing... that was caught a few days ago, and we're talking about it tomorrow on the call. That's the whole reason the spec is going through several cycles before it hits a recommendation! Specs are written by humans, and humans fail... I probably fail more than most, even. But we're seeking feedback.

And indeed, AP has already been shaped by the contributions of both of you (@annando and @jaywink). We're now at the point in the spec where we're relying on people actually implementing things, and catching what's missed or needs to be adjusted based on that feedback. I do want, and appreciate, your feedback, both from reading and from implementation experience if you're willing to give it.

So if you see things that are missing, or that need clarification, or have errors... yes! Please do contact me! Or file an issue! This is the time to do it!

[cwebber]

BTW, I wrote up a little ActivityPub tutorial which might even get put at the top of the AP spec (obviously with the ascii art becoming real graphics) in case that's of help to anyone here.

[hex-m]

Is this issue just about the server-2-server part of AP (federation) or does this relate to #7422?

[Flaburgan]

#7422 is this issue, which one are you talking about? But yes, this is about s2s, not c2s.

[hex-m]

Thanks for the clarification. And sorry - I meant #3467.

[roipoussiere]

Related discussion on Discourse: Let’s talk about ActivityPub.

[wizzwizz4]

Any updates on this? ActivityPub's much more standardised now, and I think it would be great if Diaspora wasn't a (collection of) island(s) any more.

[Flaburgan]

@SuperTux88 spent a lot of time (almost two years) to rewrite the diaspora* protocol implementation just before AP came out. All the time spent on the protocol level doesn't bring any new features to the users. With the current low resources of the project (not a single dev is paid to work on diaspora*), to see the current volunteers do the whole work of porting diaspora* to a new protocol is not going to happen, as we feel that the priority is first to bring new features to the users. However, that does not mean that we don't want to see diaspora* able to federate with the AP universe. It would be awesome and brings a lot to connect everybody. So if someone wants to step up and do that work, please do. However, there are probably a lot of things to decide in the way AP should be implemented inside diaspora*, so please raise your hand here to show your interest before starting to actually write the code to be sure to do it the good way.

[HankG]

@wizzwizz4 There has been no development of anything related to communicating via ActivityPub. In my personal opinion that is strictly a resource management thing. That is a big development effort and contributors are working on higher priority things that have been requested for awhile by users and developers alike such as the API, account migration, adding back likes on comments, etc. As someone who uses Diaspora and Mastodon throughout the day every day I would love to see this happen. As an active Diaspora developer I am looking forward to working on this eventually. However as a Diaspora user I see several things I want to see in my Diaspora user experience before I would pick that work up.

[denschub]

In my personal opinion that is strictly a resource management thing.

No, it is not. There are issues by-design with ActivityPub that completely disagree with what diaspora* is doing in terms of communication reliability, predictability, and general user-friendliness. Those issues have been outlined in the linked Discourse thread, and as much as I appreciate the euphemisms by @Flaburgan and @HankG, those issues are not solvable by throwing more development time into diaspora. So please stop acting like "low resources" is the reason why nobody is working on AP support. It is not.

[jaywink]

The Discourse thread doesn't clearly list anything after a quick view. Would you @denschub mind recapping them here? I'm interested in seeing Diaspora adopt AP sometime in the future and maybe people outside the Diaspora project can help demystify AP for the project. This wont magically make development happen, but it might help get rid of the the "Diaspora cannot federate over AP" myth, which knowing both technologies in some detail I find it hard to believe.

Note AP is not a protocol specification like Diaspora. It is more like a framework. Thus I find it hard to believe Diaspora protocol could not be done with AP+extensions, having been a part of the working group for exactly the reason to make sure it can.

[HankG]

In my personal opinion that is strictly a resource management thing.

No, it is not. There are issues by-design with ActivityPub that completely disagree with what diaspora* is doing in terms of communication reliability, predictability, and general user-friendliness. Those issues have been outlined in the linked Discourse thread, and as much as I appreciate the euphemisms by @Flaburgan and @HankG, those issues are not solvable by throwing more development time into diaspora. So please stop acting like "low resources" is the reason why nobody is working on AP support. It is not.

I'll speak solely for myself by reiterating what I said at the end of my comment: " As someone who uses Diaspora and Mastodon throughout the day every day I would love to see this happen.. As an active Diaspora developer I am looking forward to working on this eventually." That doesn't mean there aren't problems to be overcome when it's time to work on it but those aren't insurmountable problems for Diaspora integrating with AP at some level. They may be hard problems but not insurmountable ones. They and that whole initiative is something that will require an intense amount of concentrated work though obviously as well. Because of that and things I'd rather see in updated in the Diaspora UX I'm not planning on doing any work on this in the near future though.

[denschub]

The Discourse thread doesn't clearly list anything after a quick view. Would you @denschub mind recapping them here?

It's quite common for people to ask for a tl;dr, but there is none. You can't explain the world in two sentences, and that's not going to happen here, either. This post is a starting point, but you already know that one. Here is another wall of text, explaining the same issue with different words, hopefully making the issue clearer. No, no tl;dr.

ActivityPub, if anything, is a transport protocol, and nothing responsible for for the application/presentation layers. ActivityStreams would be accountable for that. The ActivityStreams Vocab describes, generally speaking, a set of things you can do with other things. More specifically, AS describes that an [Application, Group, Organization, Person, Service] can [Accept, Add, Announce, Arrive, Block, Create, Delete, Dislike, Flag, Follow, Ignore, Invite, Join, Leave, Like, Listen, Move, Offer, Question, Read, Reject, Remove, TentativeAccept, TentativeReject, Travel, Undo, Update, View] one or more [Article, Audio, Document, Event, Image, Note, Page, Place, Profile, Relationship, Tombstone, Video].

For each of those object types, AS describes a set of properties each object may have. That's a perfect rfc2119 may right there, everything is entirely optional. There is no real required set of properties (besides an identifier) for each object, so it's everyone's guess on what to do on receiving an object. Even more interesting, if you're not okay with the properties AS defines for you, not to worry, you can happily come up with your own stuff:

In Activity Streams 2.0, an "extension" is any property, activity, actor or object type not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present.

Not only does AP/AS not provide any guarantee that a specific set of properties are there, but there could also be any other imaginable properties, and by design that is a feature and throwing one's arms in the air and acting like properties aren't there on receiving is perfectly fine.

I'm dead serious here: how are we supposed to build something that works for users based on that? From a pure implementer perspective, AP/AS is almost like coming up with a protocol that states "you can send XML files via email. We don't really want to tell you what's in those XML files, but you have to parse it anyway, and you have to act as you understand it". What some of you are praising as a feature, is actually really bad for implementations. You can't throw indefinite amounts of extensibility onto a machine-to-machine communication protocol and expect things to work reliably.

I am well aware that implementing AP is a fancy thing to do right now, and everyone writes flashy press announcements with their freshly added AP support. And well, good for them, but with me spending significant portions of my career working on web browsers and web standards (you know, the world where even a tiny bit of flexibility/ambiguity resulted in the worst possible outcomes), I seriously want to bang my head against a wall and ask myself why the world hasn't learned anything. Yes, it's nice that so many projects can claim to support AP, but I really wonder why nobody seems to consider what it actually means.

Let's go away from diaspora* for a bit, as this is not about diaspora* at all. Do you know JetLovers? Okay, don't worry, I didn't expect you to: it's basically a social network for people who spend too much time on airplanes. You basically share the airport you're currently at (and your planned route), and it allows you to connect with coworkers/friends/... who just happen to be in the same airport, or even the same plane. I know this concept sounds weird to most of you, but it works well for illustrating a point. JetLovers could implement AP. For that, they'd send status updates in the form of Person Creates Place, probably, because that makes sense, right?

So, Alice is on Jetlovers, and Bob is using Mastodon. Alice is aware that both services are using ActivityPub because they both wrote fancy announcement blog posts claiming so. Therefore, Alice adds Bob to her contacts on JetLovers.

Now. What happens? Will Bob ever see Alice's Place updates? Mastodon doesn't support sharing locations, so what happens if they receive one? Do they display GPS coordinates in text form? Do they just drop it? What happens with Carol, a contact on NextCloud, which also supports AP?

I don't actually care what the answer to that is. The fact that this is a perfectly valid question for me to ask is the main issue. Both projects support ActivityPub, but that's nothing more than a merely blanket term, or the indication that a project is using a framework. For users, it means nothing. Supporting ActivityPub is a beautiful thing for people to be able to flatter themselves, claiming they work on "making decentralized social networks connect to each other." And up to a certain extent, this is actually true: they connect nerds to each other. That's about it.

I've heard horror stories from people implementing AP, telling me about their workarounds, and yet still claim that AP works just fine. Stuff like "oh yeah, if we can't display the object because we don't know it, we just link to the original item." Yeah, as if that is a workable solution. Sure, you folks on GitHub click the link and have no trouble with consuming that item on a remote pod, then coming back to your own instance and figure out a way to comment/like/whatever on that. It's naive to think that's a solution that will work for users. Users will click on the link, read the post, search for a link button or a comment field, maybe even find something that redirects them to the login form of that remote node ... whatever happens, they will get confused and never come back again because this thing is confusing as heck.

If Alice knows about the technical background, you might be able to explain the limitations. But what happens if Alice is not a software engineer, but a frequently traveling businesswoman selling heavy machinery? Alice doesn't care that you are all wonderful projects implementing a standard, and both implementations are perfectly valid ActivityPub nodes. She just realizes that, for some reason or another, her flight plan updates are not visible to Bob while her text-only updates are visible - at which point using the service in the first place has no purpose, so she stops doing that.

I've yet to find someone who is able to look me in the eye and seriously claim that this scenario is better than a simple "No, Alice, you can't communicate with Bob."

The current modus operandi seems to be to just look at Mastodon and copy their implementation because that seems to be the only way to get something working. That, however, is not about supporting AP, it's about supporting Mastodon's dialect of AP, and their subset of that. And that is just not going to happen with diaspora*. While there is an overlap between feature sets and UX, there are way too many differences.

If diaspora* ever supports AP, then it is likely in the form of an external service, just like we handle Twitter crossposts. And no matter how hard @HankG and others try to re-shuffle words here, what I say has the approval of the entire diaspora* core team (which I have verified more than once): diaspora* using AP for its federation is, in its current form, simply not going to happen. For us, building something isn't really about having an ideologically perfect project that supports all the latest flashy specifications, it's about creating something that works for users. And here, we can pick between two possible scenarios:

1. Implementing AP, and put ourselves in a position where we have to explain why sometimes communication works just fine, but with some endpoints, it might not work, polls will never arrive, people might not be able to send you identifiable private messages, but they'll just show up as limited posts, oh, and geolocation tags always get lost when talking to some endpoints.
2. Not implementing AP, being able to explicitly say "no, you can't communicate with X, but you can be sure that, if there is some form of communication, it works reliably and we are relatively sure that no contents get squished, lost, or otherwise transformed."

Option 1 is, for us, simply not workable. That's sacrificing UX for purely ideological reasons. It makes distributed social network more confusing for non-technical people to use, and that is absolutely not a thing we need. At the end of the day, we are all doing a horrible job at building consistent user experiences already, and I absolutely don't get why people are happy to make it even worse.

[HankG]

I'll make this easy. I agree with @denschub's post 100%. The part that seems to be lost in the exchange this morning is this:

If diaspora* ever supports AP, then it is likely in the form of an external service, just like we handle Twitter crossposts.

I don't know what the AP integration will look like. Is it an app? Is it a side car service of some sort? Is it something else? Who knows? I'm certain it wouldn't become the lingua franca of Diaspora federation. I imagine the soonest I'd get to look at it seriously will be a year from now. So I'm not going to spend too many brain cells right now worrying about details like that for something so far away.

Even if I had no other higher important (as I've personally ranked them for my own development purposes) Diaspora features/updates I'd rather work on I'd probably still wait at least half a year because of the churn problems @denschub highlighted. I too am following the AP integration discussions across the other fediverse projects closely. I see the chaos that's going on right now too. I don't want to subject myself to it right now either.

As an end user I don't care about the how I care about the existence of it in some form eventually. I'm going to just leave it at that point until I get within a reasonable time frame to look at it.

[jaywink]

Wow, that is a lot of text without answering the question at all. I still don't see from Diaspora protocol perspective what are the blockers in federating a Diaspora style platform using AP as a framework. The time for generic "what is AP good for" and discussing whether it is bad or not is long gone. It is here and people are adopting it. If the Diaspora project wants to say "nah it's shit, we're not doing it", then that is a reason, but it isn't a technical one.

Any concrete technical questions on how something in Diaspora would work in an AP context I'm sure many people would be happy to answer (including myself). For generic AP discussion this is most definitely the wrong forum - I would suggest the W3C social issue tracker or irc channel.

If diaspora* ever supports AP, then it is likely in the form of an external service, just like we handle Twitter crossposts.

Cross posting is not federation. That would be a shame if the implementation was one way only.

[SuperTux88]

I still don't see from Diaspora protocol perspective what are the blockers in federating a Diaspora style platform using AP as a framework.

Well, if we would replace salmon with AP, that wouldn't change much besides having more JSON and less XML, it still wouldn't be compatible with anything because it would still be a diaspora specific protocol (diaspora dialect of AP). It would only add work and doesn't add any value. AP doesn't magically mean compatibility, and that's what @denschub answered.

If the Diaspora project wants to say "nah it's shit, we're not doing it", then that is a reason, but it isn't a technical one.

Nobody said that. AP is great, and it's exactly what it wants to be (a framework), but people want it to be more and think that everything that talks AP is compatible, but that's not the case. There is currently no reason for us to switch to AP, because our protocol just works fine, and as said, it wouldn't magically add compatibility, it would just add work and probably new bugs.

And there are also other problems that come with AP, but I'm not going to repeat the whole comment of @denschub :)

[jaywink]

@SuperTux88 I wasn't arguing that Diaspora should immediately start work on AP. I was just disagreeing to this:

No, it is not. There are issues by-design with ActivityPub that completely disagree with what diaspora* is doing in terms of communication reliability, predictability, and general user-friendliness.

I don't see those issues. Dennis didn't list anything. What he wrote was a more generic critique of AP.

Of course nothing magical would happen should Diaspora start to work on AP. Of course it would be a huge amount of work. Btw, there is no "pure AP" - it would anyway be a Diaspora dialect.

but people want it to be more and think that everything that talks AP is compatible, but that's not the case

Who are these people? I doubt anyone who has even looked at the spec thinks that everything that utilizes AP should be automatically compatible to all the other implementations. That is not realistic. I don't know of any AP implementation like that. And there will never be one. One simple reason is delivery which is outscoped from the spec. That doesn't mean project maintainers cannot build compatibility for several "flavours". But a single implementation simply cannot be compatible fully with anything except itself.

Great that the Diaspora project is happy with its protocol, that is fantastic 🎉

[wizzwizz4]

Ok: TL;DR, ActivityPub is like Blockchain. Hypothetically, though, if somebody wanted to claim the $500 (at time of writing), what would the implementation look like?

• An external service that allowed connection to Mastodon in the same way as Twitter.
• A replacement of Salmon with ActivityPub, which would allow some things to be sent to and from Mastodon, some things to be sent to and from JetLovers, causing a UX mess.
• An external service which would allow some things to be sent to and from Mastodon, some things to be sent to and from JetLovers, handling that in a sane way.
• Something else.

Because I'm still not convinced that compatible communication over ActivityPub cannot be done, if you know what each flavour supports (sending them only what they support) and have a decent fallback for receiving everything that supported flavours can throw at you. And that wouldn't require an overhaul of the whole system.

Disclaimer: I am completely ignorant of this whole thing.

[CSammy]

Just highlighting a few things.

@jaywink said:

Wow, that is a lot of text without answering the question at all. I still don't see from Diaspora protocol perspective what are the blockers in federating a Diaspora style platform using AP as a framework.

I see this answered in the post of @denschub:

The current modus operandi seems to be to just look at Mastodon and copy their implementation because that seems to be the only way to get something working. That, however, is not about supporting AP, it's about supporting Mastodon's dialect of AP, and their subset of that.

And @SuperTux88 answered the very same question, by approaching the problem from the other side.

Well, if we would replace salmon with AP, that wouldn't change much besides having more JSON and less XML, it still wouldn't be compatible with anything because it would still be a diaspora specific protocol (diaspora dialect of AP).

As it is, it would introduce more complexity (if supporting both approaches, diaspora*-specific plus diaspora*'s dialect of AP, or plus Mastodon's dialect) or just flat out throw out all the work a lot of people did in stabilizing diaspora*'s protocol, and bind huge resources on building yet another incompatible dialect of AP. Yes, that's possible. Sorry, it's of no use to diaspora*. What benefit would there be except for "Yay, we have a less strict and more error-prone protocol implementation now, and we can get a press release out of it that sounds good."

[goobertron]

As the people who currently have the most in-depth knowledge of Diaspora's code/architecture don't think that there is currently a workable implementation for AP within Diaspora, the onus is surely on someone who believes that there is a workable implementation for AP within Diaspora to propose that, with a schema/etc.

But this discussion should be happening in Discourse, shouldn't it? There is a link in that Discourse thread to Dennis's long blog post about AP, which I imagine contains some of the detail people have been asking for in the last few comments here.

[annando]

The current modus operandi seems to be to just look at Mastodon and copy their implementation because that seems to be the only way to get something working. That, however, is not about supporting AP, it's about supporting Mastodon's dialect of AP, and their subset of that.

Friendica is not doing so. I implemented the AP protocol in a way that it fits to the way Friendica works. When I had been unsure, I talked about it in the Matrix room of the Social CG. My implementation created incompatibilities to Mastodon in some way. But then I opened corresponding issues. These have mostly been fixed by now.

[denschub]

Okay, this conversation here actually serves no purpose anymore, I fear. The arguments here show that there are conflicting interpretations of what a standard should be. And that's probably fine, but given the circumstances, this discussion will not yield any results.

Yes, @jaywink, you are right, my comments are generic critique of AP, and that's precisely the point. AP is not designed as something to just work, but as a framework for people to build their own stuff. You're claiming you can't imagine someone expecting AP just to work, yet, in the initial post by @evanp, he is talking about "get[ting] a truly federated network working," and so are others, as you can follow up on Discourse. Sprinkling a bunch of AP on an implementation is not going to make "one large network of different implementations" happen, and we all agree on that.

To some, having AP as a buzzword for a "kinda similar, but not compatible" communication channel is fine. We all can acknowledge the SocialWG's plan of building a transport protocol without actually building something concrete (and no, that's not me saying things, that's literally the SocialWG's charter.), and if we take that as a goal, then cool, there we are. Comments like "go to the SocialWG issue tracker" are, btw, also highly inappropriate. What I am describing as "too much flexibility" is not a bug, it is the literal design behind AP, and a bug suggesting to define a set of required attributes, objects, and actors, would be wontfixed immediately, as it would literally violate the goals of the WG and AP itself.

Others, however, have a different opinion. While some think it's perfectly fine that implementations have to talk to each other and that projects have to implement "compatibility for several 'flavours'" of a given specification, I wholeheartedly disagree, and that will not change, no matter how long we end up sinning in circles here.

To me, and it happens that everyone in the diaspora* core team agrees, this is not perfectly fine. In fact, I think it's bad. To me, a specification is a reference document to follow during implementation, and the mere reason the specification exists is that I don't have to look at what other implementations are doing. In my opinion, as soon as you need to look at other applications to know what you should implement, the specification failed, because it no longer is the source of truth, and thus, it's not specifying anything. We don't need a spec for that. And with the current state, most projects should label themselves as "Mastodon-compatible" instead of "ActivityPub-compatible," because that's closer to reality than everything else.

I really tried my best to explain my reasoning; in a lengthy blog post (which, btw, got support from people inside the WG, and we agreed that there is no black and white here), in multiple comments on Discourse, on GitHub, and on other social media, to explain the risks of basing social network communication on something with such high levels of ambiguity, and I tried my best to explain why I think this is something terrible for end users, from both the "it kinda works" communication channel and the unified marketing label "ActivityPub". It saddens me quite a bit that some people just walk over all that, discarding those concerns as "no real issues," but I can accept that to some projects, this is simply not a concern.

There are different projects out there for a reason. That's always been the case, and it always will be the case. In computer history, there never was "one thing to solve everything," and there never will be. Especially in social media, there are too many conflicting demands and ideas for that even to be possible.

---

@annando Even though we've just talked a couple of days ago, I'll say it again: looking forward to your blog post on the issues you faced while implementing AP. I'll keep my part of the promise as well, and will make sure I either publish a revised opinion, or to follow up with questions on that. 🙂

---

There is no point in continuing here, as there are two contradictory views on what a "standard" should be. That's not going to change, no matter how many hours we spend here. Continuing here will lead nowhere besides a place where people start getting ad hominem again, but this is not the right place for that. Feel free to shitpost about me on social media for locking this.

If someone steps by and is seriously interested in adding an AP service, propose your implementation on Discourse.

[cmrd-senya]

I've read your discussion and have a thought I'd like to share.

What I understood is that AP is a framework. But a framework for what? I'd say that we can see it as a framework for creating federated protocols. It's like OAuth2 is a base framework for creating authorization protocols like OpenID Connect. Or like XMPP which defines some basic features in some RFCs and has lots of extensions in the form of XEPs. So I agree that "implementing AP" in diaspora* doesn't make sense itself. What would make some sense is to create a custom protocol (a dialect) based on AP for diaspora. Such dialect should be specified strictly without the ambiguity about what we send and what properties objects have.

We can't discuss implementing AP for diaspora because it makes no sense because of the AP ambiguity. So if there is anyone who wants to move on with supporting AP in diaspora, the first step to take would be to specify with some strict documentation the AP based protocol which is satisfactory for diaspora. I don't think anyone would be against it if someone will work on creating such specification. It could even be fun to discuss and work on. However that must be kept in mind that nothing guarantees that we will eventually implement this specification in diaspora. But there is no sense to discuss the topic of "AP in diaspora" before we have the specification of the dialect which would fit diaspora. As soon as we have such specification we can consider our resources and do some experiments if it is approved by the core team.

So if there is someone who is strong about the idea of diaspora working with something based on AP for federation, they should consider writing the AP based protocol specification for diaspora and only then propose this specification for implementation in diaspora. Working on such specification doesn't require any approval from the core team so this someone can just start working on it.

Everything written above is my personal opinion though and may differ from the core team members opinion.

[deutrino]

Does it make sense now?

[MasterOfTheTiger]

@deutrino Whether it makes sense to federate via ActivityPub or not is not the issue. The issue is how diaspora* would implement it (if I understand it correctly).

[wizzwizz4]

I've been thinking about this for a few months, and I'd appreciate somebody tearing my proposal into shreds:

When establishing ActivityPub federation, detect what we're talking to. Then, mash stuff we send it into a format it can understand, and convert stuff that doesn't exist in Diaspora* into a format Diaspora* can understand.

For example: if a Diaspora* instance wants to federate with the Jen's Travel Associates forum, which only allows communication via geotagged images, Diaspora* might "import" posts as a WhatFreeWords followed by an image, and "export" them as SVG files tagged at Null Island (or the same place as what they're replying to). Crude, yes, but it permits communication between vastly different platforms.

For a less pathological example: Mastodon "importing" can be as simple as escaping the plain text (so [test](https://looks.like/a-uri-doesn-t-it) doesn't get interpreted as a link, etc.) and slapping the images-plus-alt-text at the end. Similarly, "exporting" is as simple as compiling the Markdown to HTML, since iirc Mastodon clients can display bold and code even if the servers don't support posting formatted text.

I suppose this isn't really "supporting ActivityPub", since that's too ill-defined to be possible; it's simply supporting most ActivityPub-based systems. Even crude support would be amazing: establishing just some form of communication is preferable to no communication.

If this proposal isn't utterly useless, then the obvious next question is: what would this look like?

[6543]

I know about the privacy concerns of ActivityPub but it seams to be the successor ....

so my idear is this:

• Diaspora -> Diaspora uses still its privacy frendly protocoll
• Diaspora to XY uses ActivityPub ... so we dont dry out on our diaspora iland :(

[deutrino]

Might it not make sense to push all posts that are visible to public (or, to a user-configurable set of aspects) to the AP fediverse, and do essentially what @wizzwizz4 suggests (#7422 (comment)) in reverse in order to display incoming posts semi-intelligibly in with the Diaspora news feed?

[wizzwizz4]

Also, it'd be good if you could send messages to Mastodon users… though that's difficult to implement, since you'd need a warning saying "server owner will be able to read this" (as I understand, Diaspora supports encrypted messages and Mastodon does not).

@deutrino How do you envisage comments on ActivityPub posts working?

[annando]

@wizzwizz4 @deutrino it does not make sense to discuss about some partly protocol implementation. The issue is about implementing the ActivityPub protocol as an additional protocol in Diaspora. And according to the comments in this thread no one from the core team is working on it or plans to do so - which has to be respected.

So until there isn't some new contributor or some change in mind it doesn't make sense discussing about details of an implementation that isn't expected to come.

[goobertron]

@wizzwizz4 @deutrino, please read the comments above yours, particularly those from core team members (shown by the 'Member' flag at the top of their comments. You'll see that until AP itself changes, it's not going to be implemented in diaspora*, as @annando has just said.

My suggestion, made at the beginning of the year, was:

As the people who currently have the most in-depth knowledge of Diaspora's code/architecture don't think that there is currently a workable implementation for AP within Diaspora, the onus is surely on someone who believes that there is a workable implementation for AP within Diaspora to propose that, with a schema/etc.

But this discussion should be happening in Discourse, shouldn't it? There is a link in that Discourse thread to Dennis's long blog post about AP, which I imagine contains some of the detail people have been asking for in the last few comments here.

Feel free to contribute to the discussion on Discourse (after reading it first, of course, to see whether or not you suggestions have already been addressed). You can use your GitHub account to sign in to Discourse, so there's no need to create another account.

[denschub]

Thank you, Goob.

In addition to the comments above, I will now close this issue. There are no immediate plans to implement AP/AS inside diaspora* in any form, so I don't think it is worth having an issue open. My primary motivation for closing is the fact that there are USD 513 worth of bounties placed on this bug, and by leaving this bug open with no plans to act on it, we're effectively holding that money hostage. When the issue is closed and processed by Bountysource, the people who decided to put money on this issue can either receive a refund, or choose to put the money into other matters. I think this is a much fairer approach than leaving this open and not doing anything about it.

To stop people posting on a thread where nobody reads it, I'll also lock this issue. If someone has new arguments, please raise them on Discourse, as explained by @goobertron above. If we change our decision and want to work on adding AP/AS support actively, we can either reopen this issue or open a new one.