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
Copy file name to clipboardExpand all lines: DEVELOPERS.md
+46-8Lines changed: 46 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -59,14 +59,52 @@ To build:
59
59
60
60
-`npm run build`
61
61
62
-
> Macos: You will need to have set
63
-
> APPLE_ID_EMAIL
64
-
> and
65
-
> APPLE_ID_PASSWORD
66
-
> as environment variables, in addition to having a certificate for the Apple Developer
67
-
> account installed on the system you are building on.
62
+
The packaged executables can be found in `frontend/electron/out`.
68
63
69
-
You will find the packaged executables in `electron/out`.
64
+
In order to get cross-platform builds, just tag your repository like `v0.0.1` and push the tag to Github. CI will automatically start running a build, under the "Release" action.
65
+
66
+
> Macos: You will need to have set the following environment variables as repository secrets:
67
+
> - APPLE_CERTIFICATE_BASE64
68
+
> - APPLE_CERTIFICATE_PASS
69
+
> - APPLE_DEV_IDENTITY
70
+
> - APPLE_ID_EMAIL
71
+
> - APPLE_ID_PASSWORD
72
+
>
73
+
> The first two should be set as equivalents of `MACOS_CERTIFICATE` = `APPLE_CERTIFICATE_BASE64` and `MACOS_CERTIFICATE_PWD` = `APPLE_CERTIFICATE_PASS` as found in the following article, which also provides other instruction regarding this: https://localazy.com/blog/how-to-automatically-sign-macos-apps-using-github-actions
74
+
75
+
76
+
### Versioning
77
+
78
+
Each version of the app will either change, or not change, the paths to the user data folders in use by the application.
79
+
80
+
The user data will be located under `mova` in the platform specific appData folder, as specified by `appData` here: https://www.electronjs.org/docs/latest/api/app#appgetpathname
81
+
82
+
It is then in a specific sub-folder that relates to one of two types of data:
83
+
- source chain and DHT -> `databases-${DATABASES_VERSION_NUMBER}`
DATABASES_VERSION_NUMBER and KEYSTORE_VERSION_NUMBER are defined in `frontend/electron/src/holochain.ts` and can be modified as needed in order to jump to new versions of holochain, or a new app DNA.
87
+
88
+
You can tweak DATABASES_VERSION_NUMBER and KEYSTORE_VERSION_NUMBER independently.
89
+
90
+
DATABASES_VERSION_NUMBER should be incremented when a new DNA is in use. It will cause users to have to re-create profiles and re-instate data they've previously added.
91
+
92
+
KEYSTORE_VERSION_NUMBER should be incremented if the version of lair-keystore changes, and has a new key format. Or if you otherwise want users to have to switch and generate new keys.
Lair Keystore Revision [v0.0.9 Nov 4, 2021](https://github.com/holochain/lair/releases/tag/v0.0.9)
104
+
105
+
https://docs.rs/hdk/0.0.115/hdk/index.html
106
+
107
+
and electron version 12 [https://www.electronjs.org/](https://www.electronjs.org/)
70
108
71
109
## Technical Overview
72
110
@@ -75,7 +113,7 @@ Acorn functions at a high level according to these patterns:
75
113
- an 'electron' wrapper is responsible for
76
114
- creating a 'BrowserWindow' application window through which users interact with the HTML/JS/CSS GUI of Acorn
77
115
- starting up and stopping background processes for Holochain related services, including the main holochain engine, and the holochain "keystore" which handles cryptographic signing functions. It is necessary for these background processes to be running while the application is open, and for them to stop when it is closed/quit, because the GUI must talk to these components in order for it to perform any of its primary functions such as reading and writing data.
78
-
- The `holochain` binary shipped by the holochain organization is **not** directly bundled, and executed. An alternative approach is taken for the needs of Acorn. This alternative approach involves the compilation of a custom binary to run the core Holochain engine, the "conductor", which is achieved by importing shared code from the `holochain` binary source code. This is found in the [conductor](./conductor) folder. It relies on a general library that was developed with Acorn in mind, the [embedded-holochain-runner](https://github.com/Sprillow/embedded-holochain-runner/). This strategy was taken to optimize performance and cut down on cross-language (js <-> rust) complexity. Due to this architecture, the electron js code does not need to call any functions of the `admin websocket` typically exposed by `holochain` to manage the Conductor state. This also improves code development simplicity, as it minimizes the surface area/complexity of the electron side code, and keeps it "thin".
116
+
- The `holochain` binary shipped by the holochain organization is **not** directly bundled, and executed. An alternative approach is taken for the needs of Acorn. This alternative approach involves the compilation of a custom binary to run the core Holochain engine, the "conductor", which is achieved by importing shared code from the `holochain` binary source code. This is found in the [conductor](./conductor) folder. It relies on a general library that was developed with Acorn in mind, the [holochain-runner](https://github.com/Sprillow/holochain-runner/). This strategy was taken to optimize performance and cut down on cross-language (js <-> rust) complexity. Due to this architecture, the electron js code does not need to call any functions of the `admin websocket` typically exposed by `holochain` to manage the Conductor state. This also improves code development simplicity, as it minimizes the surface area/complexity of the electron side code, and keeps it "thin".
79
117
- This custom binary also helps the GUI / electron application know about the status of the Conductor. It does this by subscribing to events emitted from the `embedded-holochain-runner`, and forwarding those events to the GUI via electron's IPC messages.
80
118
- Within the application, here is how Acorn utilizes Holochain:
81
119
- A new user will need a new private/public key pair to represent their unique identity within Acorn. This will be generated automatically on the first launch of Acorn. Acorn will look in the following folder on the users computer to determine whether this is the first launch or a re-launch (`-X-Y-Z` would be replaced by version numbers such as for `v0.5.1` it would be `-0-5-1`):
0 commit comments