diff --git a/.gitignore b/.gitignore index f2651158..6ae5b379 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,5 @@ __pycache__/ src/seedsigner.egg-info/ .nova +.vscode +src/seedsigner/models/settings_definition.json diff --git a/README.md b/README.md index edb3fb35..b4469cb4 100644 --- a/README.md +++ b/README.md @@ -81,14 +81,16 @@ The quickest and easiest way to install the software is to download the most rec After downloading the .zip file, extract the seedsigner .img file, and write it to a MicroSD card (at least 4GB in size or larger). Then install the MicroSD in the assembled hardware and off you go. If your goal is a more trustless installation, you can follow the [manual installation instructions](docs/manual_installation.md). ## Verifying Your Software -You can verify the data integrity and authenticity of the latest release with as little as three commands (though moving forward you will have to replace the version in the following commands with the version number you are attempting to validate). This process assumes that you have navigated to a folder where you have these four relevant files present: +You can verify the data integrity and authenticity of the latest release with as little as three commands. This process assumes that you know [how to navigate on a terminal](https://terminalcheatsheet.com/guides/navigate-terminal) and have navigated to the folder where you have these four relevant files present: (This will most likely be your Downloads folder.) * seedsigner_pubkey.gpg (from the main folder of this repo) -* seedsigner_0_4_5.img.zip (from the software release) -* seedsigner_0_4_5.img.zip.sha256 (from the software release) -* seedsigner_0_4_5.img.zip.sha256.sig (from the software release) +* seedsigner_0_4_6.img.zip (from the software release) +* seedsigner_0_4_6.img.zip.sha256 (from the software release) +* seedsigner_0_4_6.img.zip.sha256.sig (from the software release) -This process also assumes you are running the commands from a system where both GPG and shasum are installed and working. +**Note:** The specific version number of the files in your folder might not match the above exactly, but their overall format and amount should be the same. + +This process also assumes you are running the commands from a system where both [GPG](https://gnupg.org/download/index.html) and [shasum](https://command-not-found.com/shasum) are installed and working. First make sure that the public key is present in your keychain: ``` @@ -101,8 +103,10 @@ key <...> not changed Now you can verify the authenticity of the small text file containing the release's SHA256 hash with the command: ``` -gpg --verify seedsigner_0_4_5.img.zip.sha256.sig +gpg --verify seedsigner_0_*_*.img.zip.sha256.sig ``` +**Note:** The `*`s in the command above allow the terminal to auto-populate the command with the version number you have in the folder you are in. It should be copied and pasted as is. + The reponse to this command should include the text: ``` Good signature from "seedsigner " [unknown] @@ -111,11 +115,11 @@ The previous command validates that aforementioned small text file was signed us The last step is to make sure the .zip file that you've downloaded, and that contains the released software, is a perfect match to the software that was published by the holder of the private key in the last step. The command for this step is: ``` -shasum -a 256 -c seedsigner_0_4_5.img.zip.sha256 +shasum -a 256 -c seedsigner_0_*_*.img.zip.sha256 ``` The reponse to this command should include the text: ``` -seedsigner_0_4_5.img.zip: OK +seedsigner_0_4_6.img.zip: OK ``` There are other steps you can take to verify the software, including examining the hash value in the .sha256 text file, but this one has been documented here because it seems the simplest for most people to follow. Please recognize that this process can only validate the software to the extent that the entity that first published the key is an honest actor, and assumes the private key has remained uncompromised and is not being used by a malicious actor. @@ -138,6 +142,14 @@ The Orange Pill enclosure design offers a more finished look that includes butto The upper and lower portions of the enclosure can be printed using a standard FDM 3D printer, no supports necessary. The buttons and joystick nub should ideally be produced with a SLA/resin printer. An overview of the entire assembly process can be found [here](https://youtu.be/aIIc2DiZYcI). To access the design files and printable models, click [here](https://github.com/SeedSigner/seedsigner/tree/main/enclosures/orange_pill). +### Community Designs + +* [Lil Pill](https://cults3d.com/en/3d-model/gadget/lil-pill-seedsigner-case) by @_CyberNomad +* [OrangeSurf Case](https://github.com/orangesurf/orangesurf-seedsigner-case) by @OrangeSurfBTC +* [PS4 Seedsigner](https://www.thingiverse.com/thing:5363525) by @Silexperience +* [OpenPill Faceplate](https://www.printables.com/en/model/179924-seedsigner-open-pill-cover-plates-digital-cross-jo) by @Revetuzo +* [Waveshare CoverPlate](https://cults3d.com/en/3d-model/various/seedsigner-coverplate-for-waveshare-1-3-inch-lcd-hat-with-240x240-pixel-display) by @Adathome1 + --------------- # SeedQR Printable Templates diff --git a/docs/code_structure.md b/docs/code_structure.md new file mode 100644 index 00000000..50b7d315 --- /dev/null +++ b/docs/code_structure.md @@ -0,0 +1,21 @@ +# Code Structure + +SeedSigner roughly follows a Model-View-Controller approach. Like in a typical web app (e.g. Flask) the `View`s can be called as needed like individual web urls. After completing display and interaction with the user, the `View` then decides where to route the user next, analogous to a web app returning a `response.redirect(url)`. + +The `Controller` then ends up being quite stripped down. For example, there's no need for a web app's `urls.py` since there are no mappings from url to `View` to maintain since we're not actually using a url/http routing approach. + +`View`s have to handle user interaction so there are `while True` loops that cycle between waiting for user input, gathering data, and then updating the UI components accordingly. You wouldn't find this kind of cycle in a web app because this sort of interactive user input is handled in the browser at the html/css/js level. + + + +* `Model`s: Store the persistent settings, the in-memory seeds, current wallet information, etc. +* `Controller`: Manages the state of the world and controls access to global resources. +* `View`s: Implementation of each screen. Prepares relevant data for display. Must also instantiate the display objects that will actually render the UI. +* `gui.screens`: Re-usable formatted UI renderers. +* `gui.components`: Basic individual UI elements that are used by the `templates` such as the top nav, buttons, button lists, text displays. + +In an typical webserver context the `View` would send data to an html template (e.g. Jinja) which would then dynamically populate the page with html elements like ``, `