Implement good layout algorithm server side

[utunga]

Summary

When a user is looking at their position on 'the graph' they will see their own node in relation to other nodes.

For this reason we need a 'primary' / default layout for all nodes. At least in the fully zoomed out case.

This default or primary layout can be used to 'seed' positions in the layout on the phone.

NB See here for more background context on this project
https://utunga216.medium.com/the-together-project-8884e7521e35

Acceptance Criteria

• When a user opens the 'graph layout' all users see, roughly, the same layout of nodes and it 'persists' between sessions
• The layout is as 'meaningful' as possible in terms of conveying useful information about who is who in the larger network and who is semantically 'close' to who else
• A process runs on the server which adjusts / recomputes the global layout periodically - eg every 4 hours.
• When the layout is recomputed it is (ideally) done in a way that factors in new information without drastically altering the specific positions from the previous run (ie small changes only). This should be possible by seeding the next run with positions from the last run
• If nodes or edges are added in between re-computation of the overall layout they still appear on the graph, defaulting to positions dictated by simple force layout relative to the positions of the nodes/edges that already exist.
• The code to do this can run on a server, in ec2, connecting to dgraph and then potentially writing positions back to dgraph (or providing to the mobile app in some other way) probably in python or rust (discuss with @utunga if another language is preferred)

Discussion

Seeding of positions

The phone will apply a simpler force layout style layout - which will preserve the 'bounciness' vibe of the graph - but if the positions are seeded (and, if necessary, the edge distances adjusted somewhat to match the current global layout) then we can maintain a degree of 'persistence' between different visits to the layout graph and also give a more 'meaningful' layout than is possible with a simple force layout algorithm

Persistence of positions

The appearance of persistent positions will preserve the all important illusion that the layout is something 'out there' in the world and somewhat concrete and not so arbtirary.

Meaningful global topology

Basically we want people to be able to see at a glance that similar people / people that work together a lot and/or interact with each other a lot are 'close' on the layout.

While understanding that no 2-d layout can preserve a higher dimensional information, we do want the overall layout to preserve as much global information topology as possible. This is not really possible with a simple 'force layout' algorithm.

For this reason, it is thought that we implement UMAP on the server (or failing that something similar)
https://umap-learn.readthedocs.io/en/latest/

We could, of course, implement directly in Dart on the phone, but it is probably not doable to keep it performant in this case, that's why it's thought to be better to go for pre-calculating the layout on the server. We could use any code on the server, but python or rust are front runners for various other reasons.

The primary 'edge strength' between nodes should be based on 'acknowledgement' edges. However we may also want to experiment with adding edges to hashtags (for any case where a user has a request, skill or acknowledgement with a hashtag link them to that hashtag). If we let hashtags appear as nodes on the graph they will be of secondary visual importance but they may well be highly useful as an addition for preserving a 'meaningful' global layout.

Accessing data in dgraph
The data for edges, nodes etc is stored in dgraph - which can be accessed from various clients including python
https://github.com/dgraph-io/pydgraph#creating-a-client