Problem: wrong documentation links

Solution: fixed documentation links to direct to Thaler docs

README.md

@@ -54,7 +54,7 @@ and the [contributing guidelines](CONTRIBUTING.md) when submitting code.
 
 ## 4. Documentation
 
-Technical documentation can be found in this [Github repository](https://github.com/crypto-com/chain-docs) (you can read it in [this hosted version](https://crypto-com.github.io)).
+Technical documentation can be found in this [Github repository](https://github.com/crypto-com/thaler-docs) (you can read it in [this hosted version](https://thaler-testnet.crypto.com/docs/getting-started/).
 
 <a id="build" />
 
@@ -149,13 +149,13 @@ TODO
 
 ## 6. Start a Local Full Node
 
-Please follow the [instruction](https://crypto-com.github.io/getting-started/local_full_node_development.html) to deploy a local full node.
+Please follow the [instruction](https://thaler-testnet.crypto.com/docs/getting-started/local-devnet.html) to deploy a local full node.
 
 <a id="send-first-transaction" />
 
 ## 7. Send Your First Transaction
 
-Kindly refer to this [instruction](https://crypto-com.github.io/getting-started/send_your_first_transaction.html#send-your-first-transaction) to perform transactions between addresses.
+Kindly refer to this [instruction](https://thaler-testnet.crypto.com/docs/getting-started/local-devnet.html#send-your-first-transaction) to perform transactions between addresses.
 
 <a id="testing" />
 
@@ -175,15 +175,15 @@ $ drone exec --trusted \
     --include multinode-tests
 ```
 
-Kindly refer to [Prepare SPID & KEY](https://crypto-com.github.io/getting-started/#prepare-spid-key) to obtain the values of `SPID` and `IAS_API_KEY`. 
+Kindly refer to [Prepare SPID & KEY](https://thaler-testnet.crypto.com/docs/getting-started/local-devnet.html#prepare-spid-key) to obtain the values of `SPID` and `IAS_API_KEY`. 
 
 ---
 
 <a id="useful-links" />
 
 ## 9. Useful links
 
-* [Project Website](http://crypto.com/chain)
-* [Technical Documentation](https://crypto-com.github.io)
+* [Project Website](https://thaler-testnet.crypto.com/)
+* [Technical Documentation](https://thaler-testnet.crypto.com/docs/)
 * Community chatrooms (non-technical): [Discord](https://discord.gg/nsp9JTC) [Telegram](https://t.me/CryptoComOfficial)
 * Developer community chatroom (technical): [![Gitter](https://badges.gitter.im/crypto-com/community.svg)](https://gitter.im/crypto-com/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)

architecture-docs/adr-001.md

@@ -28,7 +28,7 @@ stores the latest app hash provided by chain-abci; and upon a startup, chain-abc
 *Problem 2: Transaction querying*:
 
 As wallet / client-* may be lightweight client and not have access to TEE directly, it will connect to one remotely.
-For this purpose, there is transaction query enclave (TQE). See [this document](https://github.com/crypto-com/chain-docs/blob/master/plan.md#transaction-query-enclave-tqe-optional--for-client-infrastructure) for more details.
+For this purpose, there is transaction query enclave (TQE). See [this document](https://github.com/crypto-com/thaler-docs/blob/master/plan.md#transaction-query-enclave-tqe-optional--for-client-infrastructure) for more details.
 
 There are two flows (over an attested secure channel):
 

architecture-docs/adr-002.md

@@ -37,8 +37,7 @@ The code will be progressively moved to EDP across different PRs:
 * attestation proxy that forwards requests between enclave code and IAS or DCAP
 * runner with zMQ to replace tx-query: the usercall extension will bridge the zMQ connection requests and replies
 * other implementation work: "transaction bootstrapping enclave" (TDBE) work may begin with enclave-to-enclave connections leveraging the above
-(note tx-validation will need a TLS connection to be pushed the obfuscation keys from TDBE
- https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md#tdbe-handling--generation)
+(note tx-validation will need a TLS connection to be pushed the obfuscation keys from [TDBE](https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md#tdbe-handling--generation)
 * port tx-validation: add a runner to chain-abci that will load tx-validation's sgxs and relay the the requests
 * put the edp enclave crates in standalone directory `chain-tx-enclave-next`, to prevent conflicts with some hacks for old enclave
   codes.

chain-core/src/mls/mod.rs

@@ -55,7 +55,7 @@ impl From<NackMsgTx> for TaggedTransaction {
 
 /// A wrapper type for payloads generated and exchanged
 /// by a part of "Transaction Data Bootstrapping Enclave" (TDBE)
-/// ref: https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md
+/// ref: https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md
 /// TODO: currently, Vec<u8> payloads are assumed to be TLS encoded,
 /// but this may switch to SCALE
 #[derive(Debug, PartialEq, Eq, Clone, Encode, Decode)]

chain-tx-enclave-next/enclave-ra/ra-client/src/verifier.rs

@@ -254,7 +254,7 @@ impl EnclaveCertVerifier {
                 return Err(EnclaveCertVerifierError::MeasurementMismatch);
             }
 
-            // SVN verification: https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md#svn-verification--compilation-order
+            // SVN verification: https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md#svn-verification--compilation-order
             match (
                 enclave_info.isv_svn,
                 enclave_info.mr_enclave,

chain-tx-enclave-next/mls/src/extras/mod.rs

@@ -1,6 +1,6 @@
 ///! This module contains additional parts that are a part of the MLS draft spec,
 ///! but are required for resolving relevant open issues in the draft spec
-///! or for extra conventions / operations: https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md.
+///! or for extra conventions / operations: https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md.
 ///!
 ///! At the moment, one issue is that the node generating Commit/Welcome
 ///! may put "bogus" in the ciphertext, which will block nodes (newly joining or on the affected
@@ -119,7 +119,7 @@ impl NackMsg {
         // if there's no ancestor, this would be meaningless -- committer sending NACK for its own commit?
         let ancestor = ParentSize::common_ancestor(commit_sender, nack_sender)
             .ok_or(NackError::InvalidCommit)?;
-        // incomplete paths are expected to be checked: https://github.com/crypto-com/chain-docs/issues/190 https://github.com/crypto-com/chain-docs/issues/189
+        // incomplete paths are expected to be checked: https://github.com/crypto-com/thaler-docs/issues/190 https://github.com/crypto-com/thaler-docs/issues/189
         let path_node = NodeSize::from(commit_sender)
             .direct_path(leaf_len)
             .into_iter()

chain-tx-enclave-next/mls/src/extras/validation.rs

@@ -5,7 +5,7 @@ use crate::message::MLSPlaintext;
 use crate::Codec;
 use ra_client::{CertVerifyResult, ENCLAVE_CERT_VERIFIER};
 
-/// FIXME: needs design/spec https://github.com/crypto-com/chain-docs/issues/141
+/// FIXME: needs design/spec https://github.com/crypto-com/thaler-docs/issues/141
 /// of possible errors
 #[derive(thiserror::Error, Debug)]
 pub enum NodeJoinError {
@@ -15,13 +15,13 @@ pub enum NodeJoinError {
     VerifyError(#[from] KeyPackageError),
 }
 
-/// FIXME: needs design/spec https://github.com/crypto-com/chain-docs/issues/141
+/// FIXME: needs design/spec https://github.com/crypto-com/thaler-docs/issues/141
 /// of what needs to be returned
 pub struct NodeJoinResult {
     pub info: CertVerifyResult,
 }
 
-/// FIXME: needs design/spec https://github.com/crypto-com/chain-docs/issues/141
+/// FIXME: needs design/spec https://github.com/crypto-com/thaler-docs/issues/141
 /// this may need to be passed in more arguments, e.g. groupcontext or whatever the chain-abci
 /// can maintain
 pub fn check_nodejoin<CS: CipherSuite>(

chain-tx-enclave-next/mls/src/lib.rs

@@ -1,6 +1,6 @@
 //! This crate implements [mls protocol](https://github.com/mlswg/mls-protocol/blob/1d5e14d79435834bc5cab6c7aa9e2fcdd6afeabc/draft-ietf-mls-protocol.md)
 //! Note: "Application Secret Tree" is not implemented here, as it's not being used in the latest
-//! TDBE iteration: https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md#new-obfuscation-key
+//! TDBE iteration: https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md#new-obfuscation-key
 //! (i.e. instead of exchanging application messages, only node tree ratcheting + secret derivations are used,
 //! as the obfuscation key for transactions is obtained directly using the MLS "exporter" construct that didn't exist in the earlier protocol drafts)
 

chain-tx-enclave-next/tdbe/enclave-app/src/sgx_module.rs

@@ -115,7 +115,7 @@ pub fn entry() -> std::io::Result<()> {
         let tve_uds = TcpStream::connect("tx-validation")?;
         let mut tve_stream = create_tls_server_stream(&context, tve_verifier, tve_uds, false)?;
 
-        /// FIXME: this should be generated using "MLS-Exporter": https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md#new-obfuscation-key
+        /// FIXME: this should be generated using "MLS-Exporter": https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md#new-obfuscation-key
         const MOCK_KEY: [u8; 16] = mock_key!();
         tve_stream.write_all(&MOCK_KEY);
     }
@@ -203,7 +203,7 @@ fn fetch_remote_tdbe_connection_details(
     Ok(("".to_string(), "".to_string()))
 }
 
-// TODO: Get transaction IDs as mentioned in https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md#light-client
+// TODO: Get transaction IDs as mentioned in https://github.com/crypto-com/thaler-docs/blob/master/docs/modules/tdbe.md#light-client
 fn fetch_transaction_ids() -> (Vec<TxId>, u32) {
     Default::default()
 }