Implicit joins of agents - How to deal with it

[KaiTries]

An agent needs to be present in a workspace if he wants to interact with it. In cartago this means he needs to have joined the workspace. Currently the "focus", "instantiateArtifact" and "doAction" operations all implicitly make the caller join the workspace.

private void focus(
      final String agentUri,
      final String workspaceName,
      final String artifactName
  ) throws CartagoException {
    this.joinWorkspace(agentUri, workspaceName); // <- implicit join
    final var workspace = this.workspaceRegistry.getWorkspace(workspaceName).orElseThrow();
    workspace
        .focus(
            this.getAgentId(this.getAgentCredential(agentUri, workspaceName), workspace.getId()),
            p -> true,
            new NotificationCallback(this.httpConfig, this.dispatcherMessagebox, workspaceName,
                artifactName),
            Optional.ofNullable(workspace.getArtifact(artifactName)).orElseThrow()
        )
        .forEach(p -> this.dispatcherMessagebox.sendMessage(
            new HttpNotificationDispatcherMessage.ArtifactObsPropertyUpdated(
                this.httpConfig.getArtifactUri(workspaceName, artifactName),
                p.toString()
            )
        ));
}

This has some unwanted effects.

• No leaving of workspaces

  Since in all three methods the agent is just joined, the agent will never leave the workspace, which could cause issues in long running systems.

• Ghost agents

  No representation is created for these agent bodies and users will be unaware of their presence.

Possible solutions

Remove implicit join

The simplest remedy would be to just remove the line from the function, and return an error if the agent is not present in the workspace. This would force each agent to consciously and explicitly join the workspace and then in a second step focus on an artifact.

Extend the implicit join

If we want to keep the implicit join we would have to extend the functionality of the methods. An agent would have to additionally specify the "X-Agent-LocalName" header so that an appropriate body can be created. Also additional update notifications would have to be sent out to subscribers of the workspace to notify the change of the representation due to a new body being present.

Make them leave again (does not work for focus)

For the methods "makeArtifact" and "doAction" it would also be plausible to just make the agent leave the workspace again after the operation has finished.

[danaivach]

Thank you @KaiTries for opening this issue. Here's is my current view, but I'm open to alternative views:

Make them leave again (does not work for focus) Although this offers simplicity for users, and may be better for resource management on Yggdrasil, I think it devalues the concept of embodiment by making it simply a means to an end at the implementation level (it's like using agent info where client info would be enough from an application perspective). Additionally, either of the following implementations comes with considerations:

• We either make an ephemeral joining without storing agent info on Yggdrasil, which would make the agent responsible for artifact creation or action invocation to be untraceable, or
• we make an ephemeral joining that stores agent info in the background, which creates transparency issues.

As pointed out, this also does not work for focus.

I could suggest either making join explicit, or extending implicit join. In either case, I think it is valuable to make the situation as transparent as possible to the client. Both options come with some complexity for the client (requiring to explicitly join and/or leave), but the complexity is bound to the use of the enabled CArtAgO environment. Users that want to avoid complexity (no required join, no focus option, etc.) can disable the environment; users that want to exploit CArtAgO features (including required join, focus, etc.) can enable the environment.

Extend the implicit join It's appealing given that it brings some simplicity for the client side. Transparency could be supported by returning the body IRI in a header value.

Remove implicit join CArtAgO users should be familiar with this. As a variation of this option, the signifier for joining could be returned instead of a sole error. This mimics the common human experience on the Web. @andreiciortea, for extra guidance, we could relate signifiers for makeArtifact, "doAction", and focus to the signifier for joinWorkspace though recommended abilities. This would make the process more explicit and transparent.

Additional considerations Given that the hypermedia environment can be used to represent physical environments and the joining of human agents, this decision may bring implications to human user experience, e.g. upon invoking actions of advertised artifacts.

[KaiTries]

Thanks for the input @danaivach.

I agree that the making them leave option does not need to be further considered and that the focus should be on the latter two possibilities.

I personally think removing the join is more logical in a sense of

• Code -> a function should do one thing and not multiple, joining and focusing are two actions. Since we already have functionality of an agent joining there is no need to pack that into the focus operation. Would give better seperation of concerns
• Mirrors reality -> If a robot is in a room i first need to enter the room to be able to interact with it. Since in the physical world the joining of a room is also not implicit I think making it explicit on yggdrasil would work well.
• Makes further interactions easier -> If we have them join explicitly we can utilize our already existing functionality of managing agent bodies. If it were implicit we would have to implement an additional way of updating the environment with a new body and communicating that with participants.

While extending the implicit join, might feel easier for the client since they will only have to send one request instead of two, we still need to pack all the same information into our response. Even if we just add the newly created body as a link in the header, the agent will then need another request to get the full information on the body either way (e.g. to leave th workspace again).

So currently I see a lot more pros for the explicit join.

[andreiciortea]

Thanks, @KaiTries and @danaivach, for the detailed discussion.

I suggest removing the implicit join as well. An explicit join would then be required to perform any action, including the focus action.

Other points to consider:

• currently, an agent can browse workspaces without joining them; I would support this behavior as default, but I can easily imagine use cases where a workspace should be less open and an explicit join is required to obtain a complete representation
• related to the above, representations of workspaces and artifacts can also be observed openly via WebSub; this means, for instance, that an agent can receive notifications about other agents joining a workspace or artifacts being created in the workspace without having to explicitly join the workspace

I suggest discussing these points and others tomorrow in our f2f meeting — and then adding a summary of our conclusions to the issue.

[danaivach]

Relevant term for differentiating between artifacts hosted on Yggdrasil (also possible to be focused on), and artifacts that are not hosted on Yggdrasil (e.g., physical devices): https://purl.org/hmas/isHostedOn

[KaiTries]

So in short: Specifically this issue it has been decided to remove the implicit join and return a 405 not allowed if an agent tries to do any of the above actions without first joining.

Additionally there was more discussion on how to handle these issues also with external / physical artifacts. And if we need to differentiate between them.