search

KeychainMDIP / kc

Reference implementation of the Multi Dimensional Identity Protocol (MDIP)
MIT License
8 stars 2 forks source link

Revisit hyperswarm garbage collection requirements #233

Closed macterra closed 1 month ago

macterra commented 1 month ago

Garbage collection was originally designed to deal with the problem of ephemeral DIDs (namely challenge and response DIDs) bloating the DID db. Currently all asset DIDs that are registered on hyperswarm on deleted after 24 hours. This strategy will consequently end up deleting other assets like groups and schemas and credentials that happen to be registered on hyperswarm. Let's revisit the requirements.

macterra commented 1 month ago

Related to #166

macterra commented 1 month ago

I think @Flaxscrip suggested originally that ephemeral DIDs should have an expiry date or time-to-live specified in the DID data at creation time. The garbage collector should use that instead of DID type and creation time.

Found it in #159

macterra commented 1 month ago

This may tie into adding type metadata to didDocumentData #224. For example, a challenge DID could implement two types, "challenge" and "ephemeral" while a response DID would implement "response" and "ephemeral". Both kinds of DID would include a section in their didDocumentData that looks like:

{
    'ephemeral': {
        'expiresAt': "2024-07-16T20:19:16.002Z",
    }
}

The garbage collector can look for ephemeral DIDs and do the right thing, independent of the specific DID types.