feat_: extract storenode cycle to go-waku

[#21557 ] feat: show from account page in swap flow (#21611 )
* [#21557] feat: show from account page in swap flow * [#21557] feat: add disabled state to account-item * [#21557] fix: apply suggestion * [#21557] fix: add format address util and rename screen * [#21557] fix: check and count account with token balance * [#21557] fix: check for root screen
2024-11-22 11:26:00 -04:00 · 2024-11-22 16:12:00 +03:00 · 2024-11-22 11:00:02 +08:00 · 2024-11-21 16:28:45 +00:00 · 2024-11-21 18:16:01 +05:30 · 2024-11-21 12:19:58 +00:00
1128 changed files with 31954 additions and 21610 deletions
@@ -74,7 +74,8 @@
                ;; https://github.com/borkdude/clj-kondo/issues/867
                :unresolved-symbol             {:exclude [PersistentPriorityMap.EMPTY
                                                          number
-                                                          legacy.status-im.test-helpers/restore-app-db]}
+                                                          legacy.status-im.test-helpers/restore-app-db
+                                                          (cljs.test/is [match-strict?])]}
                :unresolved-var                {:level :error}
                :unsorted-required-namespaces  {:level :error}
                :unused-alias                  {:level :warning}
@@ -1,10 +1,8 @@
 CACHED_WEBVIEWS_ENABLED=1
 DEBUG_WEBVIEW=1
-DEFAULT_NETWORK=mainnet_rpc
 DEV_BUILD=1
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
-FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=info
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -26,7 +24,6 @@ APN_TOPIC=im.status.ethereum.pr
 COMMUNITIES_ENABLED=1
 DATABASE_MANAGEMENT_ENABLED=1
 DELETE_MESSAGE_ENABLED=1
-COLLECTIBLES_ENABLED=1
 COMMANDS_ENABLED=1
 TWO_MINUTES_SYNCING=1
 SWAP_ENABLED=1
@@ -37,3 +34,5 @@ FAST_CREATE_COMMUNITY_ENABLED=1
 TEST_NETWORKS_ENABLED=1
 SHOW_NOT_IMPLEMENTED_FEATURES=0
 ENABLE_ALERT_BANNER=0
+FLAG_WALLET_CONNECT_ENABLED=1
+LOG_REQUEST_GO=1
@@ -1,8 +1,7 @@
 DEBUG_WEBVIEW=1
-DEFAULT_NETWORK=goerli_rpc
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
-FLEET=status.prod
+FLEET=status.staging
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=debug
 MAILSERVER_CONFIRMATIONS_ENABLED=0
@@ -22,8 +21,8 @@ KEYCARD_TEST_MENU=1
 QR_READ_TEST_MENU=1
 ENABLE_ROOT_ALERT=0
 APN_TOPIC=im.status.ethereum.pr
-VERIFY_TRANSACTION_CHAIN_ID=5
-VERIFY_ENS_CHAIN_ID=5
+VERIFY_TRANSACTION_CHAIN_ID=11155111
+VERIFY_ENS_CHAIN_ID=11155111
 TEST_STATEOFUS=1
 DATABASE_MANAGEMENT_ENABLED=1
 COMMUNITIES_ENABLED=1
@@ -38,3 +37,6 @@ SHOW_NOT_IMPLEMENTED_FEATURES=1
 DELETE_MESSAGE_FOR_ME_UNDO_TIME_LIMIT=10000
 DELETE_MESSAGE_UNDO_TIME_LIMIT=10000
 ENABLE_ALERT_BANNER=0
+FLAG_WALLET_CONNECT_ENABLED=1
+MOBILE_DATA_SYNCING_TOGGLE_ENABLE=0
+LOG_REQUEST_GO=1
@@ -1,9 +1,7 @@
 CACHED_WEBVIEWS_ENABLED=1
 DEBUG_WEBVIEW=1
-DEFAULT_NETWORK=goerli_rpc
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
-FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=debug
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -22,8 +20,8 @@ KEYCARD_TEST_MENU=0
 ENABLE_ROOT_ALERT=1
 DISABLE_WALLET_ON_MOBILE_NETWORK=1
 APN_TOPIC=im.status.ethereum.pr
-VERIFY_TRANSACTION_CHAIN_ID=5
-VERIFY_ENS_CHAIN_ID=5
+VERIFY_TRANSACTION_CHAIN_ID=11155111
+VERIFY_ENS_CHAIN_ID=11155111
 TEST_STATEOFUS=1
 BLANK_PREVIEW=0
 DATABASE_MANAGEMENT_ENABLED=1
@@ -37,3 +35,5 @@ LOCAL_PAIRING_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=1
 TEST_NETWORKS_ENABLED=1
 ENABLE_ALERT_BANNER=1
+FLAG_WALLET_CONNECT_ENABLED=1
+LOG_REQUEST_GO=1
@@ -1,8 +1,6 @@
 DEBUG_WEBVIEW=1
-DEFAULT_NETWORK=mainnet_rpc
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
-FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=info
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -24,3 +22,5 @@ DELETE_MESSAGE_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=0
 TEST_NETWORKS_ENABLED=0
 ENABLE_ALERT_BANNER=1
+FLAG_WALLET_CONNECT_ENABLED=1
+LOG_REQUEST_GO=0
@@ -1,8 +1,6 @@
 DEBUG_WEBVIEW=0
-DEFAULT_NETWORK=mainnet_rpc
 ETHEREUM_DEV_CLUSTER=0
 EXTENSIONS=0
-FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -18,6 +16,8 @@ PARTITIONED_TOPIC=0
 ENABLE_ROOT_ALERT=1
 MAX_IMAGES_BATCH=1
 DELETE_MESSAGE_ENABLED=1
-COLLECTIBLES_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=0
 TEST_NETWORKS_ENABLED=0
+STATUS_PROXY_STAGE_NAME=prod
+FLAG_WALLET_CONNECT_ENABLED=1
+LOG_REQUEST_GO=0
@@ -1,8 +1,8 @@
 ---
-name: MVPBug Report
-about: MVPBug Report
+name: Bug Report
+about: Bug Report
 title: ''
-labels: ['E:Mobile Bug MVP', ':1234: low prio']
+type: 'Bug'
 assignees: ''

 ---
