Do we need direction in existing PUT /v1/graphs ?

[prestonzendev]

No description provided.

[prestonzendev]

@wilwade Based on the call I had with @aramikm and @p5150j this is something that we are looking to you on feedback / thoughts on.

[JoeCap08055]

direction is included per-connection, there is not a concept of direction for the entire request, I believe

The endpoint accepts an array of connections, and the graph service will convert them into actual graph updates based on whether or not they already exist in the user's graph.

One thing we do appear to be missing in graph-service, however, is a way to remove a connection...

[aramikm]

But we have a connectionType per connection which already captures that sentiment. I'm skeptical why we might need direction.

Example:

{
  "dsnpId": "2",
  "connections": {
    "data": [
      {
        "privacyType": "private",
        "direction": "connectionTo",
        "connectionType": "follow",
        "dsnpId": "3"
      }
    ]
  },
  "graphKeyPairs": [
    {
      "keyType": "X25519",
      "publicKey": "0xd43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d",
      "privateKey": "0xd43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d"
    }
  ],
  "webhookUrl": "http://localhost/webhook"
}

[aramikm]

So it appears that the direction might have been defined to be used for removing a connection but I think we might need a better design for Updating the graph

export enum Direction {
  ConnectionTo = 'connectionTo',
  ConnectionFrom = 'connectionFrom',
  Bidirectional = 'bidirectional',
  Disconnect = 'disconnect',
}

[JoeCap08055]

But we have a connectionType per connection which already captures that sentiment. I'm skeptical why we might need direction.

Ah, I wasn't clear on the context of the question.
direction was copied from reconnection-service, which needs to know whether this is an entry in the user's graph, or if it is an entry in the 'followed' party's graph for purposes of scheduling additional graph updates.

We probably don't need it, then, in graph-service.

[aramikm]

I think using the same types as what we defined in graph-SDK might be more intuitive

export interface ConnectAction {
  type: "Connect";
  ownerDsnpUserId: string;
  connection: Connection;
  dsnpKeys?: DsnpKeys;
}

export interface DisconnectAction {
  type: "Disconnect";
  ownerDsnpUserId: string;
  connection: Connection;
}

I'll create a new ticket for that

[JoeCap08055]

Yes.
I think the issue is that graph-service copied a lot from reconnection-service, which is a different use case. reconnection-service is about syncing state (ie, "here's a list of connections my provider knows; make sure my graph reflects this state"). graph-service is about taking discrete actions (ie, follow/unfollow).