You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Caveat: The following may not be the right framework/structure to approach this. Open to expert advice.
And a foregone conclusion is that we cannot tackle all of the following, at least this year. What we have done is architected the SDK in a way to keep all these doors open.
Context
https://jan.ai/docs/ which explain the high level vision, and current approach, for Jan Framework
Jan Desktop is one implementation on top of this Framework.
Given our rapid growth, it accrues inevitable tech debt, and has leaky abstractions.
SDK Design Principles
Extensions Developers can build once & deploy everywhere
Devs don't have to learn our stack to build cool stuff
Devs don't have to understand the eccentricities of Electron/Capacitor/Whatever
Devs can choose to target a specific Runtime/Device/Platform and access native capabilities
Devs can just import core from @janframework as a single library to access all SDK capabilities
Current SDK Challenges
Cross Platform, Cross Runtime, and Cross Device
Node/Python backend processes need to be more elegantly exposed via the core SDK
Native desktop/mobile capabilities need to be more elegantly exposed via the core SDK
Local-first
We've nibbled at "local-first" with our current data persistence impl on users filesytem
Local first also encompasses collaboration, cross device syncing, crdts, etc
In time, the litmus test is whether users can build a non-ChatGPT, local first, ai native app with the SDK, e.g. a smart self hosted CRM, a privacy-preserving health app, a game engine, etc.
AI native
AI native software stack likely has to be some what opinionated about the types/primitives, to enable integrations/contribution across the stack
So far, we've used OpenAI API as the standard at the interface level
And did our best to define primitives at a deeper level (see core/types)
I have concerns around how this will withstand the test of time, and if it is overopinionated
Unclear core modules API
Events
Settings
FS/JanFolder
Common UI components
And more, are "core modules" that need to be more elegantly packaged and exposed in the SDK.
Core extensions vs nonessential extensions
Extensions are some what interdependent
UI API
Client UIs are modular and programmable
Devs can mount pages into the left ribbon, add menu items into the right toolbar, or do anything within the predefined frames
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Context
https://jan.ai/docs/ which explain the high level vision, and current approach, for Jan Framework
Jan Desktop is one implementation on top of this Framework.
Given our rapid growth, it accrues inevitable tech debt, and has leaky abstractions.
SDK Design Principles
import core from @janframework
as a single library to access all SDK capabilitiesCurrent SDK Challenges
Cross Platform, Cross Runtime, and Cross Device
Local-first
AI native
Unclear core modules API
Core extensions vs nonessential extensions
UI API
UI Library
Beta Was this translation helpful? Give feedback.
All reactions