Skip to content

Commit

Permalink
Update ROADMAP.md (#878)
Browse files Browse the repository at this point in the history
Signed-off-by: Parth Mandaliya <[email protected]>
  • Loading branch information
psfoley authored and ParthMandaliya committed Oct 5, 2023
1 parent a0fbd73 commit dd140cf
Showing 1 changed file with 11 additions and 13 deletions.
24 changes: 11 additions & 13 deletions ROADMAP.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,13 +36,13 @@ In the process of thinking about federated workflows, and the properties that ar
7. Don't reinvent unless absolutely necessary

### 1.2 Security, Privacy, and Governance
OpenFL is designed for security and privacy, and later this year we will be releasing some exciting extensions that build on running [OpenFL experiments within SGX enclaves](https://github.com/intel/openfl/blob/develop/openfl-gramine/MANUAL.md).
OpenFL is designed for security and privacy, and soon we will be releasing some exciting extensions that build on running [OpenFL experiments within SGX enclaves](https://github.com/intel/openfl/blob/develop/openfl-gramine/MANUAL.md).

### 1.4 Decoupling interface from infrastructure
### 1.3 Decoupling interface from infrastructure
The task runner interface is coupled with the the single experiment aggregator / collaborator infrastructure, and the interactive API is tied to the director / envoy infrastructure.
The interactive API was originally designed to be a high-level API for OpenFL, but for the cases when more control is required by users, access to lower level interfaces is necessary.

### 1.3 Consolidating interfaces
### 1.4 Consolidating interfaces
Today we support three interfaces: TaskRunner, native Python API, and interactive API. These are all distinct APIs, and are not particularly interoperable.
By the time we reach OpenFL 2.0, our intention is to deprecate the original native [Python API](https://openfl.readthedocs.io/en/latest/source/workflow/running_the_federation.notebook.html) used for simulations,
bring consistency to the remaining interfaces with a high level, middle level, and low level API that are **fully interoperable**. This will result in being able to use the interface you're most comfortable with for a simulation,
Expand All @@ -58,20 +58,18 @@ This causes community fragmentation and distracts from some of the bigger proble

## Upcoming OpenFL releases

### OpenFL 1.6 (Q2 2023)
### OpenFL 1.6 (Q4 2023)
1. Use the OpenFL Workflow Interface on distributed infrastructure with the [FederatedRuntime](https://openfl.readthedocs.io/en/latest/workflow_interface.html#runtimes-future-plans)
2. New use cases enabled by custom workflows
2. LLM Support
3. New use cases enabled by custom workflows
* Standard ML Models (i.e. Tree-based algorithms)
3. Federated evaluation documentation and examples
4. Well defined aggregator / collaborator interfaces intended for building higher level projects on top of OpenFL
5. Significantly improved documentation
6. New OpenFL Security Repo that extends OpenFL to provide governance, and end-to-end security for federated learning experiments
4. Federated evaluation documentation and examples
6. Significantly improved documentation

### OpenFL 2.0 (2023)
### OpenFL 2.0 (2024)
1. Interface Cohesion
* High level interface: Interactive API
* Mid level interface: Workflow API
* Low level interface: Redesigned TaskRunner API
* Low level interface: Workflow API
2. Decoupling interfaces from infrastructure
3. Updates to OpenFL Security
3. Well defined interfaces intended for building higher level projects on top of OpenFL

0 comments on commit dd140cf

Please sign in to comment.