W3C home > Mailing lists > Public > public-credentials@w3.org > January 2022

Re: Defining load balanced, failover clusters for DID Document serviceEndpoints?

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Date: Fri, 7 Jan 2022 16:43:37 +0000
To: "David I. Lehn" <dil@lehn.org>
CC: "public-credentials (public-credentials@w3.org)" <public-credentials@w3.org>
Message-ID: <MWHPR1301MB20947E3D1BB19A4910B8804FC34D9@MWHPR1301MB2094.namprd13.prod.outlook.com>
Dave, are you aware of any "normal scalable infrastructure best practices" that aren't based on some sort of centralized routing infrastructure (e.g. round-robin DNS as a simple example)?

Ultimately I'd like to find/build a pattern for creating "a fabric of fully decentralized compute nodes" that still works within/compliant with the current constraints of the DID-CORE spec.

Michael

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: David I. Lehn <dil@lehn.org>
Sent: Friday, January 7, 2022 8:22:00 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
Subject: Re: Defining load balanced, failover clusters for DID Document serviceEndpoints?

On Fri, Jan 7, 2022 at 5:24 AM Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
Has anyone else thought about this? ...for example, the value of serviceEndpoint can be a map or set of URIs (https://www.w3.org/TR/did-core/#services). This collection of URIs can serve as the list of serviceEndpoint/agent instances in a round-robin or load-balanced cluster. Second, the service type could be "clustered" to signal this is explicitly a load balanced, fallover-enabled serviceEndpoint/agent.

Thoughts?


Implementation details for a web endpoint are out of scope for the specs defined here.  Use normal scalable infrastructure best practices for your services.

-dave
Received on Friday, 7 January 2022 16:43:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:28 UTC