# Besoins extension ActivityPub pour SemApps

Si l'on veut ajouter une extension ActivityPub à SemApps, par exemple via un système de plugin, il faut que cette extension ait accès à un certain nombre de services. En s'assurant que les points ci-dessous sont respectés, on pourra développer une architecture de SemApps suffisamment modulable pour permettre une intégration harmonieuse entre ces deux briques (et plus tard, avec potentiellement d'autres extensions)

> Note: Les besoins exprimés ci-dessous concernent également les besoins spécifiques au serveur Reconnexion, qui sera développé dans un premier temps dans le cadre de Colibris.

1. Pouvoir gérer des routes directement via ExpressJS (`/.well-known/webfinger`, `/actor`, `/activity`, `/device`, ce dernier endpoint concernant les notifications push)

2. Pouvoir se connecter via le système d'authentification [CAS](https://github.com/OceanXuY/cas-authentication), en plus d'OIDC (c'est ce qui est utilisé pour le SSO des Colibris)

3. Être averti lorsqu'un nouvel acteur (utilisateur, organisation...) est créé / édité / supprimé et pouvoir enrichir le profil WebID avec des données propres aux [Actors AS](https://www.w3.org/TR/activitypub/#actor-objects) (y compris les liens vers `inbox`, `outbox`, `followers`, `following`, `liked` qui seront gérés par l'extension ActivityPub)

4. Être averti lorsqu'un nouvel objet est créé / édité / supprimé, afin de générer les activités `Create` / `Update` / `Delete` correspondantes et pouvoir enrichir les données avec des propriétés des [Objects AS](https://www.w3.org/TR/activitypub/#obj) (y compris les liens vers `likes` et `shares` gérés par l'extension ActivityPub).

5. Avoir un accès direct au dataset principal du triple store, où sont stockés les objets (via SparQL ou autre ?). Si l'on choisi de stocker les activités AS dans le triple store, pouvoir créer et gérer un autre dataset.

6. Pouvoir ajouter / éditer / supprimer des objets JSON-LD directement sur le serveur LDP, et recevoir en retour l'URI de l'objet. Cela est nécessaire pour gérer les activités `Create`, `Update`, `Delete`, `Offer`, `Undo`, mais aussi l'[importation de masse](https://github.com/reconnexion/reconnexion-server/blob/master/src/Command/ImportCommand.php) et l'[ajout par clé d'API](https://github.com/reconnexion/reconnexion-server/blob/master/src/Controller/ApiController.php).

7. Pouvoir créer un groupe WebACL avec les followers d'un acteur, et le mettre à jour lorsqu'un follower est ajouté/supprimé. Lire les droits attachés à une ressource. Donner les droits de lecture d'un objet à un groupe de followers ou à un acteur en particulier.

## Services possibles

Quelques idées de services dont l'extension ActivityPub pourrait avoir besoin.

- `tripleStore` : Accès direct à Jena via SparQL ou autre (une instance par dataset ?)
- `ldp` : Ajout, édition et suppression des ressources. Utilise le service `tripleStore`.
- `webAcl` : Création et mise à jour de groupes, assignation des droits sur une ressource. Utilise le service `tripleStore`.

## Points de réflexion

- L'utilisation de l'ontologie ActivityStreams pour les [objets](https://www.w3.org/TR/activitystreams-core/#object) n'est pas strictement nécessaire, mais elle permettrait de faciliter l'échange avec les autres logiciels qui utilisent le protocole ActivityPub. Par exemple, si on utilise `ActivityStreams#Event` pour les événements, Mobilizon pourra récupérer ces données. L'interprétation pourrait être codée en dur dans l'extension ActivityPub, mais il faudrait réfléchir s'il y a un moyen d'automatiser la "traduction" entre ontologies, afin par exemple qu'un événement défini dans l'ontologie PAIR puisse être automatiquement "mappé" sur l'ontologie ActivityStreams. Le standard OWL permet-il de tels transferts ?

- Si on décide de créer automatiquement un flux activitées en fonction des opérations CRUD effectués sur le serveur LDP par les acteurs, il faudra faire attention aux WebACL. Un objet qui n'est pas public ne devrait pas apparaître dans le flux d'activités, ou alors il ne devrait être adressé qu'aux acteurs qui ont le droit de lecture sur cet objet.

- A moins que SemApps gère dès le début le versionning, il sera sans doute nécessaire d'enregistrer les objets AS sous forme de JSON brut, afin qu'on garde la trace des différentes modifications.