implement ActivityPub to enable federated Inventaire instances

[maxlath]

This issue isn't a todo, rather a way to investigate and document a possible future:

Steps

1. Move Inventaire entities to a Wikibase instance (move Inventaire entities to a Wikibase instance #186), that would be the main non-decentralized service among federated Inventaire instances, the idea being that decentralizing this knowledge base would be pure waste of contributors efforts, which would have to re-do the work on every instances.

2. Turn Inventaire into an ActivityPub-powered social network

• turn additions to inventories (currently known as items rename items into <name to be found> to let the (currently named) entities be called items #180), collections ([new feature] entities lists #184), reviews ([new feature] book review #185), transactions actions and messages into ActivityPub events
• find a solution to the problem of indexing inventories per entity URIs over the fediverse (see discussion on federated indexation)

Other services that could benefit from not being decentralized, or at least to offer the option to use a common instance between several instances:

• The entities search engine: the entities remaining centralized, all running a search engine could just be a waste of resources(?)
• A registry of compatible inventory providers (like libraries, bookshops, etc) and Inventaire instances(?)

Pros

• centralizing everything has never been the goal of this project: the vision is still to aggregate information on resources from different providers, be them peers, libraries, or bookshops
• that would probably bring more code contributors, just interested in improving/customizing their instance, giving the opportunity to explore adding new kinds of resources beyond books in a full bazar way
• decentralization is cool ;)

Cons

• Federation is still difficult to understand for many people used to centralized services
• And then even for tech-saavy people, federation is hard: which instance should I choose, etc
• Quality of service is hard to keep consistent over many instances, run by a diversely qualified crowd of sys admins and/or amateurs. Several issues on Mastodon seem to be related to this: mismatch between following/followers count and the actual list, cross instance lags, etc
• Yeaah let's do all the work, and let a startup deploy it's customized version with ads and affiliation to Amazon on every pages, hurraay...

Questions

• Is that even possible? Inventaire isn't "just" a microblogging platform, there are some heavy optimization to do to be able to display inventory content in a meaningful way, etc, how would that work over the fediverse? Discussing this possibility with @Chocobozzz, ActivityPub seems fit to activity streams, not to browsing large inventories over a myriad of instances(?)
• Wouldn't that just create a lot of duplicated content? All the pages on entities (authors, works, series, etc) would be basically the same over each instances, with the only difference being the related inventory items being shown: to which page should you link when you want to link to this entity for the information on entity it provides, not for the inventory feature?

Requirements

• full import/export features to be able to move an account to another instance: it is currently possible to export an inventory, but not to re-import it in a clean/complete way

[jum-s]

Data transformation of users to create a discoverable ActivityPub actor could be a very first step toward being activity pub compliant, without having to think to much about entities and inventories yet.
Changing how relations and users are implemented today, so a user/actor could become something like this.
This would need to implement :

• a method to resolve links to a resource aka a webfinger endpoint,
• HTTP signatures with generate-rsa
• a followers endpoint
  Once people can follow each other (implemented next week most probably ^^) then we can for example convert rss feeds into activity streams https://github.com/dariusk/rss-to-activitypub/blob/master/updateFeeds.js and focus on entities

[vk0xOrg]

any progress so far?

[maxlath]

@vk0xOrg the informal discussions are accelerating and getting more urging but no code has been written in this direction yet

[maxlath]

cross-posting a discussion from the chat:

Q: could one follow inventaire's user, say from mastodon?

A: no it's not possible at the moment. we are considering using ActivityPub to implement federation features #187 but it's not trivial. In the use case you describe for example, it wouldn't be as easy as just publishing one action per added items, as it's a perfectly acceptable behaviour in inventaire to create a 1000 items at once (either by importing data from another platform or by scanning a large library): just broadcasting that activity on something like mastodon would but zuper spammy. Maybe we could instead generate some sort of summary, like publishing one action saying "user X added 1000 new items to their inventory" with a link to the inventory. Somewhere where we could have a "1 inventaire action = 1 activity pub action" could be with book reviews: it's not expected that people would post a 1000 reviews at once (out of the case where they import reviews from another platform).

[vk0xOrg]

the above sounds cool for me. at the moment I do not know ActivityPub protocol. Following days would try to check it and to see what I can do for this

[maxlath]

Guide for new ActivityPub implementers

[jum-s]

Some take away of AP exploration so far : mainly those articles, darius express example repo and the w3c specs: vocabulary and the basics:

• "An activity is delivered to its targets (which are actors) by first looking up the targets' inboxes and then posting the activity to those inboxes." "The inbox is determined by first retrieving the target actor's JSON-LD representation and then looking up the inbox property."
• "For federated servers performing delivery to a third party server, delivery SHOULD be performed asynchronously, and SHOULD additionally retry delivery to recipients if it fails due to network error. "
• inboxes are stored as actorUrl+'/inbox'
• "Servers SHOULD validate the content they receive to avoid content spoofing attacks." source
• "The request contains a Date header. Compare it with current date and time within a reasonable time window to prevent replay attacks." source
• "You need to include an inbox even if you don’t plan on receiving messages in response, because for legacy purposes Mastodon doesn’t acknowledge inbox-less actors as compatible." Meaning there is no need to setup inboxes if inventaire does not talk to masto source

To me the next step toward implementing users inventories activity streams would be to define what activity types to use (Accept, Create, Delete, Follow, Remove, Update)

[jum-s]

an example of activityPub implemented in a book sharing context

[jum-s]

new feedback from AP exploration, with a bunch of decision-related questions to figure out, before even considering to follow people from two inventaire instances

• Webfinger: do we use webfingers ? Which is technically not AP but most implementers use it (peertube, funkwhale, pleroma)

• Auth: server to server. 2 options through HTTP or through Linked Data. HTTP seems lighter. If we agree on HTTP signature, 2 features to implement: signature verification from remote instances and signature verification on incoming activities. RSA key pair got to be generated for each actor/user (at user creation, or at their first "federation opt-in" in user settings)

Those bring a larger question : is inventaire AP designed to be fully interoperating with Mastodon ? (implying extra work like implementing inboxes and webfingers for example). As this detailed report puts it :

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.