@@ -0,0 +1,3 @@
+[submodule "legal-docs"]
+	path = legal-docs
+	url = https://github.com/status-im/status-software-legal-documents.git
@@ -1,10 +1,15 @@
-*
+/*
+
+# Format top-level js files.
 !*.js
-!*/
-*.clj-kondo
-*.shadow-cljs
-modules
-result
-target
-component-spec
-/app
+
+# Ignore all except src/js/**/*.js
+!/src/
+/src/*
+!/src/js
+!/src/js/**/*.js
+
+# Ignore all except translations/en.json
+!/translations/
+/translations/*
+!/translations/en.json
@@ -6,4 +6,8 @@ module.exports = {
  tabWidth: 2,
  trailingComma: 'all',
  useTabs: false,
+
+  // JSON sorting
+  jsonSortOrder: '{ "/.*/": "caseInsensitiveLexical" } ',
+  plugins: ['prettier-plugin-sort-json'],
 };
@@ -1,6 +1,8 @@
 {
    "ignore_dirs": [
        "android/build",
-        "target"
+        "target",
+	".clj-kondo",
+	".shadow-cljs"
    ]
 }
@@ -97,6 +97,8 @@ nix-purge: ##@nix Completely remove Nix setup, including /nix directory
 	nix/scripts/purge.sh

 nix-update-gradle: export TARGET := gradle
+nix-update-gradle: export ORG_GRADLE_PROJECT_hermesEnabled := false
+nix-update-gradle: export ORG_GRADLE_PROJECT_universalApk := false
 nix-update-gradle: ##@nix Update maven nix expressions based on current gradle setup
 	nix/deps/gradle/generate.sh

@@ -215,15 +217,13 @@ build-fdroid: ##@build Build release for F-Droid
 build-android: export BUILD_ENV ?= prod
 build-android: export BUILD_TYPE ?= nightly
 build-android: export ORG_GRADLE_PROJECT_versionCode ?= $(TMP_BUILD_NUMBER)
-build-android: export ANDROID_ABI_SPLIT ?= false
-build-android: export ANDROID_ABI_INCLUDE ?= armeabi-v7a;arm64-v8a;x86
 build-android: ##@build Build unsigned Android APK
 	@scripts/build-android.sh

 release-android: export TARGET := keytool
 release-android: export KEYSTORE_PATH ?= $(HOME)/.gradle/status-im.keystore
 release-android: keystore build-android ##@build Build signed Android APK
-	@scripts/sign-android.sh result/app-release-unsigned.apk
+	@scripts/sign-android.sh result/app-arm64-v8a-release-unsigned.apk

 release-ios: export TARGET := ios
 release-ios: export IOS_STATUS_GO_TARGETS := ios/arm64
@@ -278,6 +278,7 @@ run-android: export TARGET := android
 # Disabled for debug builds to avoid 'maximum call stack exceeded' errors.
 # https://github.com/status-im/status-mobile/issues/18493
 run-android: export ORG_GRADLE_PROJECT_hermesEnabled := false
+run-android: export ORG_GRADLE_PROJECT_universalApk := false
 run-android: ##@run Build Android APK and start it on the device
 	@scripts/run-android.sh

@@ -317,7 +318,7 @@ lint: ##@test Run code style checks
 	scripts/lint/translations.clj && \
 	zprint '{:search-config? true}' -sfc $$ALL_CLOJURE_FILES && \
 	sh scripts/lint/trailing-newline.sh && \
-	node_modules/.bin/prettier --write .
+	node_modules/.bin/prettier --check .

 # NOTE: We run the linter twice because of https://github.com/kkinnear/zprint/issues/271
 lint-fix: export TARGET := clojure
@@ -353,13 +354,17 @@ test: export SHADOW_NS_REGEXP := .*-test$$
 test: ##@test Run all Clojure tests
 test: _test-clojure

+# Note: we need to override the :output-to and :ns-regexp options because
+# shadow-cljs has a bug where it will not read from the env vars to expand the
+# configuration when the shadow-cljs mobile target is already running.
 test-watch-for-repl: export TARGET := default
 test-watch-for-repl: export SHADOW_OUTPUT_TO := target/test/test.js
 test-watch-for-repl: export SHADOW_NS_REGEXP := .*-test$$
 test-watch-for-repl: ##@test Watch all Clojure tests and support REPL connections
+	rm -f "$$SHADOW_OUTPUT_TO" && \
 	yarn install && shadow-cljs compile mocks && \
 	concurrently --kill-others --prefix-colors 'auto' --names 'build,repl' \
-		'yarn shadow-cljs watch test --verbose' \
+		"yarn shadow-cljs watch test --verbose --config-merge '{:output-to \"$(SHADOW_OUTPUT_TO)\" :ns-regexp \"$(SHADOW_NS_REGEXP)\"}'" \
 		"until [ -f $$SHADOW_OUTPUT_TO ] ; do sleep 1 ; done ; node --require ./test-resources/override.js $$SHADOW_OUTPUT_TO --repl"

 test-unit: export SHADOW_OUTPUT_TO := target/unit_test/test.js
@@ -434,10 +439,11 @@ android-clean: ##@prepare Clean Gradle state
 	rm -rf ~/.gradle


-android-ports: export FLOWSTORM_PORT := 7722
+android-ports: export FLOWSTORM_PORT ?= 7722
 android-ports: export TARGET := android-sdk
+android-ports: export RCT_METRO_PORT ?= 8081
 android-ports: ##@other Add proxies to Android Device/Simulator
-	adb reverse tcp:8081 tcp:8081 && \
+	adb reverse tcp:$(RCT_METRO_PORT) tcp:$(RCT_METRO_PORT) && \
 	adb reverse tcp:3449 tcp:3449 && \
 	adb reverse tcp:4567 tcp:4567 && \
 	adb reverse tcp:$(FLOWSTORM_PORT) tcp:$(FLOWSTORM_PORT) && \
@@ -457,6 +463,12 @@ android-tail-geth: export VERSION ?= debug
 android-tail-geth:
 	adb shell 'while true; do cat; sleep 1; done < /storage/emulated/0/Android/data/im.status.ethereum$$( [ "$(VERSION)" = "release" ] || echo ".$(VERSION)" )/files/Download/geth.log'

+android-clean-geth: export TARGET := android-sdk
+android-clean-geth: export VERSION ?= debug
+android-clean-geth:
+	adb shell 'rm /storage/emulated/0/Android/data/im.status.ethereum$$( [ "$(VERSION)" = "release" ] || echo ".$(VERSION)" )/files/Download/geth.log'
+
+
 android-logcat: export TARGET := android-sdk
 android-logcat: ##@other Read status-mobile logs from Android phone using adb
 	adb logcat | grep -e RNBootstrap -e ReactNativeJS -e ReactNative -e StatusModule -e StatusNativeLogs -e 'F DEBUG   :' -e 'Go      :' -e 'GoLog   :' -e 'libc    :'
