Roadmap

[helmut72]

In some answers you mentioned that you have other priorities. A roadmap would be cool. For example somthing like this:

https://github.com/photoprism/photoprism/projects/5

[drakkan]

Hi,

I don't have a defined roadmap, I don't use SFTPGo in production myself, so I don't need anything :)

Priorities change based on user feedbacks/bug reports and sponsor requests. Based on these requests, I decide what makes sense to do for the project. Clearly the requests of the sponsors take priority.

Maintaining an open source project like this takes a lot of time and effort and I also have a busy day job. The maintenance effort is often underestimated, take a look here to better understand what I mean.

Writing a roadmap will increase my load. The project you linked has 197 sponsors. It is still unclear if SFTPGo will be sustainable in the long term with sponsorships or if I should continue to donate my time.

There are very large companies that use SFTPGo and just ask for support without returning anything ... this is really disappointing.

I'm currently adding support for groups so, in short, you can define settings by group and they will apply to all users belonging to this group.

I think SFTPGo is already comparable to similar commercial products. There are features that you don't find even in commercial products, but we also need to fill some gaps, see for example #762 (this is a really big feature). My current goal is to fill these gaps.

[helmut72]

Thanks! While reading the commit messages with some interesting features and also read your comment here #796 (comment) ("for now I have other priorities") I just ask me what's the "other priorities", what v2.3 must be provide to be released. Then I thought you have some kind of "roadmap" written down somewhere else ;)

[drakkan]

Thanks! While reading the commit messages with some interesting features and also read your comment here #796 (comment) ("for now I have other priorities") I just ask me what's the "other priorities", what v2.3 must be provide to be released. Then I thought you have some kind of "roadmap" written down somewhere else ;)

I have some notes in a private TODO file but priorities can change so I don't want to share my TODO for now, for example MSSQL support has been there for a few years but I don't think it will happen until someone sponsors its development and maintenance.

For v2.3 we need at least

• groups support
• remove prefer_database_credentials and assume it is always true (a data migration is required)
• OIDC should also work in multi nodes setups
• Azure SDK has some backward incompatible changes in the latest update, I need to adapt and retest the code

the 2.2.x branch has several fixes, I also should find the time to tag a release and do the manual work required for a new release

[markpash]

@drakkan Hi

OIDC should also work in multi nodes setups

I don't wish to increase your workload, but I'm curious to know what exactly this means and if there's an issue that tracks it. I'd like to help test OIDC stuff and perhaps help develop it if needed. If there's an issue that describes what that means and what work it involves, I'd appreciate a link. Thanks.

[drakkan]

@drakkan Hi

OIDC should also work in multi nodes setups

I don't wish to increase your workload, but I'm curious to know what exactly this means and if there's an issue that tracks it. I'd like to help test OIDC stuff and perhaps help develop it if needed. If there's an issue that describes what that means and what work it involves, I'd appreciate a link. Thanks.

OIDC sessions are stored in memory, for single instances this is the best solution. If you have multiple SFTPGo instances, it will only work if a client is redirected to the same backend (including the authentication callback from the identity provider). I should add a data provider backend to allow for these deployments.

There is no open issue to track this development it is in my private TODO, feel free to open an issue if you wish

[markpash]

So the idea being, you need to store state somewhere that's not in memory so that requests as part of an auth flow could be sent to any instance and it doesn't need to be the instance where the flow was started? (something like https://github.com/eko/gocache would be useful?) If that's the case, then that's cool. Thanks for working on it. :)

[drakkan]

So the idea being, you need to store state somewhere that's not in memory so that requests as part of an auth flow could be sent to any instance and it doesn't need to be the instance where the flow was started? (something like https://github.com/eko/gocache would be useful?) If that's the case, then that's cool. Thanks for working on it. :)

We also need to store the state after the initial auth flow to be able to renew the oauth2 token. I think the first implementation will simply use the existing data providers. If you have multiple SFTPGo instances you also have a shared or distributed database.

Another thing to improve in the future is to maintain a shared state for active sessions, connections etc. Currently you can limit the maximum sessions per user, per ip and total, but these limits are local for each instance, in multi-node installations it would be useful to have global limits. I think that to share these states we need something like redis, memcache, groupcache or similar and for this development we also need the sponsorship of some company :). Unfortunately large companies that seem to be using SFTPGo just ask for support and new features but don't support the project in any way.