Least Authority May Update

[Lauri Hmel]

Hello All!

The following covers Least Authority’s work for the Tahoe-LAFS Software
Foundation during May 2025:


   -

   Create Tahoe-LAFS Mobile from PrivateStorage Mobile:
   -

      Major reorganisation of tahoe-chk repo: tahoe-chk!11
      <https://gitlab.com/tahoe-lafs/tahoe-chk/-/merge_requests/11>.
      Details can be found in the description of that MR.
      -

      Investigated new features: Supporting SDMF files in folders, LIT
      working anywhere CHK does,  prospects for write support, lone files in
      mobile app, SDMF validation, and found that more refactoring is required.
      -

      Study python code in preparation for said refactoring.
      -

      Write Haskell client tests against the Python server implementation.
      -

      Refactoring design well advanced, with some concepts committed to
      and/or proven in code, and others subject to further research:
      -

         Honour the spec’s statement that a capability has a location and
         an identification aspect, and that these aspects have largely
independent
         lives. In contrast to the current architecture in which SSK and CHK
         capabilities are different types and require type classes, in
future they
         will differ only in the constructor of the sum type of the
identification
         aspect, while the location aspect will be identical for SSK
and CHK. These
         new types are in place. Most called code will take either the
location or
         the identification aspect but rarely both.
         -

         Establish the servant definition of the GBS protocol (client and
         server sides) as the joint-most upstream thing in the
dependency graph,
         i.e., make storage agnostic of encodings. Derive the client
and any servers
         from this common definition.
         -

         Make encodings agnostic of storage.
         -

         Remove downloading functionality’s dependence on (plain or magic)
         folders.
         -

         End-to-end lazy streaming to restrict memory demand to roughly the
         segment size times k (proven in code for CHK.) Consider
adapting the fec
         library to work almost byte by byte.
         -

         Factor out commonalities between CHK and SSK, e.g.:
         -

            the location aspect of capabilities,
            -

            en/decryption with the read key,
            -

            fec
            -

         Subject to further feasibility study, consider SDMF being
         implemented as a subset of MDMF with infinite segment length.
         -

         Testing (client or server) against the python implementations,
         therefore some mocking code can be discontinued. Several
system tests in
         place.
         -

         Make sure the new architecture will be suitable for all
         verification methods, MDMF,  and write support.
         -

         Monitor performance at all stages of development to reveal current
         bottlenecks.
         -

         Single definition of all types.
         -

         Dead code removal and line count reduction of perhaps 50% or
         better.
         -

   Continued work on Replacement for the Current Issue Tracking System and
   Web landing page (#4161
   <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4161>)
   -

   Maintenance and Community Work:
   -

      Updated tahoe (1) man page (#1433
      <https://github.com/tahoe-lafs/tahoe-lafs/pull/1433>)
      -

      Updated integration test CI images (#1434
      <https://github.com/tahoe-lafs/tahoe-lafs/pull/1434>)
      -

      Installed recent Chutney for Tor integration tests (#1435
      <https://github.com/tahoe-lafs/tahoe-lafs/pull/1435>)
      -

      Tor integration test improvements (#1437
      <https://github.com/tahoe-lafs/tahoe-lafs/pull/1437>)
      -

      Additional/ongoing work towards fixing Tor integration tests (Trac
      tickets #3943 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3943>,
      #4167 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4167>)
      -

      Infrastructure as Code to manage DNS configurations (#4162
      <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4162>)
      -

      Provide basic monitoring of critical services #4175
      <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4175>
      -

         https://tahoe-lafs.github.io/infrastructure-upptime/
         -

      Manage shared secrets required to interact with the infrastructure (
      #4177 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4177>)
      -

      Investigating intermittent 502 responses from Trac (#4178
      <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4178>)


Additionally, a few hours of our time was spent on project administration
and coordination.


Please let us know if you have any questions or comments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tahoe-lafs.org/pipermail/tahoe-dev/attachments/20250605/7936365e/attachment-0001.htm>