Following are the list of features that needs to be implemented in iFolder server/client/plugins as needed. This is a open list, people having a feature or wish-list can add to this. Also people interested in implementing the feature can contact bmcconnell [at] novell.com for assistance or guidance to start with or just mail ifolder-dev@forge.novell.com for any queries.

• Server side trash can – The code is available, it has to be integrated with the 3.7 code. The implementation is very simple and the main idea behind this implementation is to not break the current abstractions
• Versioning Support – With very minimal effort Versioning can be supported in Simias. The simias architecture allows for versioning. But there is more work in the UI part on displaying these versions.
• Delta-sync for encryption – One area which has more IDRs by the team. This will be a very useful feature as most of the users will use encrypted iFolders and would like to see good performance in it.
• Pluggable Encryption – Currently encryption is tied to the Simias code. This has to be separated as a plugin, so that all additional features will be a plugin. Will also help in maintaining the core Simias in good condition for future programmers.
• P2P support – The current peer-to-peer support is via Bonjour or Gaim. This has to be made native with simias itself, instead of requiring an additional non-iFolder component to be installed.
• Integrated content search – The current search facility is very basic and it does only iFolder search in Thick client and File search in Web client. But there is no content search. It would be great if a minimal version of quick-finder be used inside iFolder or as an linked library to perform content search.
• Windows Explorer Integration – Windows shell integration is only to give a context sensitive Menu and icon display. But there is no category called iFolders in Explorer (like “My Bluetooth Places”). This integration will help finding iFolders easily and help leverage the Microsoft search capabilities.
• Rebranding – Currently there is no way to identify which logos to change and the size and characteristics of the logos, images, texts for rebranding it. We need to document the list of images to change and their respective characteristics to enable rebranding.
• User-groups independent of LDAP groups – iFolder groups must be implemented to cater to various customer needs. Currently only LDAP groups are supported. Independent of LDAP, the Web Admin must allow the administrator to create Domain level Server groups and Domain level User groups. This will give flexibility in Provisioning users/groups/ldap-groups to a group-of-servers rather than a single server. This will help is high-availability of the home server, rather than depending on a single home-server.
• Ifolder Store virtualization – The iFolder store must be virtual and not tied to a server. This will help in high-availability of data irrespective of which Master or Slave is alive.
• RSS support – iFolder must allow subscription to RSS feeds. There is some code to enable this, but not fully working. This will help iFolder keep-up with the technology evolution and hence get more users to use iFolder.
• Gnome File Viewer Integration (Nautilus) – The current nautilus support is for the context sensitive menu and icon. There is some code to integrate iFolder with the VFS/gnome, so that iFolder will be seen as a File category in the Nautilus File Explorer. This will help get the list of iFolders available via the gnome explorer rather than the client.
• Light-weight Simias – Simias is the heart of iFolder. We need a light-weight Simias that will be able to integrate iFolder in the existing clients rather than requiring a iFolder thick client itself. A light-weight simias running in the background and simple plugins to nautilus, VFS, GAIM, Bonjour, GWIM, GW etc will be more powerful than expecting users to use the iFolder client to access iFolder. When the user opens a gnome vfs browser, then a separate category of iFolder must be displayed. Similarly, for IM, the user must be able to save the IM into iFolder, so that the IM conversation is available in other locations.
• AJAX based Web-Access – Web Access does a major job of displaying iFolders files, upload/download/members etc. For every simple action, there is a POSTBACK. This has to be moved to AJAX, so that the page refresh is avoided and all actions take place in the background.
• Binary Synchronization – The current Sync algorithm is more useful for text data than Binary data. The sync algorithm must be modified to help better binary synchronization – possibly integrating the 'rdiff' changes into the RSYNC algorithm.
• Content tagging with Indexing – iFolder being a more collaboration product and user will tend to store more and more data, over a period of time, it becomes more difficult to manage and search the data. During iFolder upload/download the content must be tagged for easier search and also indexed better.
• Password-less login – iFolder does not support bio-metric based login or non-password based login. This support will provide a product that can be used by Government and military organizations.
• Local store encryption – iFolder local store is never encrypted, this poses a security threat if the laptop or desktop or the user hard-disk is stolen or miss-placed. This encryption is a challenge as this should not affect the existing applications from using the data. There are certain ideas to plugin iFolder to the FS layer to get the data encrypted via the iFolder key and provide the key to the file-system via certain authentication. For this iFolder must be running for other applications to use the iFolder stored data.
• FUSE support – This will help users use the FS interface to create iFolders (eg: using mkdir) rather than using a client. Also all iFolder CLI can be done via FUSE, than writing a separate CLI utility for iFolder.
• FAST engine – Fully Automated Sync Tracker (FAST) engine will automate the entire conflict management and versioning. This engine will track the updates and create versions and during such creation will also resolve conflicts with multiple data sources. User will have minimal intervention for resolving conflicts, as the user can get his version of data and if required get the merged data with other user changes or get the other user's version of data, worst case ask for a merged version of both the user versions.
• Meta-iFolder – Currently there is no option to manage multiple domains from a single console. A new Meta-administration console needs to be developed that will manage multiple domains.