[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3763: Potential issues with `PUT /v1/lease/:storage_index` in GBS protocol

[Tahoe-LAFS]

#3763: Potential issues with `PUT /v1/lease/:storage_index` in GBS protocol
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:  exarkun
         Type:  task      |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------

Comment (by exarkun):

 > Another question: Why does this endpoint exist at all?
 >
 > Creating an immutable storage index also creates a lease, per the docs:
 "A lease is also created for the shares." So maybe this endpoint doesn't
 need to exist at all?
 >

 There does need to be a "create a new lease" endpoint.  The strongest case
 is made by this scenario, I think:

 1. Alice uploads some immutable shares.  A lease is implicitly created and
 keeps the data alive.
 2. Alice shares the cap with Bob.
 3. Bob creates his own lease.
 4. Alice abandons the content and her lease expires.
 5. Bob's lease keeps the data alive.

 whether is pattern is actually supported by Tahoe as currently
 implemented, I'm not sure (I can't remember if leases with distinct renew
 secrets actually get tracked separately from each other ... but I think
 they might and if they don't, they should).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3763#comment:5>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage