|
1 | 1 | ## Developers
|
2 | 2 |
|
3 |
| -This is a monorepo that includes the frontend and backend code for Acorn. |
| 3 | +This is a monorepo that includes the frontend and backend code for Acorn. All zomes and rust crates are contained in this repo. The main zome code is in `./happs/happ` where a widely used rust crate `hdk_crud` has been moved to `./happs/lib` for easier maintenance. |
| 4 | + |
4 | 5 | Note, there are two build targets and thus two development modes:
|
5 | 6 |
|
6 | 7 | - Acorn Desktop (app packaging is currently managed by a separate repo [acorn-desktop](https://github.com/lightningrodlabs/acorn-desktop))
|
@@ -34,77 +35,26 @@ If you want 2 agents, open a 3rd terminal window and run `yarn run moss:happ2`
|
34 | 35 |
|
35 | 36 | If you want to test the full webhapp, run `yarn run moss:build-webhapp` then run `yarn run moss:webhapp`. If you want a second agent, run `yarn run moss:webhapp2`.
|
36 | 37 |
|
37 |
| -### Building / Packaging - TO BE UPDATED |
38 |
| - |
39 |
| -To build: |
40 |
| - |
41 |
| -- `yarn run build` |
42 |
| - |
43 |
| -The packaged executables can be found in `frontend/electron/out`. |
44 |
| - |
45 |
| -In order to get cross-platform builds, just tag your repository like `v1.0.0-alpha` and push the tag to Github. CI will automatically start running a build, under the "Release" action. |
46 |
| - |
47 |
| -> Macos: You will need to have set the following environment variables as repository secrets: |
48 |
| -> |
49 |
| -> - APPLE_CERTIFICATE_BASE64 |
50 |
| -> - APPLE_CERTIFICATE_PASS |
51 |
| -> - APPLE_DEV_IDENTITY |
52 |
| -> - APPLE_ID_EMAIL |
53 |
| -> - APPLE_ID_PASSWORD |
54 |
| -> - APPLE_TEAM_ID |
55 |
| -> |
56 |
| -> 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 |
57 |
| -
|
58 |
| -### Versioning |
59 |
| - |
60 |
| -Each version of the app will either change, or not change, the paths to the user data folders in use by the application. |
61 |
| - |
62 |
| -The user data will be located under `acorn` in the platform specific appData folder, as specified by `appData` here: https://www.electronjs.org/docs/latest/api/app#appgetpathname |
63 |
| - |
64 |
| -It is then in a specific sub-folder that relates to one of two types of data: |
65 |
| - |
66 |
| -- source chain and DHT -> `databases-${INTEGRITY_VERSION_NUMBER}` |
67 |
| -- private keys -> `keystore-${KEYSTORE_VERSION_NUMBER}` |
| 38 | +### Building / Packaging Desktop App |
68 | 39 |
|
69 |
| -INTEGRITY_VERSION_NUMBER and KEYSTORE_VERSION_NUMBER are defined in `electron/src/holochain.ts` and can be modified as needed in order to jump to new versions of holochain, or a new app DNA. |
| 40 | +First, build the webhapp if you haven't done so yet: |
70 | 41 |
|
71 |
| -You can tweak INTEGRITY_VERSION_NUMBER and KEYSTORE_VERSION_NUMBER independently. |
| 42 | +- `yarn run desktop:build-webhapp` |
72 | 43 |
|
73 |
| -INTEGRITY_VERSION_NUMBER should be incremented when a new DNA is in use, or when a new version of holochain which is not backwards compatible with prior versions is bumped to. In the case of new happ files being used, this occurs when the version number of the happ release in [./scripts/download-happs.sh](./scripts/download-happs.sh) changes. It will cause users to have to go through the migration process. |
| 44 | +This will create an `[acorn-desktop.webhapp](./happs/happ/workdir/acorn-desktop.webhapp)` file. Upload this to the [Acorn release page](https://github.com/lightningrodlabs/acorn/releases) with the appropriate version tag. |
74 | 45 |
|
75 |
| -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. |
| 46 | +Then, clone the `[acorn-desktop](https://github.com/lightningrodlabs/acorn-desktop/tree/v11.1.2)` repo. Take the `acorn-desktop.webhapp` file and copy it into the `/pouch` directory. Follow the rest of the instruction in the README. This should trigger a github action which automatically builds and releases multi-platform versions of Acorn, signed and ready to download on the [release page](https://github.com/lightningrodlabs/acorn-desktop/releases) |
76 | 47 |
|
77 |
| -## Happ Code |
| 48 | +### Building / Packaging Moss Tool |
78 | 49 |
|
79 |
| -The happ code has been separated into its own repository with its own release process. This has been done even though developing new features can sometimes involve the modification of that code, as well as the frontend and desktop wrapper code. |
| 50 | +Build the webhapp, |
80 | 51 |
|
81 |
| -The repo is here: https://github.com/lightningrodlabs/acorn-happ. |
| 52 | +- `yarn run moss:build-webhapp` |
82 | 53 |
|
83 |
| -After making changes, and performing a release, just edit [./scripts/download-happs.sh](./scripts/download-happs.sh) to point to the new release, and then run `yarn run download-happs` to download the new release. |
| 54 | +This will create an `[acorn-moss.webhapp](./weave-tool/acorn-moss.webhapp)` file. Upload this to the [Acorn release page](https://github.com/lightningrodlabs/acorn/releases) with the appropriate version tag. |
84 | 55 |
|
85 |
| -As mentioned above, INTEGRITY_VERSION_NUMBER should be incremented when the happ release has been updated. |
| 56 | +Publish this to the weave tool curation list, following the instruction [here](https://github.com/lightningrodlabs/weave-tool-curation/blob/main/0.13/README.md). You can view an example PR of this [here](https://github.com/lightningrodlabs/weave-tool-curation/pull/40). |
86 | 57 |
|
87 |
| -## Dependencies |
88 |
| - |
89 |
| -This project uses [holochain-runner](https://github.com/lightningrodlabs/holochain-runner) and [electron](https://www.electronjs.org/docs/latest/api/app) |
90 |
| - |
91 |
| -## Technical Overview |
92 |
| - |
93 |
| -Acorn functions at a high level according to these patterns: |
| 58 | +### Versioning |
94 | 59 |
|
95 |
| -- an 'electron' wrapper is responsible for |
96 |
| - - creating a 'BrowserWindow' application window through which users interact with the HTML/JS/CSS GUI of Acorn |
97 |
| - - 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. |
98 |
| -- 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. It relies on a general library that was developed with Acorn in mind, the [holochain-runner](https://github.com/lightningrodlabs/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". |
99 |
| - - 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 `holochain-runner`, and forwarding those events to the GUI via electron's IPC messages. |
100 |
| -- Within the application, here is how Acorn utilizes Holochain: |
101 |
| - - 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` would be replaced by "integrity version" numbers such as `1`, and `-Y` would be replaced by "keystore version" numbers such as `1`, both are the numbers associated in the [Versioning](#versioning) section of this doc): |
102 |
| - - Linux: `~/.config/Acorn/databases-X` and `~/.config/Acorn/keystore-Y` |
103 |
| - - MacOS: `~/Library/Application Support/Acorn/databases-X` and `~/Library/Application Support/Acorn/keystore-Y` |
104 |
| - - Windows: coming soon... |
105 |
| - - In Holochain, there is a pattern of a Conductor running 'apps', where an app is a collection of Cells (which are DNA + Agent), all configured to be running under the same Agent private keys |
106 |
| - - Instead of installing many DNAs within an "app", Acorn installs many/multiple "apps" each with one Cell. |
107 |
| - - On initial launch, the first "app" containing a Cell is automatically installed and activated, as all users need it to operate the app and onboard themselves. It is the "profile" app. It is responsible for sharing data globally between all Acorn users to do with users profile metadata. |
108 |
| - - In order to create a "Project" within Acorn, a whole new "app" containing one Cell is installed and activated. _By taking the unique 5 word secret phrase generated in the UI and injecting it into the DNA as a "uid" key/value, we create a unique secure network and DHT for that Project, which is guessable/joinable only by those who know that same secret phrase, which can be shared with them via chat channels outside of Acorn._ |
109 |
| - - When the UI calls into the Conductor to list out which "apps" are installed, it receives back a list like this: `["main-app", "acorn-project-206088-uid-pickle-glandular-cache-jugular-battered", "acorn-project-664715-uid-twinky-mockup-foothold-skiing-handed", "acorn-project-918455-uid-puffball-alkalize-freckles-drier-flame"]` which distinguishes between apps which are project apps, any with the prefix "acorn-project" and the 1 app which is not, which is called "main-app". It uses this distinction to make all the necessary Zome calls into that 1 Cell within each project app to find the Project metadata (`ProjectMeta` in the code) and list it out in the UI on the Dashboard. |
110 |
| -- All user data is either stored in the previously mentioned platform specific "application data" folder, and also in the chromekit/electron "localstorage" memory. Only very simple things such as preferences for Trackpad or Mouse are currently stored in "localstorage", the rest is in the application support folder, namespaced by the version number you are currently running. |
| 60 | +When you are bumping a version, do a global search for the version number and replace it with the new one. You can see an example commit of this [here](https://github.com/lightningrodlabs/acorn/pull/374/commits/fffe15395ee489d25a0aab7fbc48d674bee97991). |
0 commit comments