From ddae7f647dc1f7aa1d1324f4fbd1a937bd6935ab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Claus-Peter=20H=C3=BCbner?= Date: Wed, 15 Feb 2023 23:11:16 +0100 Subject: [PATCH 1/8] describe and draw the current federation moduls and handshake --- .../TechnicalRequirements/Federation.md | 47 ++- .../graphics/TechnicalOverview_V1-19.drawio | 282 ++++++++++++++++++ .../image/TechnicalOverview_V1-19.svg | 1 + 3 files changed, 303 insertions(+), 27 deletions(-) create mode 100644 docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio create mode 100644 docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index 959aa8afe..7210756ff 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -4,29 +4,6 @@ This document contains the concept and technical details for the *federation* of But meanwhile the usage of a DHT like HyperSwarm promises more coverage of the gradido requirements out of the box. More details about HyperSwarm can be found here [@hyperswarm/dht](https://github.com/hyperswarm/dht). -## ActivityPub (deprecated) - -The activity pub defines a server-to-server federation protocol to share information between decentralized instances and will be the main komponent for the gradido community federation. - -At first we asume a *gradido community* as an *ActivityPub user*. A user is represented by "*actors*" via the users's accounts on servers. User's accounts on different servers corrsponds to different actors, which means community accounts on different servers corrsponds to different communities. - -Every community (actor) has an: - -* inbox: to get messages from the world -* outbox: to send messages to others - -and are simple endpoints or just URLs, which are described in the *ActivityStream* of each *ActivityPub community*. - -### Open Decision: - -It has to be decided, if the Federation will work with an internal or with external ActivityPub-Server, as shown in the picture below: - -![FederationActivityPub](./image/FederationActivityPub.png " ") - -The Variant A with an internal server contains the benefit to be as independent as possible from third party service providers and will not cause additional hosting costs. But this solution will cause the additional efforts of impementing an ActivityPub-Server in the gradido application and the responsibility for this component. - -The Varaint B with an external server contains the benefit to reduce the implementation efforts and the responsibility for an own ActivitPub-Server. But it will cause an additional dependency to a third party service provider and the growing hosting costs. - ## HyperSwarm The decision to switch from ActivityPub to HyperSwarm base on the arguments, that the *hyperswarm/dht* library will satify the most federation requirements out of the box. It is now to design the business requirements of the [gradido community communication](../BusinessRequirements/CommunityVerwaltung.md#UC-createCommunity) in a technical conception. @@ -41,12 +18,28 @@ To enable such a relationship between an existing community and a new community 2. Authentication 3. Autorized Communication -### Overview +### Overview of Federation-Handshake At first the following diagramm gives an overview of the three stages and shows the handshake between an existing community-A and a new created community-B including the data exchange for buildup such a federated, authenticated and autorized relationship. ![FederationHyperSwarm.png](./image/FederationHyperSwarm.png) +### Technical Architecture + +The previous described handshake will be done by several technical moduls of the gradido system. The following picture gives an overview about the moduls and how the communicate with each other. + +![img](./image/TechnicalOverview_V1-19.svg) + +As soon as a Gradido Community is up and running the DHT-Modul first write the home-community-entries in the database and starts with the federation per HyperSwarm. Each community, which is configured to listen on the GRADIDO_HUB of the DHT will be part of the Gradido-Net-Federation. That means each DHT-Modul of each community will receive the publicKey of all connected communities. The DHT-Modul will open for each received publicKey a communication-socket with the associated community DHT-Modul, to exchange api-version info and hosted urls for later direct communication between both communities. The exchanged api-version info and urls will be written in the own database. + +The up and running Backend-Modul contains a validation logic to verify the community entries from the own DHT-Modul. For each announced but unverified community-entry the GraphQL-Client is used to invoke a getPublicKey-Request. Depending on the containing api-version the matching GraphQL-Client is used and the getPublicKey-Request will be send to the given URL. + +As soon as the FederationModul of the assoziated community received the getPublicKey-request the own publicKey is read from database and send back in the response. + +The GraphQL-Client will read from the returned response data the publicKey of the other community and compare it with the data of the community-entry, which cause the getPublicKey-Request. If they match the community-entry will be updated be inserting the current timestamp in the verifiedAt-field of this community-entry. + +This federation and verification logic will work the whole time and can be monitored by observing the communities-table changes. The Admin-UI will contain a Page to have a look on the current state of the communities table content. + ### Prerequisits Before starting in describing the details of the federation handshake, some prerequisits have to be defined. @@ -235,7 +228,7 @@ For the first federation release the *DHT-Node* will be part of the *apollo serv | communityApiVersion.apiversion | keep existing value | | communityApiVersion.validFrom | exchangedData.API.validFrom | | communityApiVersion.verifiedAt | keep existing value | - * + * 3. After all received data is stored successfully, the *DHT-Node* starts the *stage2 - Authentication* of the federation handshake ### Stage2 - Authentication @@ -284,8 +277,8 @@ As soon the *openConnection* request is invoked: 3. check if the decrypted `parameter.signedAndEncryptedURL` is equals the selected url from the previous selected CommunityFederationEntry 1. if not then break the further processing of this request by only writing an error-log event. There will be no answer to the invoker community, because this community will only go on with a `openConnectionRedirect`-request from this community. 2. if yes then verify the signature of `parameter.signedAndEncryptedURL` with the `cf.pubKey` read in step 2 before - 3. -4. + 3. +4. ### Stage3 - Autorized Business Communication diff --git a/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio b/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio new file mode 100644 index 000000000..534804e1d --- /dev/null +++ b/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio @@ -0,0 +1,282 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg b/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg new file mode 100644 index 000000000..4b407aa5a --- /dev/null +++ b/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg @@ -0,0 +1 @@ +
Community  "Gradido-Akademie"
Community  "Gradido-Akademie"
Gradido - technical Infrastructure-Overview
State of 02.2023
Gradido - technical Infrastructure-Overview...
Backend-Modul
GraphQL-API
Backend-Modul...
CommunityServer DB
CommunityServer DB
Layer 1:
Layer 1:
Layer 2:
Layer 2:
"GDT-Server"
base on C++ + mySQL
"GDT-Server"...
GDT-Server DB
GDT-Server DB
json-
ajax-
request
json-...
Layer 3:
Layer 3:
"Elopage"
external Service-Portal
"Elopage"...
"User-UI"
"User-UI"
graphql
graphql
json-
request
json-...
graphql
graphql
"Admin-UI"
"Admin-UI"
DHT-Modul
HyperSwarm
DHT-Modul...
Federation-Modul
GraphQL-API V2_0
Federation-Modul...
Federation-Modul
GraphQL-API V1_x
Federation-Modul...
Federation-Modul
GraphQL-API V1_1
Federation-Modul...
Federation-Modul
GraphQL-API V1_0
Federation-Modul...
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
Community "GallischesDorf-TBB"
Community "GallischesDorf-TBB"
Backend-Modul
GraphQL-API
Backend-Modul...
CommunityServer DB
CommunityServer DB
Layer 1:
Layer 1:
Layer 2:
Layer 2:
Layer 3:
Layer 3:
"User-UI"
"User-UI"
graphql
graphql
graphql
graphql
"Admin-UI"
"Admin-UI"
 DHT-Socket Communication 
 DHT-Socket Communication 
DHT-Modul
HyperSwarm
DHT-Modul...
Federation-Modul
GraphQL-API V1_1
Federation-Modul...
Federation-Modul
GraphQL-API V1_0
Federation-Modul...
graphQL-Handshake
graphQL-Handshake
GraphQL-Client V1_1
GraphQL-Client V1_1
graphQL-Handshake
graphQL-Handshake
GraphQL-Client V1_0
GraphQL-Client V1_0
graphQL-Handshake
graphQL-Handshake
graphQL-Handshake
graphQL-HandshakeViewer does not support full SVG 1.1 \ No newline at end of file From d6044b4fe61bd26ec0ba7318523d12c1318bbb22 Mon Sep 17 00:00:00 2001 From: Einhornimmond Date: Thu, 16 Feb 2023 14:46:12 +0100 Subject: [PATCH 2/8] correct error with gdt server in graphic --- .../graphics/TechnicalOverview_V1-19.drawio | 144 +++++++++--------- .../image/TechnicalOverview_V1-19.svg | 2 +- 2 files changed, 73 insertions(+), 73 deletions(-) diff --git a/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio b/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio index 534804e1d..3ce2508d9 100644 --- a/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio +++ b/docu/Concepts/TechnicalRequirements/graphics/TechnicalOverview_V1-19.drawio @@ -1,277 +1,277 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + diff --git a/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg b/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg index 4b407aa5a..2f5264182 100644 --- a/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg +++ b/docu/Concepts/TechnicalRequirements/image/TechnicalOverview_V1-19.svg @@ -1 +1 @@ -
Community  "Gradido-Akademie"
Community  "Gradido-Akademie"
Gradido - technical Infrastructure-Overview
State of 02.2023
Gradido - technical Infrastructure-Overview...
Backend-Modul
GraphQL-API
Backend-Modul...
CommunityServer DB
CommunityServer DB
Layer 1:
Layer 1:
Layer 2:
Layer 2:
"GDT-Server"
base on C++ + mySQL
"GDT-Server"...
GDT-Server DB
GDT-Server DB
json-
ajax-
request
json-...
Layer 3:
Layer 3:
"Elopage"
external Service-Portal
"Elopage"...
"User-UI"
"User-UI"
graphql
graphql
json-
request
json-...
graphql
graphql
"Admin-UI"
"Admin-UI"
DHT-Modul
HyperSwarm
DHT-Modul...
Federation-Modul
GraphQL-API V2_0
Federation-Modul...
Federation-Modul
GraphQL-API V1_x
Federation-Modul...
Federation-Modul
GraphQL-API V1_1
Federation-Modul...
Federation-Modul
GraphQL-API V1_0
Federation-Modul...
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
Community "GallischesDorf-TBB"
Community "GallischesDorf-TBB"
Backend-Modul
GraphQL-API
Backend-Modul...
CommunityServer DB
CommunityServer DB
Layer 1:
Layer 1:
Layer 2:
Layer 2:
Layer 3:
Layer 3:
"User-UI"
"User-UI"
graphql
graphql
graphql
graphql
"Admin-UI"
"Admin-UI"
 DHT-Socket Communication 
 DHT-Socket Communication 
DHT-Modul
HyperSwarm
DHT-Modul...
Federation-Modul
GraphQL-API V1_1
Federation-Modul...
Federation-Modul
GraphQL-API V1_0
Federation-Modul...
graphQL-Handshake
graphQL-Handshake
GraphQL-Client V1_1
GraphQL-Client V1_1
graphQL-Handshake
graphQL-Handshake
GraphQL-Client V1_0
GraphQL-Client V1_0
graphQL-Handshake
graphQL-Handshake
graphQL-Handshake
graphQL-HandshakeViewer does not support full SVG 1.1 \ No newline at end of file +
Community  "Gradido-Akademie"
Community  "Gradido-Akademie"
Gradido - technical Infrastructure-Overview
State of 02.2023
Gradido - technical Infrastructure-Overview...
Backend-Modul
GraphQL-API
Backend-Modul...
CommunityServer DB
CommunityServer DB
Layer 1:
Layer 1:
Layer 2:
Layer 2:
"GDT-Server"
base on cakephp + mySQL
"GDT-Server"...
GDT-Server DB
GDT-Server DB
json-
ajax-
request
json-...
Layer 3:
Layer 3:
"Elopage"
external Service-Portal
"Elopage"...
"User-UI"
"User-UI"
graphql
graphql
json-
request
json-...
graphql
graphql
"Admin-UI"
"Admin-UI"
DHT-Modul
HyperSwarm
DHT-Modul...
Federation-Modul
GraphQL-API V2_0
Federation-Modul...
Federation-Modul
GraphQL-API V1_x
Federation-Modul...
Federation-Modul
GraphQL-API V1_1
Federation-Modul...
Federation-Modul
GraphQL-API V1_0
Federation-Modul...
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
GraphQL-Client V1_0
Community "GallischesDorf-TBB"
Community "GallischesDorf-TBB"
Backend-Modul
GraphQL-API
Backend-Modul...
CommunityServer DB
CommunityServer DB
Layer 1:
Layer 1:
Layer 2:
Layer 2:
Layer 3:
Layer 3:
"User-UI"
"User-UI"
graphql
graphql
graphql
graphql
"Admin-UI"
"Admin-UI"
 DHT-Socket Communication 
 DHT-Socket Communication 
DHT-Modul
HyperSwarm
DHT-Modul...
Federation-Modul
GraphQL-API V1_1
Federation-Modul...
Federation-Modul
GraphQL-API V1_0
Federation-Modul...
graphQL-Handshake
graphQL-Handshake
GraphQL-Client V1_1
GraphQL-Client V1_1
graphQL-Handshake
graphQL-Handshake
GraphQL-Client V1_0
GraphQL-Client V1_0
graphQL-Handshake
graphQL-Handshake
graphQL-Handshake
graphQL-HandshakeText is not SVG - cannot display \ No newline at end of file From d3a1b8afe5844cf179fad61f6da8212fcb7e8249 Mon Sep 17 00:00:00 2001 From: clauspeterhuebner <86960882+clauspeterhuebner@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:32:22 +0100 Subject: [PATCH 3/8] Update docu/Concepts/TechnicalRequirements/Federation.md Co-authored-by: Ulf Gebhardt --- docu/Concepts/TechnicalRequirements/Federation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index 7210756ff..5e674e7d1 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -26,7 +26,7 @@ At first the following diagramm gives an overview of the three stages and shows ### Technical Architecture -The previous described handshake will be done by several technical moduls of the gradido system. The following picture gives an overview about the moduls and how the communicate with each other. +The previous described handshake will be done by several technical modules of the gradido system. The following picture gives an overview about the modules and how the communicate with each other. ![img](./image/TechnicalOverview_V1-19.svg) From 73ce45034401c6a409215d3b9f54c9dcf00823e1 Mon Sep 17 00:00:00 2001 From: clauspeterhuebner <86960882+clauspeterhuebner@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:35:45 +0100 Subject: [PATCH 4/8] Update docu/Concepts/TechnicalRequirements/Federation.md Co-authored-by: Ulf Gebhardt --- docu/Concepts/TechnicalRequirements/Federation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index 5e674e7d1..afa7116d3 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -34,7 +34,7 @@ As soon as a Gradido Community is up and running the DHT-Modul first write the h The up and running Backend-Modul contains a validation logic to verify the community entries from the own DHT-Modul. For each announced but unverified community-entry the GraphQL-Client is used to invoke a getPublicKey-Request. Depending on the containing api-version the matching GraphQL-Client is used and the getPublicKey-Request will be send to the given URL. -As soon as the FederationModul of the assoziated community received the getPublicKey-request the own publicKey is read from database and send back in the response. +As soon as the FederationModul of the associated community received the getPublicKey-request the own publicKey is read from database and send back in the response. The GraphQL-Client will read from the returned response data the publicKey of the other community and compare it with the data of the community-entry, which cause the getPublicKey-Request. If they match the community-entry will be updated be inserting the current timestamp in the verifiedAt-field of this community-entry. From b617149138ec1c161ecf70f31a3fe34e12a196c3 Mon Sep 17 00:00:00 2001 From: clauspeterhuebner <86960882+clauspeterhuebner@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:36:02 +0100 Subject: [PATCH 5/8] Update docu/Concepts/TechnicalRequirements/Federation.md Co-authored-by: Ulf Gebhardt --- docu/Concepts/TechnicalRequirements/Federation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index afa7116d3..a5ecc984d 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -36,7 +36,7 @@ The up and running Backend-Modul contains a validation logic to verify the commu As soon as the FederationModul of the associated community received the getPublicKey-request the own publicKey is read from database and send back in the response. -The GraphQL-Client will read from the returned response data the publicKey of the other community and compare it with the data of the community-entry, which cause the getPublicKey-Request. If they match the community-entry will be updated be inserting the current timestamp in the verifiedAt-field of this community-entry. +The GraphQL-Client will read the publicKey of the other community from the returned response data and compare it with the data of the community-entry, which caused the getPublicKey-Request. If they match the community-entry will be updated be inserting the current timestamp in the verifiedAt-field of this community-entry. This federation and verification logic will work the whole time and can be monitored by observing the communities-table changes. The Admin-UI will contain a Page to have a look on the current state of the communities table content. From c89a1916aea0ad0f78283df749f05262166d2a8a Mon Sep 17 00:00:00 2001 From: clauspeterhuebner <86960882+clauspeterhuebner@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:37:04 +0100 Subject: [PATCH 6/8] Update docu/Concepts/TechnicalRequirements/Federation.md Co-authored-by: Hannes Heine --- docu/Concepts/TechnicalRequirements/Federation.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index a5ecc984d..6ba5589e3 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -277,8 +277,6 @@ As soon the *openConnection* request is invoked: 3. check if the decrypted `parameter.signedAndEncryptedURL` is equals the selected url from the previous selected CommunityFederationEntry 1. if not then break the further processing of this request by only writing an error-log event. There will be no answer to the invoker community, because this community will only go on with a `openConnectionRedirect`-request from this community. 2. if yes then verify the signature of `parameter.signedAndEncryptedURL` with the `cf.pubKey` read in step 2 before - 3. -4. ### Stage3 - Autorized Business Communication From 66d077c256897501d89f15998d8610c89bb4e159 Mon Sep 17 00:00:00 2001 From: clauspeterhuebner <86960882+clauspeterhuebner@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:37:14 +0100 Subject: [PATCH 7/8] Update docu/Concepts/TechnicalRequirements/Federation.md Co-authored-by: Hannes Heine --- docu/Concepts/TechnicalRequirements/Federation.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index 6ba5589e3..f9a94d7a1 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -228,7 +228,6 @@ For the first federation release the *DHT-Node* will be part of the *apollo serv | communityApiVersion.apiversion | keep existing value | | communityApiVersion.validFrom | exchangedData.API.validFrom | | communityApiVersion.verifiedAt | keep existing value | - * 3. After all received data is stored successfully, the *DHT-Node* starts the *stage2 - Authentication* of the federation handshake ### Stage2 - Authentication From e2081994f89a5da89d3c53254fbba298497b926c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Claus-Peter=20H=C3=BCbner?= Date: Thu, 23 Mar 2023 00:01:47 +0100 Subject: [PATCH 8/8] rework pr comments --- docu/Concepts/TechnicalRequirements/Federation.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index f9a94d7a1..8bbd74a3e 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -30,13 +30,15 @@ The previous described handshake will be done by several technical modules of th ![img](./image/TechnicalOverview_V1-19.svg) -As soon as a Gradido Community is up and running the DHT-Modul first write the home-community-entries in the database and starts with the federation per HyperSwarm. Each community, which is configured to listen on the GRADIDO_HUB of the DHT will be part of the Gradido-Net-Federation. That means each DHT-Modul of each community will receive the publicKey of all connected communities. The DHT-Modul will open for each received publicKey a communication-socket with the associated community DHT-Modul, to exchange api-version info and hosted urls for later direct communication between both communities. The exchanged api-version info and urls will be written in the own database. +As soon as a Gradido Community is up and running the DHT-Modul first writes the home-community-entries in the database and starts with the federation via HyperSwarm. Each community, which is configured with the configuration key GRADIDO_HUB to listen on the correct topic of the DHT will be part of the Gradido-Net-Federation. That means each DHT-Modul of each community will receive the publicKey of all connected communities. The DHT-Modul will open for each received publicKey a communication-socket with the associated community DHT-Modul. Over this open socket the connected communities exchange the data "api-version" and "url" for later direct communication between both communities. The exchanged api-version info and urls will be written in the own database. -The up and running Backend-Modul contains a validation logic to verify the community entries from the own DHT-Modul. For each announced but unverified community-entry the GraphQL-Client is used to invoke a getPublicKey-Request. Depending on the containing api-version the matching GraphQL-Client is used and the getPublicKey-Request will be send to the given URL. +The background of this exchanged data base on the supported api-versions a community will support with its own federation-modules. Each running federation-module in a community will support exact one graphql api-version of a cross-community-communication. To reach a dedicated federation-module with the correct api-version during a cross-community-communication the url for this federation-module must be known by both communities. As shown in the picture above the graphql-client with api-version V1_0 in the left community will interact with the federation-module with api-version V1_0 on the right community. During the lifecycle of the gradido-application it will be necessary to extent the features and interfaces for the cross-community-communication. To keep a backwards compatibilty and not to force each community to always upgrade their running software version on the last api-version at the same time, it will be necessary to support several api-versions in parallel. The different running api-version modules are responsible to convert and treat the exchanged data in a correct way to ensure konsistent data in the local database of the community. -As soon as the FederationModul of the associated community received the getPublicKey-request the own publicKey is read from database and send back in the response. +The up and running Backend-Module contains a validation logic to verify the community entries from the own DHT-Module. For each announced but unverified community-entry the GraphQL-Client is used to invoke a getPublicKey-Request. Depending on the containing api-version the matching GraphQL-Client is used and the getPublicKey-Request will be send to the given URL. -The GraphQL-Client will read the publicKey of the other community from the returned response data and compare it with the data of the community-entry, which caused the getPublicKey-Request. If they match the community-entry will be updated be inserting the current timestamp in the verifiedAt-field of this community-entry. +As soon as the federation-module of the associated community received the getPublicKey-request the own publicKey is read from database and send back in the response. + +The GraphQL-Client will read the publicKey of the other community from the returned response data and compare it with the data of the community-entry, which caused the getPublicKey-Request. If they match the community-entry will be updated by inserting the current timestamp in the verifiedAt-field of this community-entry. This federation and verification logic will work the whole time and can be monitored by observing the communities-table changes. The Admin-UI will contain a Page to have a look on the current state of the communities table content.