.github/workflows/release.yml

@@ -10,41 +10,53 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        os: [macos-latest, ubuntu-latest, macos-13]  # Specify the runners you want to use
+        include:
+          - os: ubuntu-latest
+            target: x86_64-unknown-linux-gnu
+          - os: ubuntu-latest
+            target: aarch64-unknown-linux-gnu
+          - os: macos-latest
+            target: aarch64-apple-darwin
+          - os: macos-13
+            target: x86_64-apple-darwin
 
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Dynamically create a tag from the pushed version
       - name: Get the tag name
         id: get_tag
         run: | 
           echo "TAG=${GITHUB_REF##*/}" >> $GITHUB_ENV
 
       - name: Set up Rust
         uses: actions-rust-lang/setup-rust-toolchain@v1
+        with:
+          target: ${{ matrix.target }}
+
+      - name: Install cross-compilation tools
+        if: matrix.target == 'aarch64-unknown-linux-gnu'
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y gcc-aarch64-linux-gnu
 
       - name: Build release binary
-        run: cargo build --release
+        env:
+          CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER: aarch64-linux-gnu-gcc
+        run: |
+          cargo build --release --target ${{ matrix.target }}
 
-      # Perhaps we can ignore tests, as they are run by the CI workflow
-      # - name: Run tests
-      #   run: cargo test --release
-      #
-
       - name: Get OS and architecture
         run: |
-          echo "os=$(uname -s | tr '[:upper:]' '[:lower:]')" >> $GITHUB_ENV
-          echo "arch=$(uname -m)" >> $GITHUB_ENV
+          echo "OS=$(echo ${{ matrix.target }} | grep -q 'linux' && echo 'linux' || echo 'darwin')" >> $GITHUB_ENV
+          echo "ARCH=$(echo ${{ matrix.target }} | grep -q 'aarch64' && echo 'arm64' || echo 'x86_64')" >> $GITHUB_ENV
 
       - name: Create release archive
         run: |
-          mkdir -p release
-          ARCH="${{ env.arch }}"
-          OS="${{ env.os }}"
-          cp target/release/spaced release/spaced-${{ env.TAG }}-${OS}-${ARCH}
-          cp target/release/space-cli release/space-cli-${{ env.TAG }}-${OS}-${ARCH}
+          mkdir -p spaces-${{ env.TAG }}-${{ env.OS }}-${{ env.ARCH }}
+          cp target/${{ matrix.target }}/release/spaced spaces-${{ env.TAG }}-${{ env.OS }}-${{ env.ARCH }}/spaced
+          cp target/${{ matrix.target }}/release/space-cli spaces-${{ env.TAG }}-${{ env.OS }}-${{ env.ARCH }}/space-cli
+          tar -czf spaces-${{ env.TAG }}-${{ env.OS }}-${{ env.ARCH }}.tar.gz spaces-${{ env.TAG }}-${{ env.OS }}-${{ env.ARCH }}
 
       - name: Create GitHub Release
         id: create_release
@@ -57,8 +69,7 @@ jobs:
           draft: false
           prerelease: false
           files: | 
-            release/spaced-${{ env.TAG }}-${{ env.os }}-${{ env.arch }}
-            release/space-cli-${{ env.TAG }}-${{ env.os }}-${{ env.arch }}
+            spaces-${{ env.TAG }}-${{ env.OS }}-${{ env.ARCH }}.tar.gz
           make_latest: true
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -1,3 +1,4 @@
 target
 .idea
-.DS_store
+.DS_store
+.zone

CONTRIBUTING.md

@@ -0,0 +1,49 @@
+# Contributing to Spaces
+
+This document is adapted from Bitcoin Core [contributing guide](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md). Everyone is welcome to contribute towards development in the form of peer review, testing and patches. This document explains the practical process and guidelines for contributing.
+
+## Getting started
+
+Reviewing and testing is highly valued and the most effective way you can contribute as a new contributor. It also will teach you much more about the code and process than opening pull requests.
+
+
+### Good First Issue Label
+
+The purpose of the good first issue label is to highlight which issues are suitable for a new contributor without a deep understanding of the codebase.
+
+However, good first issues can be solved by anyone. If they remain unsolved for a longer time, a frequent contributor might address them.
+
+You do not need to request permission to start working on an issue. However, you are encouraged to leave a comment if you are planning to work on it. This will help other contributors monitor which issues are actively being addressed and is also an effective way to request assistance if and when you need it.
+
+
+## Communication Channels
+
+You can join the [spaces telegram](https://t.me/spacesprotocol).
+
+Discussion about codebase improvements happens in GitHub issues and pull requests.
+
+## Contributor Workflow
+
+The codebase is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests" (PRs). This facilitates social contribution, easy testing and peer review.
+
+To contribute a patch, the workflow is as follows:
+
+1. Fork repository (only for the first time)
+2. Create topic branch
+3. Commit patches
+
+## Squashing Commits
+
+If your pull request contains fixup commits (commits that change the same line of code repeatedly) or too fine-grained commits, it's a good practice to squash your commits to better prepare them for review. 
+
+Learn how to write [good commit messages](https://cbea.ms/git-commit/)
+
+## Pull Request Philosophy
+
+It's a good practice to make Patchsets focused. For example, a pull request could add a feature, fix a bug, or refactor code; but not a mixture. Please also avoid super pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult.
+
+
+## Copyright
+
+By contributing to this repository, you agree to license your work under the MIT license unless specified otherwise in contrib/debian/copyright or at the top of the file itself. Any work contributed where you are not the original author must contain its license header with the original author(s) and source.
+