# AD4M Direct Messages

A DM (agent-to-agent) implementation exists in AD4M since fall 2021. While there are tests for this in our CI, we have no UI.

It is both specced out in an interoperable way as **DirectMessage Language**, and we also have an implementation for this interface, based on Holochain.

This Holochain implementation uses p2p signals if the receiving agent is online, and posts an encrypted entry to the DHT if not.

AD4M Direct Messages are conceptually linked with AD4M **Friends**, since adding someone as a friend, makes the Executor install the other agents DM Language, which in the case of our Holochain implementation means: friends show up as relays for Direct Messages, if the receiving agent is offline at the time of sending.

## Possible UI implementations
### 1. Adding a new DM UI component to Flux
#### Pros:
* Adding another feature to Flux which gets it closer to the feature-set of Discord
* No need to switch apps
#### Cons:
* A full new component makes the bundle size of Flux bigger
* Only makes sense if we pull in the concept of friends into Flux as well, which would better be situated at the AD4M Launcher level
* Conceptually a new domain to Flux which so far focusses only on inter-Neighbourhood communication

### 2. Adding UI for friends and DM to AD4M Launcher
#### Pros:
* Provides actually meaningful UX to user through the launcher
* Communicates the "agent-centricness" in a pragmatic way: agents (friends) exist outside of AD4M apps
* Bundle size is not an issue because it's an installed app
#### Cons:
* We don't get a mobile version of DMs for free this way, since we currently don't have a way to use the Launcher UI through a proxy

### 3. Build a new DM / Messenger App
#### Pros:
* Following through on AD4M's interoparabitly claims, we need more apps. This would be a low-hanging fruit
* No bundle-size issue, mobile usability through proxy
#### Cons:
* Overhead of introducing a new app

## DMs through Perspectives?
We discussed the possibility of introducing meta-Perspectives that have an AD4M-executor internal connection to the DM logic, such that the UI could receive and send DMs by interfacing with that perspective.

#### Pros:
* Flux' chat UI component could be reused, which would remedy one of the cons of the Flux DM implementation
#### Cons:
* Mixing of two distinct concepts: a shared perspective between only two agents is already possible and just be another Neighbourhood
* DMs share PerspectiveExpressions, Flux chat view works only on chat messages. This solution only makes sense as a partial implementation/use of AD4M DMs

## DMs in specific channels of a Neighbourhood?
Another strategy that was discussed is to just have special Flux channels within a Neighbourhood for DMs between agents and then hide these channels in the Flux UI.

#### Pros:
* Can be implemented very quickly
#### Cons:
* These are not direct messages at all. Even if the messages get encrypted, the Neighbourhood gets cluttered with information that doesn't belong there / is meant as content of the shared Perspective
* Raises the question of which Neighbourhood to choose when two agents share more than one Neighbourhood
* Does not enable agents to share an invite link to a Neighbourhood if they are not already in a shared Neighbourhood