Hi everyone,
just to inform you that I’m starting to work on a new contrib application to allow XWiki to be part of the fediverse by implementing the ActivityPub protocol.
Note that this work is funded by the NGI Search & Discovery call.
I don’t have anything to show yet, but I’ll keep you informed here.
For full visibility and disclosure, here’s the project we submitted and that is sponsored by the NGI Search & Discovery call.
Can you explain the whole project and its expected outcome(s).
Please be short and to the point in your answers; focus primarily on the what and how, not so much on the why. Add longer descriptions as attachments (see below). If English isn’t your first language, don’t worry - our reviewers don’t care about spelling errors, only about great ideas. We apologise for the inconvenience of having to submit in English. On the up side, you can be as technical as you need to be (but you don’t have to). Do stay concrete. Use plain text in your reply only, if you need any HTML to make your point please include this as attachment.
So far, XWiki has been focusing on providing the best collaboration experience and features to its users. It’s now the right time for XWiki to start collaborating externally and be part of the larger federation of collaboration and social software (a.k.a. fediverse). The proposal is to achieve this collaboration by embracing the W3C ActivityPub specification (https://www.w3.org/TR/activitypub/) and becoming compliant with it. More specifically to implement at least the server to server part of the specifications and be able to both view activity and content happening in external services (such as NextCloud, Discourse, Mastodon, PeerTube, Friendica, Plume, etc) inside XWiki itself and to make XWiki’s activity and content available from these other services too. Similary, we would also like to consider XWiki as an external service and work on the XWiki federation itself. This means considering the various XWiki instances around the world and be able to share activity and content between these instances.
Note: We use AP below this point to mean ActivityPub.
General information about AP:
Groundwork:
UC1: Personal Following/Followers
UC2: Global Following & Content viewing
UC3: Expose XWiki Content
UC4: Messaging
For all use cases:
Future use cases (not planned for this first grant. Candidates for future work):
It should also be noted that while there are a number of solutions already implementing at least partly ActivityPub, there is no wiki engine currently implementing it (the closest to the wiki approach might be Dokieli, but it has only basic wiki features). This would make XWiki a pioneer and possibly inspire others. The recent Wikipedia outage shows that a new generation of solutions is needed for enhanced resilience. Decentralized wikis can be a good solution.
Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?
XWiki SAS (the main company sponsoring the development of the XWiki open source software and of Cryptpad) has participated in several research projects in the past that are are relevant to this domain:
The outcomes of the project will be published as an XWiki Extension and thus installable and usable immediately (through XWiki’s Extension Manager) by the 7000+ current active installations of XWiki over the world.
Compare your own project with existing or historical efforts.
Compared to the experiments done in the “Past Experience” section above we believe that AP is more interesting as it’s a standard specification that applies to all content/activity software. Once we implement the specifications in XWiki, this makes XWiki interoperable with all other software implementing AP too (In practice this won’t be completely true since the specifications leaves some areas underspecified and open but it makes partially true and the remaining work to make it work with a specific software is marginal). If AP catches on and more and more software/services implement it, it would be a game changer for interoperability over the internet and a win for open standards and for XWiki.
What are significant technical challenges you expect to solve during the project, if any?
The main challenge we foresee are differences in the various actor’s AP implementations. This can happen for 2 reasons: the AP specification is underspecified in some areas and thus leaves it open for interpretation (such as authentication) and it’s also extensible and thus if we want to benefit from the extension inside XWiki we would need to discuss and interact strongly with the actors to understand how they extended the AP formats.
Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?
We propose to interact and integrate with at least 2 other actors (NextCloud and Discourse) to make sure XWiki’s AP implementation and these actor’s AP implementation work well together.
We will also promote search and discovery and AP virally through the fact that XWiki is open source and well known and used over the world but also through XWiki SAS’s regular technical conferences attended every year around XWiki’s technologies (XWiki SAS does between 10 to 20 events annually at various conferences).
Attachments: add any additional information about the project that may help us to gain more insight into the proposed effort, for instance a more detailed task description, a justification of costs or relevant endorsements. Attachments should only contain background information, please make sure that the proposal without attachments is self-contained and concise. Don’t waste too much time on this. Really.
And here’s the research I had done on this topic. Maybe it can be useful.
2 parts:
Implementations:
Most implement part 2 only.
part 1: decentralized websites can share information
part 2: users, including real-world users, bots, and other automated processes, can communicate with ActivityPub using their accounts on servers, from a phone or desktop or web application or whatever
“ActivityPub implementations can implement just one of these things or both of them. However, once you’ve implemented one, it isn’t too many steps to implement the other, and there are a lot of benefits to both (making your website part of the decentralized social web, and being able to use clients and client libraries that work across a wide variety of social websites).”
Activity Stream 2.0:
“To build a valid Activity Streams activity, you pick one of each category and add some metadata to it. You describe that something did something to or with something, and you explain those things in more detail.”
Haven’t found any proper java library to help implement ActivityPub. Some projects that can help:
Good links to understand it:
Implementations seem to be quite specific and under-specified. For example for Mastodon: “Applications interoperating with Mastodon over ActivityPub must support Webfinger resolution, with a unique preferredUsername per host, so that they can be interacted with by other users. Posts to the inbox must be signed using the HTTP Signatures draft spec with a public key that can be fetched from the actor, using the publicKey object format from the WebPayments JSON-LD Security Vocabulary.”
“If you are not too familiar with web terminology, think of ActivityPub as the postal service. The postal service drives around and delivers letters into inboxes, but it does not care about what actually is inside those letters. This is not a perfect analogy, but close enough.”: this shows that interoperability with ActivirtyPub is going to be messy…
Chat:
There’s a “source” property for defining the format of the content, see https://www.w3.org/TR/activitypub/#source-property. Check the note that is very interesting to understand how client should allow editing mediatype they don’t understand.
Implementation notes: