Describe the problem that needs this feature
I want to host my DID metadata document service on a solar powered Raspberry Pi that is only online when the sun is shining. This means the service URL for my DID might not be available when it's cloudy, so I would like to include primary and secondary service URLs in the DID. The secondary service URL would act as a backup when the primary isn't available.
Multiple services of the same type are fully supported by the DID spec as long as the id values are unique.
I believe multiple services of the same type are supported by the FAIR spec, although there is some ambiguity. The FAIR spec places no requirement on the id value.
Interestingly (although not technically relevant), the ATProto spec enforces a known id and disallows multiple AtprotoPersonalDataServer services:
The PDS service network location for the account is found under the service array, with id ending #atproto_pds, and type matching AtprotoPersonalDataServer. The first matching entry in the array should be used, and any others ignored.
I don't believe there is a technical or operational reason why FAIR should disallow multiple FairPackageManagementRepo service definitions.
Describe the solution you'd like
I would like the FAIR plugin for WordPress to support failover from a primary service to a secondary service based on the services included in the DID document. Currently it just uses the first, and if there is a network connectivity issue or it receives an invalid response, there is no failover.
This could improve the resilience of the FAIR ecosystem and facilitate hosting metadata documents on commodity hosting with fallback mechanisms. I could even imagine a future where FAIR metadata hosting SaaS providers come online and without failover support we end up heading back toward centralisation.
Describe the problem that needs this feature
I want to host my DID metadata document service on a solar powered Raspberry Pi that is only online when the sun is shining. This means the service URL for my DID might not be available when it's cloudy, so I would like to include primary and secondary service URLs in the DID. The secondary service URL would act as a backup when the primary isn't available.
Multiple services of the same type are fully supported by the DID spec as long as the
idvalues are unique.I believe multiple services of the same type are supported by the FAIR spec, although there is some ambiguity. The FAIR spec places no requirement on the
idvalue.Interestingly (although not technically relevant), the ATProto spec enforces a known
idand disallows multipleAtprotoPersonalDataServerservices:I don't believe there is a technical or operational reason why FAIR should disallow multiple
FairPackageManagementReposervice definitions.Describe the solution you'd like
I would like the FAIR plugin for WordPress to support failover from a primary service to a secondary service based on the services included in the DID document. Currently it just uses the first, and if there is a network connectivity issue or it receives an invalid response, there is no failover.
This could improve the resilience of the FAIR ecosystem and facilitate hosting metadata documents on commodity hosting with fallback mechanisms. I could even imagine a future where FAIR metadata hosting SaaS providers come online and without failover support we end up heading back toward centralisation.