@@ -1 +1 @@
-2.29.0
+2.30.0
@@ -211,7 +211,7 @@ android {
            reset()
            enable getEnvOrConfig('ANDROID_ABI_SPLIT').toBoolean()
            include getEnvOrConfig('ANDROID_ABI_INCLUDE').split(";")
-            universalApk true
+            universalApk getEnvOrConfig('ORG_GRADLE_PROJECT_universalApk').toBoolean()
        }
    }
    signingConfigs {
@@ -36,6 +36,7 @@
            android:allowBackup="false"
            android:label="@string/app_name"
            android:icon="@mipmap/ic_launcher"
+            android:roundIcon="@mipmap/ic_launcher_round"
            android:theme="@style/Theme.AppSplash"
            android:name=".MainApplication"
            android:largeHeap="true"
@@ -2,4 +2,5 @@
 <adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@mipmap/ic_background"/>
    <foreground android:drawable="@mipmap/ic_foreground"/>
-</adaptive-icon>
+    <monochrome android:drawable="@mipmap/ic_launcher_monochrome" />
+</adaptive-icon>
@@ -2,4 +2,5 @@
 <adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@mipmap/ic_background"/>
    <foreground android:drawable="@mipmap/ic_foreground"/>
-</adaptive-icon>
+    <monochrome android:drawable="@mipmap/ic_launcher_monochrome" />
+</adaptive-icon>
@@ -38,10 +38,10 @@ KEYSTORE_PASSWORD=password
 KEYSTORE_ALIAS=status
 KEYSTORE_KEY_PASSWORD=password

-# By default we build a mostly universal APK
-ANDROID_ABI_SPLIT=false
-# Some platforms are excluded though
-ANDROID_ABI_INCLUDE=armeabi-v7a;arm64-v8a;x86;x86_64
+# Splitting by CPU Architecture produces smaller APKs.
+ANDROID_ABI_SPLIT=true
+# By default its better to only build apk for most recent devices.
+ANDROID_ABI_INCLUDE=arm64-v8a

 org.gradle.jvmargs=-Xmx8704M -XX:+UseParallelGC

@@ -0,0 +1,9 @@
+initscript {
+    repositories {
+        gradlePluginPortal()
+    }
+    dependencies {
+        classpath "org.gradle:github-dependency-graph-gradle-plugin:+"
+    }
+}
+apply plugin: org.gradle.dependencygraph.simple.SimpleDependencyGraphPlugin
@@ -1,12 +1,12 @@
 pluginManagement {
-include ':react-native-share'
-project(':react-native-share').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-share/android')
+includeBuild('../node_modules/@react-native/gradle-plugin')
  repositories {
      mavenLocal() // Let's prioritize local Maven repos so that Nix can provide them offline
      gradlePluginPortal()
  }
 }
-
+include ':react-native-share'
+project(':react-native-share').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-share/android')
 rootProject.name = 'StatusIm'
 apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
 include ':react-native-nfc-manager'
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 /* Options section can't access functions in objects. */
 def isPRBuild = utils.isPRBuild()
@@ -72,11 +72,7 @@ pipeline {
        stage('Upload') {
          steps { script {
            def urls = apks.collect { s5cmd.upload(it) }
-            if (urls.size() > 1) { /* Return only the universal APK. */
-              env.PKG_URL = urls.find { it.contains('universal') }
-            } else { /* If no universal is available pick first. */
-              env.PKG_URL = urls.first()
-            }
+            env.PKG_URL = urls.first()
            jenkins.setBuildDesc(APK: env.PKG_URL)
          } }
        }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 import groovy.json.JsonBuilder

@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {
  agent { label 'linux' }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 /* Options section can't access functions in objects. */
 def isPRBuild = utils.isPRBuild()
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 /* Options section can't access functions in objects. */
 def isPRBuild = utils.isPRBuild()
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {

@@ -99,7 +99,7 @@ pipeline {
                --rerun_count=2 \
                --testrail_report=True \
                -m testrail_id \
-                -m \"new_ui_critical or new_ui_medium\" \
+                -m \"nightly\" \
                -k \"${params.KEYWORD_EXPRESSION}\" \
                --apk=${params.APK_URL ?: apk_path}
            """
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {

@@ -35,13 +35,11 @@ pipeline {
      description: 'OBSOLETE ARGUMENT TO BE REMOVED',
      defaultValue: 'DUMMY',
    )
-    /* Commented to use TEST_MARKERS values from job params
    string(
      name: 'TEST_MARKERS',
      description: 'Marker expression for matching tests to run.',
-      defaultValue: 'new_ui_critical',
+      defaultValue: 'smoke',
    )
-    */
  }

  options {
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {

@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {
  agent { label 'macos' }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {
  agent { label params.AGENT_LABEL }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {
  agent { label 'linux' }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.1'
+library 'status-jenkins-lib@v1.9.13'

 pipeline {
  agent {
@@ -1,67 +1,43 @@
-## Getting Started 
-
-[Starting Guide](starting-guide.md)
-
-[IDE Setup](ide-setup.md)
-
+## Getting Started

+- [Starting Guide](starting-guide.md)
+- [IDE Setup](ide-setup.md)

 ## Development Process

-[Coding guidelines](new-guidelines.md)
-
-[UI components coding guidelines](ui-guidelines.md)
-
-[Release Checklist](release-checklist.md)
-
-[Release Guide](release-guide.md)
-
-[Merging PR process](merging-pr-process.md)
-
-[PR Review Policy](pr-review-policy.md)
-
-[Working on PR together with QA team](pipeline_process.md)
-
-[Debugging](debugging.md)
-
-[Patching](patching.md)
-
-[Creating a pixel perfect UI](pixel-perfection.md)
-
-[Contributing to status-go](status-go-changes.md)
-
-[Malli schemas (recorded demo)](https://www.youtube.com/watch?v=SlRio70aYVI) ([slides](files/forging-code-with-schemas-sep-2023-slides.pdf))
+- [Coding guidelines](new-guidelines.md)
+- [UI components coding guidelines](ui-guidelines.md)
+- [Release Checklist](release-checklist.md)
+- [Release Guide](release-guide.md)
+- [Merging PR process](merging-pr-process.md)
+- [PR Review Policy](pr-review-policy.md)
+- [Working on PR together with QA team](pipeline_process.md)
+- [Debugging](debugging.md)
+- [Patching](patching.md)
+- [Creating a pixel perfect UI](pixel-perfection.md)
+- [Contributing to status-go](status-go-changes.md)
+- [Malli schemas (recorded demo)](https://www.youtube.com/watch?v=SlRio70aYVI) ([slides](files/forging-code-with-schemas-sep-2023-slides.pdf))

 ## Testing

-[How to run local tests](testing.md)
-
-[End-to-end tests (e2e) overview](how-to-launch-e2e.md)
-
-[Component tests (jest) overview](component-tests-overview.md)
-
+- [Overview](tests/tests-overview.md)
+- [How to run local tests](tests/how-to-run-local-tests.md)
+- [End-to-end tests (e2e) overview](tests/how-to-launch-e2e.md)
+- [Component tests (jest) overview](tests/component-tests-overview.md)

 ## Project details

-[status-go introduction (recorded meeting)](https://drive.google.com/file/d/1B7TljmTZ8fHkqJH8ChU1Cp4FGDFM03gq/view)
-
-[re-frame usage (recorded meeting)](https://drive.google.com/file/d/1qv_E0CEGzQpu_zGXD0gCTU5EvhC2k8Jy/view)
-
-[status app functionality demo](https://drive.google.com/file/u/0/d/1PmwsMLTLDNNIdv5_6wvMOwoj2PfT50c6/view)
+- [status-go introduction (recorded meeting)](https://drive.google.com/file/d/1B7TljmTZ8fHkqJH8ChU1Cp4FGDFM03gq/view)
+- [re-frame usage (recorded meeting)](https://drive.google.com/file/d/1qv_E0CEGzQpu_zGXD0gCTU5EvhC2k8Jy/view)
+- [status app functionality demo](https://drive.google.com/file/u/0/d/1PmwsMLTLDNNIdv5_6wvMOwoj2PfT50c6/view)

 ## Misc

-[Importing icons from Figma into project](export-icons.md)
-
-[Updating Status APK builds for the F-Droid Android application catalogue](fdroid.md)
-
-[Troubleshooting for known errors](troubleshooting.md)
-
-
+- [Importing assets from Figma into project](import-assets.md)
+- [Updating Status APK builds for the F-Droid Android application catalogue](fdroid.md)
+- [Troubleshooting for known errors](troubleshooting.md)

 ## Outdated:

-[Old guidelines](codebase-structure-and-guidelines.md)
-
-[Post mortem analysis](post-mortem.md)
-
+- [Old guidelines](codebase-structure-and-guidelines.md)
+- [Post mortem analysis](post-mortem.md)
@@ -1,6 +1,6 @@
-# new icons
+# Importing assets from Figma into project

-## Export icons
+## Icons

 ![](images/export-icons/export-icons.gif)

@@ -13,3 +13,11 @@
    ```
    2x@2x
 4. If you want platform specific icon use `.android` or `.ios` suffixes.  Example `icon_name@2x.android.png`.:w
+
+## Images
+
+Make sure to compress images before using into project.
+```
+make shell
+./scripts/compress_image.sh image_path
+```
@@ -32,9 +32,9 @@ Ready for testing, a PR should meet the following criteria:
 ### E2E tests and analyzing the results

 The PR **MUST** be moved to the E2E column when it is ready for testing (**mandatory for all PRs**).
-That will also trigger e2e tests run. QAs are monitoring PRs from E2E column and take it into test. 
+That will also trigger e2e tests run. QAs are monitoring PRs from E2E column and take it into test.
 This step cannot be skipped. So, at least one comment from the `status-im-auto` bot with results is a prerequisite for moving forward.
-Information on how to analyze tests can be found [here](https://github.com/status-im/status-mobile/blob/develop/doc/how-to-launch-e2e.md).
+Information on how to analyze tests can be found [here](https://github.com/status-im/status-mobile/blob/develop/doc/tests/how-to-launch-e2e.md).
 Tests might be flaky, as they depend on infrastructure - SauceLabs and Waku.

 If there are `Failed tests` and you are not sure about the reason, you can always ping the mobile QAs for help (preferably in PRs by `@status-im/mobile-qa`).
@@ -46,14 +46,14 @@ Please, respect this rule.**

 ### Adding `skip-manual-qa`

-**Do not hesitate to use a `skip-manual-qa`** if you're sure that it is a simple flow and you checked it. 
+**Do not hesitate to use a `skip-manual-qa`** if you're sure that it is a simple flow and you checked it.
 - Please ask another team member before adding the `skip-manual-qa` label (PR/Status community/DMs) so that there's a second opinion.
 - The PR MUST have a proper reasoning why manual QA is skipped.
 - The PR MUST include the steps of testing that has been done by the developer prior to moving it forward.

 **NOTE:** Make sure that QAs are OK with that;

-Before merging PRs, please make sure that information is added about how you tested the PRs, that e2s have been passed and their results have been reviewed. 
+Before merging PRs, please make sure that information is added about how you tested the PRs, that e2s have been passed and their results have been reviewed.

 The QA team appreciates your help!

@@ -72,7 +72,7 @@ The QA team appreciates your help!
 - QA engineer picks up one of PRs with the ```request-manual-qa``` label, drags the item to the ```IN TESTING``` column and assigns it to themselves.
 - During testing, QA will add comments describing the issues found, and also review automation tests results.
 Usually found issues are numbered as "Issue 1, Issue 2", etc.
-When the first round of testing is completed and all issues for this stage are found, the QA can add the ```Tested - Issues``` label and drag the card to the ```CONTRIBUTOR``` column. These two actions are optional. 
+When the first round of testing is completed and all issues for this stage are found, the QA can add the ```Tested - Issues``` label and drag the card to the ```CONTRIBUTOR``` column. These two actions are optional.

 **IMPORTANT NOTE:** when the issues are fixed, developer **MUST** notify the QA that it is ready to be re-tested again by mention them in the PR.

@@ -86,7 +86,7 @@ After that the developer merges PR into develop.
 _**How do I know if a design review is needed?**_

 There are three cases here depending on the changes in the PR:
-1. **Functional PRs with UI changes:** after the ```Tested - OK``` label is added, the QA moves the PR to the ```Design review``` column + mentions ```@Francesca-G``` in comments. 
+1. **Functional PRs with UI changes:** after the ```Tested - OK``` label is added, the QA moves the PR to the ```Design review``` column + mentions ```@Francesca-G``` in comments.
 2. **Component PRs:** once the PR has received a review from developers and e2e tests results, it can be moved directly to the ```Design review``` column by the developer (manual testing step can be skipped) + the developer mentions ```@Francesca-G``` in comments.
 3. **Functional PRs changes in which are not related to UI (e.g. a crash fix):** skip the ```Design review``` step (the PR should only be manually tested by QA).

@@ -99,7 +99,7 @@ There are three possible scenarios when the design review is completed:
 **Notes:**
 - If your PR has a long story and started from `develop` branch several days ago, please rebase it to current develop before adding label
 - if PR can be tested by developer (in case of small changes) and/or developer is sure that the changes made cannot introduce a regression, then PR can be merged without manual testing. Also, currently, PRs are not manually tested if the changes relate only the design (creation of components, etc.) and do not affect the functionality (see `skip-manual-qa` label)
---        
+---

 #### Why my PR is in `Contributor` column?
 PR can be moved to this column by the ```status-github-bot``` or by QA engineer with label `Tested-issues` or if one of the requirements for manual QA was not met.
@@ -120,6 +120,6 @@ In the second case - after fixing of all found issues, the developer should ping
 6. In case of manual testing - the label ```Tested - OK``` from QA
 7. In case of design review - the approval from the designer

-You can merge your PR into develop - some useful clues you can find [here](https://notes.status.im/setup-e2e#3-Merging-PR) 
+You can merge your PR into develop - some useful clues you can find [here](https://notes.status.im/setup-e2e#3-Merging-PR)

-HAPPY DEVELOPMENT! :tada: 
+HAPPY DEVELOPMENT! :tada:
@@ -8,7 +8,7 @@ As a part of CI for Status mobile app and in order to ensure there are no regres
 - Automated tests written on Python 3.9 and pytest.
 - Appium (server) and Selenium WebDriver (protocol) are the base of test automation framework.

-TestRail is a test case management system tool where we have test cases. 
+TestRail is a test case management system tool where we have test cases.


 Each of the test case gets a priority (Critical/High/Medium)
@@ -20,21 +20,21 @@ For now we support e2e for Android only.
 Whenever we need to push set of test scripts we create 16 parallel sessions (max, but depending on amount of cases that are included in job) and each thread: 1) uploads Android .apk file to SauceLabs -> 2) runs through the test steps -> 3) receives results whether test failed on particular step or succeeded with no errors -> 3) Parse test results and push them as a Github comment (if the suite ran against respective PR) and into TestRail.

 We push **whole automation test suite (currently 155, amount is changing)** against each nightly build (if the nightly builds job succeeded). Results of the test run are saved in TestRail.
-And also we push set of autotests whenever PR with successful builds got moved in to `E2E Tests` column from [Pipeline for QA dashboard ](https://github.com/status-im/status-react/projects/7). 
+And also we push set of autotests whenever PR with successful builds got moved in to `E2E Tests` column from [Pipeline for QA dashboard ](https://github.com/status-im/status-react/projects/7).
 In that case we save results in TestRail as well and push a comment with test results in a respective PR.

 For example: https://github.com/status-im/status-react/pull/9147#issuecomment-540008770

-![](images/how-to-launch-e2e/how-to-launch-e2e-1.png)
+![](../images/how-to-launch-e2e/how-to-launch-e2e-1.png)


 The test_send_stt_from_wallet opens link in TestRail https://ethstatus.testrail.net/index.php?/tests/view/890885 where performed steps could be found
-List of all runs performed by test jobs could be found here https://ethstatus.testrail.net/index.php?/runs/overview/14 
+List of all runs performed by test jobs could be found here https://ethstatus.testrail.net/index.php?/runs/overview/14

 **For credentials for TestRail to see results ping Chu in DM**:

 Opening any test run navigates you to list of test cases with results:
-![](images/how-to-launch-e2e/how-to-launch-e2e-2.png)
+![](../images/how-to-launch-e2e/how-to-launch-e2e-2.png)


 ## What about launching e2e manually
@@ -53,12 +53,12 @@ Params to specify:
 - test_marks: tests by priorities (by default: `critical or high or medium`, which corresponds the whole suite; to launch the same suite as in PRs, use `critical or high`)
 - testrail_case_id: here is the list of test cases which you may find in test rail (4-digit value)

-For easier access you can hit `Rerun tests` in GH comment and testrail_case_id/ apk_name/ pr_id  will be filled automatically. For making sure that tests are being rerun on most recent e2e build it is recommended to paste link to the last e2e build in apk_name field. The list of PR builds can be found in Jenkins Builds block on PR page. 
-![](images/how-to-launch-e2e/how-to-launch-e2e-3.png) 
+For easier access you can hit `Rerun tests` in GH comment and testrail_case_id/ apk_name/ pr_id  will be filled automatically. For making sure that tests are being rerun on most recent e2e build it is recommended to paste link to the last e2e build in apk_name field. The list of PR builds can be found in Jenkins Builds block on PR page.
+![](../images/how-to-launch-e2e/how-to-launch-e2e-3.png)
 And then hit ‘Build’.
 Once the job starts it picks up specified tests, runs them against provided apk and sends results to pull request.

-Even we have 16 parallel sessions for testing it’s a time consuming operation (whole test suite we have automated at the moment takes ~140 minutes to finish). 
+Even we have 16 parallel sessions for testing it’s a time consuming operation (whole test suite we have automated at the moment takes ~140 minutes to finish).
 So for PRs we pick only set of `critical or high` (you can also use this in TEST_MARKS param for job)
 tests (otherwise some PRs could wait their turn of the scheduled Jenkins job till the next day).

@@ -78,9 +78,9 @@ Several examples of when test fails to succeed:

 - **Valid issue in the automated test scripts** - that's what we're looking for

-Example: here is the test results https://github.com/status-im/status-react/pull/13015#issuecomment-1016495043 where one test failed. 
+Example: here is the test results https://github.com/status-im/status-react/pull/13015#issuecomment-1016495043 where one test failed.
    1. Open the test in TestRail and open session recorded for this test in SauceLabs
-![](images/how-to-launch-e2e/how-to-launch-e2e-4.png)
+![](../images/how-to-launch-e2e/how-to-launch-e2e-4.png)


 In TestRail you may find all the steps performed by the test.
@@ -92,12 +92,12 @@ For particular example it was failed on `Recover access(password:qwerty, keycard
 Not all features of the app could be covered by e2e at the moment:

 - Colours or place of an element on UI.
- Real ETH/token transactions. That’s the main reason we have separate .apk build for automation needs - it defaults to Goerli network. Also it has enabled keycard test menu, ENS names and chat commands are also on Goerli network (the same in PR builds, but not in nightlies / release)
+- Real ETH/token transactions. That’s the main reason we have separate .apk build for automation needs - it defaults to Sepolia network. Also it has enabled keycard test menu, ENS names and chat commands are also on Sepolia network (the same in PR builds, but not in nightlies / release)
 - Autologin/Biometric related actions (autologin available when device meets certain conditions like the it has set unlock password and device is not rooted: all emulators are rooted in SauceLabs)

 ## Brief flow for test to be automated

 Whenever there is a need to have a new test:
-1) Create a test scenario in TestRail. 
+1) Create a test scenario in TestRail.
 2) If certain item could be checked in scope of existing test case we update existing one (otherwise we may have thousands of test cases which is overkill to manage in TestRail as well as in automated test scripts). And also complex autotests increase probability to not catch regressions by stopping test execution (due to valid bug or changed feature) keeping the rest test steps uncovered. So here we need to balance when it makes sense to update existing test case with more checks.
 3) Then we create test script based on the test case, ensure test passes for the build and pushing the changes to repo.
@@ -0,0 +1,167 @@
+# Tests
+
+## Introduction
+
+This document provides a general overview of the types of tests we use and when
+to use them. It is not meant to be a tutorial or a detailed documentation about
+testing in software development.
+
+## Types of tests
+
+Tests in `status-mobile` are comprised of:
+
+- Unit tests
+  - Subscription tests
+  - Event tests
+  - Tests for various utilities
+- [Component tests](./component-tests-overview.md)
+- Integration/contract tests
+- [End-to-end tests](./how-to-launch-e2e.md)
+
+We apply the [test
+pyramid](https://en.wikipedia.org/wiki/Test_automation#Testing_at_different_levels)
+strategy, which means we want the majority of tests at the bottom of the
+pyramid. Those should be fast and deterministic and support REPL-Driven
+development (RDD). Slightly above them, we have component tests, then
+integration/contract tests and finally end-to-end tests. The closer to the top
+of the pyramid, the more valuable a test can be, but also more difficult to
+pinpoint why it failed and harder to make it dependable.
+
+*Note*: there are literally dozens of [types of
+tests](https://en.wikipedia.org/wiki/Software_testing), each with its strengths
+and weaknesses.
+
+We tend not to stub or mock implementations in our tests, which means our tests
+are [sociable](https://martinfowler.com/bliki/UnitTest.html).
+
+## What to test?
+
+The UI is driven by global & local state changes caused by events. Global state
+is managed by re-frame and local state by Reagent atoms or React hooks. Except
+for component and end-to-end tests, we test only non-UI code in `status-mobile`.
+Given that the UI is greatly derived from global state, by guaranteeing the
+state is correct we can prevent bugs and, more importantly, reduce the [cost of
+change](https://www.pmi.org/disciplined-agile/agile/costofchange).
+
+We strive to minimize the amount of _business logic_ in views (UI code). We
+achieve this by moving capabilities to status-go and also by adhering to
+re-frame's architecture.
+
+Whenever appropriate (see section `When to test?`), we _may_ test:
+
+- Re-frame events.
+- Re-frame subscriptions.
+- Utility functions.
+- User journeys through integration/contract tests.
+
+Interestingly, we don't test re-frame _effects_ in isolation.
+
+### What are status-mobile integration and contract tests?
+
+The mobile _integration tests_ can be used to "simulate" user interactions and
+make actual calls to status-go via the RPC layer and actually receive signals.
+We can also use these tests to verify the app-db and multiple subscriptions are
+correct. We use the word _simulate_ because there is no UI. Basically, any flow
+that can be driven by re-frame events is possible to automatically test. There
+is no way to change or inspect local state managed by React.
+
+A _contract test_ has the same capabilities as an integration test, but we want
+to draw the line that they should focus more on a particupar RPC endpoint or
+signal, and not on a user journey (e.g. create a wallet account). In the future,
+we may consider running them automatically in status-go.
+
+**Note:** integration tests and contract tests are currently overlapping in
+their responsibilities and still require a clearer distinction.
+
+## When to test?
+
+(Automated) tests basically exist to support rapid software changes, but not
+every piece of code should be tested. The following are general recommendations,
+not rules.
+
+- What would be the consequences to the user of a bug in the implementation you
+  are working on?
+- Can a QA exercise all the branches in the code you changed? Not surprisingly,
+  usually QAs can't test many code paths (it may be nearly impossible), and
+  because PRs are not often tested by reviewers, many PRs can get into `develop`
+  without the necessary quality assurance.
+- How costly was it for you to verify a function/event/etc was correct? Now
+  consider that this cost will be dispersed to every developer who needs to
+  change the implementation if there are no tests.
+- Check the number of conditionals, and if they nest as well. Every conditional
+  may require two different assertions, and the number of assertions can grow
+  exponentially.
+- How complicated are the arguments to the function? If they contain nested maps
+  or data that went through a few transformations, it may be tricky to decipher
+  what they are, unless you are familiar with the code. A test would be able to
+  capture the data, however complex they are.
+
+### When to unit-test subscriptions?
+
+Only test [layer-3
+subscriptions](https://day8.github.io/re-frame/subscriptions/#the-four-layers),
+i.e. don't bother testing extractor subscriptions (check the related
+[guideline](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/doc/new-guidelines.md#subscription-tests)).
+Some layer-3 subscriptions can still be straightforward and may not be worth
+testing.
+
+- Check the number of _inputs_ to the sub (from the graph). The higher this
+  number, the greater the chance the subscription can break if any of the
+  input's implementation changes.
+
+**Note**: if a tested subscription changes inadvertently, even if its own tests
+still pass, other subscriptions that depend on it and have tests may still fail.
+This is why we don't directly test the subscription handler, but instead, use
+the macro `test-helpers.unit/deftest-sub`.
+
+### When to unit-test events?
+
+A good hint is to ask if you and other CCs need to rely on re-frisk, UI, REPL,
+or FlowStorm to understand the event. If the answer is yes or probably, then a
+test would be prudent.
+
+- Many events only receive arguments and pass them along without much or any
+  transformation to an RPC call. These are straightforward and usually don't
+  need tests ([example](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/src/status_im/contexts/contact/blocking/events.cljs#L79-L85)).
+- Overall, every event basically returns two effects at most, `:fx` and/or
+  `:db`. Usually, the complicated part lies in the computation to return the new
+  app-db. If the event doesn't perform transformations in the app-db or just
+  does a trivial `assoc`, for example, it may not be worth testing.
+
+For reference, the re-frame author particularly [suggests testing events and
+subscriptions](https://github.com/day8/re-frame/blob/09e2d7132c479aa43f2a64164e54e42bf8511902/docs/Testing.md#what-to-test).
+
+### When to unit-test utility functions?
+
+Most utility functions in `status-mobile` are pure and can be readily and
+cheaply tested.
+
+- If the utility is used in an event/subscription and if the event/subscription
+  has tests, you may prefer to test the event/subscription and not the utility,
+  or the other way around sometimes.
+- If the utility is tricky to verify, such as functions manipulating time, write
+  tests ([example](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/src/utils/datetime.cljs#L1)).
+- Utilities can be particularly hard to verify by QAs because they can be lower
+  level and require very particular inputs. In such cases, consider writing
+  tests.
+
+### When to write integration/contract tests?
+
+- You want to make real calls to status-go because you think the unit tests are
+  not enough (test pyramid strategy).
+- You constantly need to retest the same things on the UI, sometimes over
+  multiple screens.
+- The flow is too important to rely only on manual QA, which can't always be
+  done due to resource limits, so an integration/contract test fills this gap.
+- You want to rely less on end-to-end tests, which can be more unreliable and
+  slower to change.
+- You want automatic verifications for some area of the mobile app whenever
+  status-go is upgraded.
+
+**Note**: the feedback cycle to write integration tests is longer than unit
+tests because they are slower and harder to debug. Using the REPL with them is
+difficult due to their stateful nature.
+
+### When to test Quo components?
+
+This is covered in [quo/README.md#component-tests](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/src/quo/README.md#component-tests).
@@ -0,0 +1,61 @@
+## What is Status Backend Server
+Status Backend Server is a http server that runs status-go, it exposed endpoints come from [mobile/status.go](https://github.com/status-im/status-go/blob/master/mobile/status.go) so that you can call them through http requests. It brings the following benefits:
+- When verifying changes made in status-go, you only need to run these commands once (unless modifying Kotlin/Objective-C code):
+  - `make clean && make run-clojure` 
+  - `make run-android` or `make run-ios`
+  This avoids repeatedly rebuilding and saves development time.
+- Debug status-go while running status mobile app
+
+## Solution to use Status Backend Server for mobile development
+`StatusBackendClient` is the entry point to use Status Backend Server. We need always to call `status-im.setup.status-backend-client/init` whether `STATUS_BACKEND_SERVER_ENABLED` is `1` or not. If it's not enabled, the invocation to functions in `native-module.core` will be delegated to built-in status-go library, otherwise it will be delegated to status-go running in status-backend server. Currently, all functions has usages in `native-module.core` should be supported delegated to. 
+NOTE: not all the native functions used `StatusBackendClient`, only the corresponding functions in `native-module.core` has usages should be supported delegated to ATM.
+
+related [PR](https://github.com/status-im/status-mobile/pull/21550)
+
+## Usage
+### Add environment variables to your local machine:
+```shell
+# enable using status backend server or not, otherwise it will use built-in status-go library
+export STATUS_BACKEND_SERVER_ENABLED=1
+
+#The host should contain an IP address and a port separated by a colon. 
+#The port comes from your running status backend server. 
+#If you run it by PORT=60000 make run-status-backend , then host will likely be 127.0.0.1:60000
+export STATUS_BACKEND_SERVER_HOST="127.0.0.1:60000" 
+
+export STATUS_BACKEND_SERVER_ROOT_DATA_DIR="/path/to/your/root/data/dir" 
+```
+You need to change `STATUS_BACKEND_SERVER_ROOT_DATA_DIR` to your preferred directory and ensure it exists, it should be in absolute path.
+All the db files and log files(requests.log/geth.log) and keystore files etc will be stored in this directory.
+
+### Start the status backend server:
+```shell
+PORT=60000 make run-status-backend
+```
+MAKE SURE the status-backend is checked out to a revision that's at least compatible with the revision in status-mobile/status-go-version.json before starting the server.
+
+For the Android simulator, you need to reverse the port:
+```shell
+adb reverse tcp:60000 tcp:60000
+```
+However, there is restriction when use adb reverse, we use random port for media server. So I'd suggest use "10.0.2.2:60000" as `STATUS_BACKEND_SERVER_HOST`.
+
+### Debug status-go using IDEA
+Assume you've already set up the development environment for status-go, open status-go project use IDEA, run `make generate` with terminal in the status-go project root directory to ensure all the generated files are up to date, then open `cmd/status-backend/main.go` file, navigate to function `main()`, click the green play button on the left of `main()`, choose `Modify Run Configuration`, in `Program arguments` section, add `--address=localhost:60000 --media-https=false`, then click `OK`, finally click the green play button on the left of `main()` again and choose `Debug ...`.
+Basically, you don't have to run `make generate` again and again, just run it once at the beginning. So you can re-run and debug it faster!
+
+## Known Android simulator issues
+- Issue#1: Android simulator may not display images due to TLS certificate validation issues with the image server
+  - solution: use http instead of https for media server with set env: `export STATUS_BACKEND_SERVER_MEDIA_SERVER_ENABLE_TLS=0`, you also need to set env variable `STATUS_BACKEND_SERVER_IMAGE_SERVER_URI_PREFIX` to "http://10.0.2.2:" so that `image_server.cljs` can work, and to make `/accountInitials` work, you need to copy `Inter-Medium.ttf` to your host machine from the android simulator, let's say you store it in `/Users/mac/Downloads/Inter-Medium.ttf`, then you need to update `get-font-file-ready` manually in `image_server.cljs` to return the correct path so that status backend server can access it.
+- Issue#2: exportUnencryptedDatabaseV2/import-multiaccount does not work for android, probably cause of tech debt, I found it during creating the draft PR.
+- Issue#3: unable to invoke `multiaccounts_storeIdentityImage` to change avatar image.
+  - The reason is that we path the absolute path of the image to the backend server, but the image file is stored in the android simulator. the backend server cannot access it as it runs in the host machine.
+
+If you're using ios simulator, you can skip above issues!
+
+## Details for issue#1 if you're interested
+- we use `react-native-fast-image` which use okhttpclient behind
+- we were using custom cert for https
+- we fetch the custom cert through endpoint `ImageServerTLSCert`
+- we fetched it through built-in status-go before, now we need to fetch it through status backend server
+- we expect `OkHttpClientProvider.setOkHttpClientFactory(StatusOkHttpClientFactory())` to be invoked early(will trigger fetching wrong custom cert via built-in status-go since StatusBackendClient is not initialised yet!) in `MainApplication.kt` before executing clojure code, otherwise we will get black screen after `make run-android` . After deep research, I found there's no way to update the cert okhttpclient used to the correct one return from status backend server
@@ -217,6 +217,7 @@ GEM

 PLATFORMS
  arm64-darwin-22
+  arm64-darwin-23
  x86_64-darwin-22

 DEPENDENCIES
@@ -0,0 +1,21 @@
+يجمع Status بين برنامج مراسلة مجهول الهوية يركز على الخصوصية ومحفظة العملات المشفرة الآمنة في أداة اتصال قوية واحدة. يمكنك الدردشة مع الأصدقاء والمجتمعات المتنامية. وشراء وتخزين وتبادل الأصول الرقمية.
+
+Status هو نظام تشغيل Ethereum الخاص بك.
+
+محفظة Ethereum آمنة
+تتيح لك محفظة العملات المشفرة Status إرسال وتخزين وتبادل أصول Ethereum بأمان مثل ETH وSNT والعملات المستقرة مثل DAI، بالإضافة إلى المقتنيات. تحكم بثقة في عملاتك المشفرة والأصول الرقمية من خلال تطبيق محفظة Ethereum متعددة السلاسل، والذي يدعم الشبكة الرئيسية وArbitrum وOptimism. تدعم محفظة blockchain Status حاليًا أصول ETH وERC-20 وERC-721 وERC-1155 فقط؛ ولا تدعم Bitcoin.
+
+PRIVATE MESSENGER
+أرسل محادثات فردية وجماعية خاصة دون أن يتجسس أحد على اتصالاتك. Status هو تطبيق مراسلة يلغي عمليات نقل الرسائل المركزية لمزيد من الخصوصية والمراسلة الآمنة. يتم تشفير جميع الرسائل باستخدام تشفير من البداية إلى النهاية. بالإضافة إلى ذلك، لا تكشف أي رسالة عن هوية المؤلف أو المستلم المقصود، لذلك لا أحد، ولا حتى Status، يعرف من يتحدث إلى من أو ما قيل.
+
+اربح مع DEFI
+
+استخدم عملتك المشفرة مع أحدث تطبيقات التمويل اللامركزية والبورصات اللامركزية (DEX) مثل Maker وAave وUniswap وSynthetix وPoolTogether وZerion وKyber والمزيد.
+
+تواصل مع مجتمعك
+
+استكشف مجتمعاتك وأصدقائك المفضلين وتواصل معهم ودردش معهم. سواء كانت مجموعة صغيرة من الأصدقاء أو مجموعة فنانين أو تجار عملات مشفرة أو منظمة كبيرة قادمة - أرسل رسائل نصية وتواصل مع مجتمعات Status.
+
+إنشاء حساب خاص
+
+ابق خاصًا من خلال إنشاء حساب مجهول الهوية. عند إنشاء حسابك المجاني، لن تضطر أبدًا إلى إدخال رقم هاتف أو عنوان بريد إلكتروني أو حساب مصرفي. يتم إنشاء مفاتيح المحفظة الخاصة بك محليًا وتخزينها بشكل آمن لضمان حصولك أنت فقط على حق الوصول إلى أموالك ومعاملاتك المالية.
@@ -0,0 +1 @@
+ربط Private Finance وWeb3
@@ -0,0 +1 @@
+Status: محفظة تشفير اجتماعية
@@ -1,26 +0,0 @@
-
-يجمع Status بين برنامج المراسلة الخاص ومحفظة التشفير الآمنة ومتصفح لتطبيقات إيثريوم اللامركزية  في أداة اتصال واحدة قوية. الدردشة مع الأصدقاء والمجتمعات المتزايدة. شراء الأصول الرقمية وبيعها وتخزينها وتبادلها. تصفح الإنترنت اللامركزي دون استغلال بياناتك.
-Status هو نظام تشغيل إيثريوم الخاص بك
-برنامج المراسلة الخاص
-أرسل دردشات خاصة 1: 1 ، ومجموعات خاصة ، ودردشات عامة دون وسطاء غير ضروريين في اتصالاتك. Status عبارة عن تطبيق نصي يزيل نقاط الاختناق المركزية من رسائلك يمنحك لمزيد من الخصوصية والمراسلة الآمنة. تطبيق مراسلة مشفر مع تشفير شامل وخصوصية بشكل افتراضي بحيث لا يمكن لأي شخص آخر غيرك والمرسل إليه استعراض رسائلك - ولا حتى Status. يعتبره البعض برنامج مراسلات سريًه. 
-
-مدفوعات بلا حدود، من النظير إلى النظير 
-يتيح ماسنجر Status لأي شخص في أي مكان إرسال مدفوعات عالمية مباشرة في الدردشة حيث انه متكامل بسلاسة مع محفظة العملات المشفرة.
-
-محفظة إيثريوم آمنة
-تتيح لك محفظة تشفير Status إرسال أصول إيثريوم وتخزينها وتداولها وتبادلها بأمان مثل ETH و SNT والعملات المستقرة القيمة مثل DAI و NFTs. يمكنك التحكم بكل ثقة في عملتك المشفرة والأصول الرقمية باستخدام تطبيق محفظة إيثريوم هذه . تدعم محفظة البلوكتشين الخاصة Status حاليًا أصول ERC-20 و ERC-721 فقط ؛ لا تدعم البيتكوين.
-اكسب مع DEFI
-دع عملاتك المشفرة تعمل مع أحدث تطبيقات التمويل اللامركزية والتبادلات اللامركزية (DEX) مثل Maker و Aave و Uniswap و Synthetix و PoolTogether و Zerion و Kyber وغيرهم الكثير.
-
-متصفح تطبيقات الويب 3 اللامركزية
-تصفح الويب الآمن وأدنو من النظام الإيكولوجي المتنامي للتطبيقات اللامركزية باستخدام المتصفح الآمن. يتيح Status الوصول إلى أكثر من مجرد DeFi - اكتشف أحدث الأسواق والمقتنيات والألعاب والشبكات الاجتماعية مثل SuperRare و Gitcoin و Dragonereum و Axie Infinity و Open Sea و CryptoKitties و Decentraland وغيرهم الكثير.
-
-
-تواصل مع مجتمعك
-استكشف وتواصل ودردش مع مجتمعاتك و أصدقائك المفضلين لديك. سواء كانت مجموعة صغيرة من الأصدقاء ، أو مجموعة فنانين ، أو تجار تشفير ، أو المؤسسة الكبيرة التالية - أرسل رسائل نصية وتواصل مع مجتمعات Status.
-
-بثّ اﻷنشطة اﻹجتماعية 
-شارك ما يدور في ذهنك وانشر التحديثات مع جهات الاتصال الخاصة بك في شبكة تواصل اجتماعية لامركزية حديثة ومقاومة للرقابة.
-
-إنشاء حساب خاص
-حافظ على خصوصيتك مع إنشاء حساب مستعار. عند إنشاء حسابك المجاني ، لن تضطر أبدًا إلى إدخال رقم هاتف أو عنوان بريد إلكتروني أو حساب مصرفي. يتم إنشاء المفاتيح الخاصة بالمحفظة الخاصة بك وتخزينها على جهازك لضمان وصولك إلى أموالك ومعاملاتك المالية فقط.
--- a/Show More
+++ b/Show More
@@ -1 +1 @@
 .29.0
 .30.0
				`@@ -0,0 +1 @@`
				`Status: محفظة تشفير اجتماعية`