The Future of Session

Earlier this year, the Session Technology Foundation (STF) had to pause Session development due to financial constraints. After a donation campaign in which many users, friends, and peers gave to the Foundation, the STF now has enough resources to continue Session development in some capacity.

This post aims to provide some context about the Foundation’s standing before and after the campaign, highlight the figures who will lead Session from now on, and outline their development strategy.

However, first we want to express our immense gratitude to all the people who gave. If it wasn’t for your help, the STF would be winding down support for Session — meaning there would be no more updates, apps would be de-listed from stores, and certain network infrastructure would go offline. Although the decentralized network can continue without the STF, the future of the ecosystem was quite uncertain. There is now a way forward because of the community’s generosity, and Session can continue to provide private, safe, and secure messaging for its millions of users.

Foundation resourcing

In the past, the Session Technology Foundation supported a relatively large development team, as well as staff for some operations, communications, and policy functions. Although the spend for these contributors was modest compared to the typical size and cost of teams creating messaging apps, people were still the most expensive part of supporting Session.

This team was maintained as long as possible in order to try and keep pace with other apps in the messaging class, assure the strongest possible security and privacy, and to attempt to develop value-generating features pursuant to the sustainability of the Foundation, node operation, and the overall ecosystem.

Our strategy was to work towards the release of the Session Pro Beta, believing this would begin providing the Foundation and ecosystem with the stimulus required to continue. Of course, privacy preservation, feature value and reliability, and decentralization were considerations, and the development work was significant. By the time this work was complete–or close to complete–the Foundation was forced to assess whether a Pro Beta release was responsible given its current position. In simple terms, as it stood the Foundation did not have the resources to continue developing Pro features or provide ongoing support to purchasers. Launching Session Pro Beta at that time would have been a huge gamble, and launching did not meet the Foundation’s integrity standards due to this risk to users.

With low revenue and a dwindling treasury, the Foundation made the decision to reduce its costs as close to zero as possible, which sadly meant losing all employees — the people whose work lives were dedicated to Session. Some continued as volunteers, and during this time there were three main activities: tracking community contributions and planning for how to use these funds, holding conversations with several parties interested in commercial deals relating to Session, and seeking grants and public funding which may support Session’s development.

Since launching the campaign, the Foundation has received a steady stream of donations from the community. These have mostly been small donations from everyday people who want to see Session live on. Some volunteer contributors started making plans for how these funds could be used (these plans can be read below).

At the same time, several individuals reached out to the Foundation to inquire about commercial deals. These ranged from proposals for white-labelled enterprise versions of Session, acquisition of the Session IP and transition of stewardship, folding Session into new or pre-existing projects, and general expressions of interest. As you can probably imagine, some of these approaches were extremely suspicious or simply technically and philosophically infeasible, while a smaller amount were good faith ideas from supportive and generous people. Unfortunately, none of these opportunities were compatible with the Session project for various reasons. That being said, contributors remain very open to the possibility of enterprise versions of Session in the future, however, it is paramount that this does not bring detriment or compromise to the free and public version of Session.

And finally, there is also ongoing effort to work with grants and public funding which supports free and open source technology like Session. These processes generally take some time, so there are not yet results from these efforts (and none can be counted on for the time being, though we are quite hopeful that at least some will come through).

For now, the Foundation is running on community contributions alone. The incredible amount of support we have received is greatly appreciated, and it will support the small team working on Session going forward. 

Session’s second wave

In the short term, Session is supported by a team of 2-3 developers.

One of these developers, Jason Rhinelander, is a long-time contributor, serving as Session’s Chief Software Architect and as a member of the STF’s board of trustees. Jason originally joined the project as a community member, participating in public discussion and debate about the proper stewardship of the ecosystem. His passion led him to join full-time, and he has been dedicated to Session since before the name ‘Session’ even existed (and, for that matter, before the previous project name existed, too). 

Jason is uniquely placed to lead the project, with an abundance of technical knowledge and expertise, full understanding of Session’s architectural and back-end layers, Foundation experience, and most importantly — love and care for the project.

He will be joined by at least one (and possibly two, pending ongoing discussions) other senior developers who have worked on Session for several years. 

Although capacity will obviously be reduced compared to a team of 12+ full-time developers, there is some acknowledgement that the software development space is evolving due to AI assistants. There have been significant advancements in just the last 6 months, and there may be further improvements to AI in the future. The Session project had started to incorporate significant AI coding contributions in the weeks before the project was forced to let people go, with significant success. Of course, it is important to stress that these tools are used as force multipliers to the existing skill and expertise of Session developers, and AI will not make wholesale or unreviewed contributions to the Session codebase. As always, privacy, security, and decentralization remain Session’s design priorities.

Development strategy

Due to the reduced development resources available to the STF, it must select highly strategic development focuses. 

Currently, there are two main goals: first, to reduce the development cost of maintaining Session; second, to generate some revenue for the Foundation to ensure its sustainability. 

The current Session application design requires Session contributors to maintain three discrete codebases for each version of the application (iOS, Android, Desktop). This creates significant overhead when implementing new features or upgrades, because they actually need to be built three times to ensure parity across platforms, while introducing significant areas for bugs to manifest in the differences between the separate applications’ logic.

If all of Session’s core functionality was instead handled by one library, it would greatly reduce the overhead of cross-platform development. For quite a while, Session contributors have been working on a unified library for core Session logic and functionality, called libsession. While some common functionality is already handled by libsession, work is commencing immediately to build out as much functionality as possible using libsession, and then making the individual applications “dumb” by handing over the majority of the application control to a shared common single codebase.

Not only will this make it much easier for full-time contributors to continue to maintain and improve Session, it will also make it much easier for community members at large to make meaningful code contributions that can be more easily accepted into the application(s).

Completing work on libsession will make it much more viable for a small cohort of developers to maintain the ecosystem going forward, and ensure that things like Session Protocol v2 (bringing Perfect Forward Secrecy (PFS) and post-quantum encryption (PQ)) are able to be launched in the applications despite the reduced development capacity. 

In parallel, work will also continue on the final tasks needed to launch Session Pro Beta, including some final testing and tweaks, pushing out the releases, user support flows, and bug report handling and fixing. At first, this will likely launch without being rebuilt using libsession, but instead relying on the cross-platform work which has been completed by past contributors.

While this work is being completed, there will be a Mandatory Session Node Upgrade (MSNU) to bring in already-completed oxen chain and storage server fixes, and add mandatory Session Router support to the network. 

With the full-fledged implementation of libsession in mind, developers will then look to select new GUI platforms which are able to wire up to libsession while offering lower development overheads than current solutions. This might be simpler native applications, or something like Qt or Flutter. 

By early next year, this will lead to ‘new’ streamlined Session clients with full libsession implementations and much greater potential for new development. This will mean that additions like Session Protocol v2 and more powerful Pro features will be faster and easier to implement.

Although this was not the original plan for Session, the Foundation is grateful to have this opportunity to continue stewarding the ecosystem. Development contributors will be surrounded by a small group of volunteers to continue supporting necessary administrative functions.

Thank you again to everyone who made this possible through their gifts: whether they be financial donations, running nodes, or messages of support.

As always — send messages, not metadata.