BrightID-Node icon indicating copy to clipboard operation
BrightID-Node copied to clipboard

[DRAFT] Change channel expiration behaviour

Open TripleSpeeder opened this issue 2 years ago • 2 comments

Channel service needs to handle these scenarios:

(Live) Group/Star connection (shared directly via qrcode or chat)

This is a multi-use channel - During lifetime of the channel multiple people can join it and connect

  • short-living channel (minimum TTL 15 - 30 minutes)
  • dynamic TTL extension not required, but okay

(Async) 1:1 connection (shared directly via qrcode or async via email/messenger etc)

This is a single-use channel - As soon as 2 people have connected, the channel is not needed anymore.

  • long-living channel (minimum TTL hours or days)
  • dynamic TTL extension not required, but okay
  • channel can be closed before minimum TTL is reached when it has been used

(Async) Social recovery (shared directly via qrcode or async via email/messenger etc)

This is a multi-use channel - During lifetime of the channel multiple people can join it and upload recovery info

  • long-living channel (minimum TTL hours or days)
  • dynamic TTL, depending on amount of data to transfer
  • TTL should be extended with every upload

(Live) Add/sync device (shared directly via QRCode)

  • Short-living channel. Minimum TTL can be low, as only one person is interacting with the channel
  • dynamic TTL, depending on amount of data to transfer
  • TTL should be extended with every upload

serverside handling of channel TTL:

  • Client can provide a minimum TTL value when creating (uploading first file) a channel

    • Service should set default TTL of 15 minutes if client does not provide minimum TTL
  • Channel service should keep a channel open at least until minimum TTL is reached, even if it is not used at all

  • Channel service should extend channel TTL whenever a new file is uploaded:

    • if remaining TTL is less than 10 minutes, new TTL of "now + 10 minutes" is set
    • If remaining TTL is > 10 minutes nothing changes

Client information

Since channel TTL gets changed dynamically, client does not know if a channel is expired on the server. To fix this, the service needs to be changed:

  • It should respond with a 404 error when client requests listing of an unknown/expired channel (Current behaviour: Service returns HTTP 200 with empty array of channel entries)
  • It should set a custom HTTP header in the response containing the current TTL of the channel (both when listing and retrieving entries)

This way the client can locally close/leave expired channels and stay informed about the current TTL of a channel.

TripleSpeeder avatar Jul 13 '22 13:07 TripleSpeeder

Thanks @TripleSpeeder for creating a thorough spec that covers all the current important use cases. It seems correct to me. I would like to also hear @abramsymons thoughts.

adamstallard avatar Jul 13 '22 14:07 adamstallard

About TTL extension when a file is uploaded: Channel service should not need to have different behaviour depending on type of channel. So even if not required in all usecases it should always be okay to extend the channel lifetime with each upload.

TripleSpeeder avatar Jul 21 '22 07:07 TripleSpeeder