diff --git a/docs/_1_ecosystem/2_example-tea-in-use.md b/docs/_1_ecosystem/2_example-tea-in-use.md index 2c50662..8db0542 100644 --- a/docs/_1_ecosystem/2_example-tea-in-use.md +++ b/docs/_1_ecosystem/2_example-tea-in-use.md @@ -8,7 +8,7 @@ However, due to the lack of a central server, financial transactions between inv If we consider blockchain as layer-1, the TEA project as the layer-2 on blockchain, we may call the payment channel as layer-3. -[ TEA Party](../_5_tapps/TApp-TEA-Party.md) is the example app to demonstrate this feature. +[ TEA Party](../_2_user_manual/_8_Tea%20Party.md) is the example app to demonstrate this feature. TEA Party allows a host(who create a video chat room, such as a teacher in classroom), get **paid per minute** by the guests(who are invited by the host via a shared URL link, such as students). There is no central server between host and guests. No matter how long the video chat does, there will be only two (or maybe three) payment transactions sent to the TEA Project network at the beginning and ending. Every minute (depending on cost structure set by the host) both host and guests exchange signed payment confirmation messages through the peer to peer network directly. The payment channel algorithm protect both sides from irresponsible behavior or incidentally network disconnection. diff --git a/docs/_1_ecosystem/4_tea-technical-details.md b/docs/_1_ecosystem/4_tea-technical-details.md index 3dd4b4a..990eaa7 100644 --- a/docs/_1_ecosystem/4_tea-technical-details.md +++ b/docs/_1_ecosystem/4_tea-technical-details.md @@ -49,7 +49,7 @@ We aim to establish the TEA Project as the preferred development platform for de ### Peer to peer application architecture -Besides typical three-tier applications, peer-to-peer applications are popular in the Web3 world. These applications are designed to be fully self-contained, which means almost all logic runs inside the client as a so-called "protocol". Therefore, they involve very little or zero server-side support. TEA Project fully supports this type of new Web3-oriented application architecture. TEA Project has integrated the **payment channel** protocol, which is similar to BTC's **Lightning Network**. Use WebRTC-based [TEA Party example](../_5_tapps/TApp-TEA-Party.md) as an example, the only two server-involved places the host peer or guests' peers are 1. signaling (peers discovery) 2. payment channel setup & settlement. All the video/audio data is transferred between the host peer and guests' peers directly. In case the TEA Party hosting node is accidentally down during the call, none of the peers will notice, and their payment won't be affected. +Besides typical three-tier applications, peer-to-peer applications are popular in the Web3 world. These applications are designed to be fully self-contained, which means almost all logic runs inside the client as a so-called "protocol". Therefore, they involve very little or zero server-side support. TEA Project fully supports this type of new Web3-oriented application architecture. TEA Project has integrated the **payment channel** protocol, which is similar to BTC's **Lightning Network**. Use WebRTC-based [TEA Party](../_2_user_manual/_8_Tea%20Party.md) as an example, the only two server-involved places the host peer or guests' peers are 1. signaling (peers discovery) 2. payment channel setup & settlement. All the video/audio data is transferred between the host peer and guests' peers directly. In case the TEA Party hosting node is accidentally down during the call, none of the peers will notice, and their payment won't be affected. ### Realtime collaborative application architecture diff --git a/docs/_5_tapps/README.md b/docs/_5_tapps/README.md index f83990d..d92c198 100644 --- a/docs/_5_tapps/README.md +++ b/docs/_5_tapps/README.md @@ -7,7 +7,7 @@ From the end-users perspective, two steps are needed before deploying any TApp f 1. A spending limit for the TApp must be set. This ensures that a TApp can't spend more than what you've allocated for that TApp. As money is spent in the TApp, the spending limit is reduced. In this way it functions like an allowance that can be spent, with the end-user able to bump it up at any time. 1. A node must be selected to run the TApp. Because of TEA's architecture, TApps are "hosted" in IPFS waiting for deployment. Because IPFS is just storage, the node that the end-user requests will download the compiled TApp binary from IPFS and execute in the node together with any data that the end-user provides. -The list of available TApps is available through the [TEA Browser Wallet](TEA-Browser-Wallet.md). +The list of available TApps is available through the [TAppStore](../_2_user_manual/_1_TAppStore_1_tapps.md). Developers interested in coding and deploying their own TApps can reference the following resources: @@ -16,10 +16,3 @@ Developers interested in coding and deploying their own TApps can reference the * [TEA-Billing](TEA-Billing.md) is the base document with information and related links for understanding TEA's billing system. You can learn more about other concepts involved with TApps by visiting the [TApps FAQ](FAQ-TApps.md). - -## More Info on Specific TApps - -There's a [core set of TApps](TApps-Core.md) that are maintained by the team. These include - -* [The TEA Party TApp](TApp-TEA-Party.md). TEA Party is a social messaging app that's also useful for developers to study and learn from. -* [The TEA Influencer TApp](TEAfluencer.md). TEAfluencer is a TApp template that can be used by any influencer to create their own faucet for the TEA ecosystem. diff --git a/docs/_5_tapps/TApp-TEA-Party.md b/docs/_5_tapps/TApp-TEA-Party.md deleted file mode 100644 index cb15b34..0000000 --- a/docs/_5_tapps/TApp-TEA-Party.md +++ /dev/null @@ -1,62 +0,0 @@ -# TEA Party - -The TEA Party is a social messaging TApp that allows users to message each other. The TEA Party is also a template that TApp developers can use to host their own messaging app. Every instance of a TApp using this template is called a **TEA Table**. The TEA Project team hosts a TEA Table known as the **Help Desk** where contestants can ask questions. - -Screen Shot 2021-11-20 at 10 50 03 AM - -From the image above, you can see what the TEA Party interface looks like. - -* Users log in and can post messages which costs a certain amount of TEA. -* There is an expiration date printed next to each message. Users can pay extra to bump their message and extend the duration of the message. -* There is also a red delete icon to remove any message that the user themselves have posted. - -## Why is TEA Party a typical Web3 application? - -Before we get into this question, please first read [more about what makes_a_web3_application](070_What_makes_a_Web3_application.md). - -Web3 applications are different than web 2.0 applications in multiple ways: - -* No centralized hosting services. -* No centralized database. -* No centralized authority (censorship). -* Tokenomics driven. - -## No centralized hosting - -When you start the TEA party, you'll probably notice that it's different than a regular web 2.0 application. You're not going to a domain name such as `teaparty.com`. Instead, you're given several URLs with different IP addresses such as in the screen shot below. - -![urls](https://user-images.githubusercontent.com/1761809/160294873-a61c21b8-e8ee-4cbf-bc41-05ae097a47bb.png) - -You'll notice that the IP addresses are different, but the rest of the URLs are identical. The part that's the same correlates to the IPFS CID of the current version of the TEA Party [front end](../z_glossary/front_end.md). The IP addresses are the IPs of the [hosting CML](../z_glossary/hosting_cml.md). In the screenshot above, you'll notice how there are three TEA mining machined (with [hosting CML](../z_glossary/hosting_cml.md) planted) currently hosting this TEA Party application. - -There's no **"domain name" or "server"** involved with TApps. As you can see, anyone (including yourself) can become a host and earn the TApp hosting fee. There's no centralized server involved with deploying a TApp. On the other word, if some super power does not like this application, there's no way for them to take this application offline. TApps say bye bye to cloud server hosting and instead utilize the TEA Project's decentralized hosting node architecture. - -## No censorship - -The code and data are running inside a hardware protected [enclave](../z_glossary/enclave.md). No one (including the developers and the hosting miners) can see what's actually inside. Therefore, there's no way for anyone to censor TApps. If any individual miner does not like a particular TApp, he can stop hosting it. But as long as other miners are willing to host that TApp, then it's still accessible and its content is readily available. - -## No centralized database - -Not only is the hosting of TApps fully decentralized, the database is also fully decentralized as well. The database layer is probably not something you can see from the front end. But if you read the full developer documentation, you'll understand how the [state machine](../z_glossary/state_machine.md) and [orbitdb](../z_glossary/orbitdb.md) work together to store the application data. - -## Tokenomics driven - -In web 2.0, end users sell their privacy to the tech giants in return for "free" application services. In Web3, because there's no centralized "operator" to steal your privacy for profit, there won't be any free lunch provided by the applications. Someone has to pay for the service as the miners and developers need to make a living. Some coming from the web 2.0 world might think this is bad, but this is actually how things should work. Because all the API call to the [public service](../z_glossary/public_service.md) need to be paid, all storage will need either RAM or hard drive space. These computing costs are eventually paid by end users. In a TApp like the TEA Party, users can see the price of posting message or sending private notifications. - -Screen Shot 2022-03-27 at 10 00 05 PM - -There might be some new business model that end users can earn "free" services in exchange of some work or data. We'll continue trying these models in future versions of the TEA Party. - -## How to Use TEA Party - -Users can consult the [TEA Party user guide](https://teaproject.medium.com/tea-party-tapp-epoch-9-users-guide-2bd8ddd87daa) published during Epoch 9, (March, 2022). - -## TEA Party TApps Earn Tips - -During the mining contest epochs, TEA Party-based TApps will earn tips every 1000 blocks during contest rounds. The amount of the consume action is as follows: - -* 10T per message. -* Maximum tip of 1000T per 1000 blocks. -* A minimum of 1T is tipped out every 1000 blocks (in case there are no messages during that block time). - -Keep in mind that this amount of TEA tipped out is used to buy the TApp's tokens which is then distributed proportionally to token holders and miners. diff --git a/docs/_5_tapps/TEA-Browser-Wallet.md b/docs/_5_tapps/TEA-Browser-Wallet.md deleted file mode 100644 index 56e63a0..0000000 --- a/docs/_5_tapps/TEA-Browser-Wallet.md +++ /dev/null @@ -1,31 +0,0 @@ -# TEA Browser Wallet - -The **TEA Browser Wallet** is the main portal through which users will access the TEA Project network of TApps. In addition to the list of TApps, endusers can sign-in to the browser wallet to transact investment tokens as well as top-up funds to TEA's layer-2 (as well as withdraw back to Ethereum). - -There are 2 options for running the TEA browser wallet: - -1. **Remote.** You can access the remotely hosted wallet client at [wallet.teaproject.org](https://wallet.teaproject.org). - -1. **Local.** The TEA Project is decentralized, allowing you to run the browser wallet locally on your machine without the aid of any central servers. - -* To get started, you should first have Node.js installed on your computer. The [official repo](https://nodejs.org/en/download/) should be sufficient for most users, though [Linux](https://nodejs.org/en/download/package-manager/), [Windows](https://github.com/coreybutler/nvm-windows), and [Mac](https://formulae.brew.sh/formula/node) users can also install Node using a package manager. Just make sure that the Node version installed is greater than 14. - -* Visit https://github.com/tearust/tea-browser-wallet/ and download the repo: - -![](https://github.com/tearust/tea-docs/blob/main/res/Try_the_demo/Try_the_demo-Tea-Browser-Wallet-download.png) - -Unpack the zip archive. - -* Start the browser wallet. From your command line terminal, run the following two commands when in the downloaded **tea-browser-wallet-master** folder : - -`npm i` - -`npm start` - -![](https://github.com/tearust/tea-docs/blob/main/res/Try_the_demo/Try_the_demo-node_start.png) - -* You should now to be able to access the browser wallet using localhost with the given port in your web browser: - -![](https://github.com/tearust/tea-docs/blob/main/res/Try_the_demo/Try_the_demo-wallet-localhost.png) - -You can use either [localhost:3000](http://localhost:3000) or [127.0.0.1:3000](http://127.0.0.1:3000) diff --git a/obsidian/_1_ecosystem/2_example-tea-in-use.md b/obsidian/_1_ecosystem/2_example-tea-in-use.md index d4b3544..d9f55af 100644 --- a/obsidian/_1_ecosystem/2_example-tea-in-use.md +++ b/obsidian/_1_ecosystem/2_example-tea-in-use.md @@ -8,7 +8,7 @@ However, due to the lack of a central server, financial transactions between inv If we consider blockchain as layer-1, the TEA project as the layer-2 on blockchain, we may call the payment channel as layer-3. -[[TApp-TEA-Party| TEA Party]] is the example app to demonstrate this feature. +[[_8_Tea Party| TEA Party]] is the example app to demonstrate this feature. TEA Party allows a host(who create a video chat room, such as a teacher in classroom), get **paid per minute** by the guests(who are invited by the host via a shared URL link, such as students). There is no central server between host and guests. No matter how long the video chat does, there will be only two (or maybe three) payment transactions sent to the TEA Project network at the beginning and ending. Every minute (depending on cost structure set by the host) both host and guests exchange signed payment confirmation messages through the peer to peer network directly. The payment channel algorithm protect both sides from irresponsible behavior or incidentally network disconnection. diff --git a/obsidian/_1_ecosystem/4_tea-technical-details.md b/obsidian/_1_ecosystem/4_tea-technical-details.md index 8438f9a..7c4618d 100644 --- a/obsidian/_1_ecosystem/4_tea-technical-details.md +++ b/obsidian/_1_ecosystem/4_tea-technical-details.md @@ -50,7 +50,7 @@ We aim to establish the TEA Project as the preferred development platform for de ### Peer to peer application architecture -Besides typical three-tier applications, peer-to-peer applications are popular in the Web3 world. These applications are designed to be fully self-contained, which means almost all logic runs inside the client as a so-called "protocol". Therefore, they involve very little or zero server-side support. TEA Project fully supports this type of new Web3-oriented application architecture. TEA Project has integrated the **payment channel** protocol, which is similar to BTC's **Lightning Network**. Use WebRTC-based [[TApp-TEA-Party|TEA Party example]] as an example, the only two server-involved places the host peer or guests' peers are 1. signaling (peers discovery) 2. payment channel setup & settlement. All the video/audio data is transferred between the host peer and guests' peers directly. In case the TEA Party hosting node is accidentally down during the call, none of the peers will notice, and their payment won't be affected. +Besides typical three-tier applications, peer-to-peer applications are popular in the Web3 world. These applications are designed to be fully self-contained, which means almost all logic runs inside the client as a so-called "protocol". Therefore, they involve very little or zero server-side support. TEA Project fully supports this type of new Web3-oriented application architecture. TEA Project has integrated the **payment channel** protocol, which is similar to BTC's **Lightning Network**. Use WebRTC-based [[_8_Tea Party|TEA Party]] as an example, the only two server-involved places the host peer or guests' peers are 1. signaling (peers discovery) 2. payment channel setup & settlement. All the video/audio data is transferred between the host peer and guests' peers directly. In case the TEA Party hosting node is accidentally down during the call, none of the peers will notice, and their payment won't be affected. ### Realtime collaborative application architecture diff --git a/obsidian/_5_tapps/README.md b/obsidian/_5_tapps/README.md index 128c9ab..cde81c0 100644 --- a/obsidian/_5_tapps/README.md +++ b/obsidian/_5_tapps/README.md @@ -7,7 +7,7 @@ From the end-users perspective, two steps are needed before deploying any TApp f 1. A spending limit for the TApp must be set. This ensures that a TApp can't spend more than what you've allocated for that TApp. As money is spent in the TApp, the spending limit is reduced. In this way it functions like an allowance that can be spent, with the end-user able to bump it up at any time. 2. A node must be selected to run the TApp. Because of TEA's architecture, TApps are "hosted" in IPFS waiting for deployment. Because IPFS is just storage, the node that the end-user requests will download the compiled TApp binary from IPFS and execute in the node together with any data that the end-user provides. -The list of available TApps is available through the [TEA Browser Wallet](TEA-Browser-Wallet.md). +The list of available TApps is available through the [[_1_TAppStore_1_tapps|TAppStore]]. Developers interested in coding and deploying their own TApps can reference the following resources: @@ -17,9 +17,3 @@ Developers interested in coding and deploying their own TApps can reference the You can learn more about other concepts involved with TApps by visiting the [TApps FAQ](FAQ-TApps.md). -## More Info on Specific TApps -There's a [core set of TApps](TApps-Core.md) that are maintained by the team. These include - -- [The TEA Party TApp](TApp-TEA-Party.md). TEA Party is a social messaging app that's also useful for developers to study and learn from. -- [The TEA Influencer TApp](TEAfluencer.md). TEAfluencer is a TApp template that can be used by any influencer to create their own faucet for the TEA ecosystem. - diff --git a/obsidian/_5_tapps/TApp-TEA-Party.md b/obsidian/_5_tapps/TApp-TEA-Party.md deleted file mode 100644 index 4f27fb9..0000000 --- a/obsidian/_5_tapps/TApp-TEA-Party.md +++ /dev/null @@ -1,55 +0,0 @@ -# TEA Party -The TEA Party is a social messaging TApp that allows users to message each other. The TEA Party is also a template that TApp developers can use to host their own messaging app. Every instance of a TApp using this template is called a **TEA Table**. The TEA Project team hosts a TEA Table known as the **Help Desk** where contestants can ask questions. - -Screen Shot 2021-11-20 at 10 50 03 AM - -From the image above, you can see what the TEA Party interface looks like. - -- Users log in and can post messages which costs a certain amount of TEA. -- There is an expiration date printed next to each message. Users can pay extra to bump their message and extend the duration of the message. -- There is also a red delete icon to remove any message that the user themselves have posted. - -## Why is TEA Party a typical Web3 application? -Before we get into this question, please first read [more about what makes_a_web3_application](070_What_makes_a_Web3_application.md). - -Web3 applications are different than web 2.0 applications in multiple ways: - -- No centralized hosting services. -- No centralized database. -- No centralized authority (censorship). -- Tokenomics driven. - -## No centralized hosting -When you start the TEA party, you'll probably notice that it's different than a regular web 2.0 application. You're not going to a domain name such as `teaparty.com`. Instead, you're given several URLs with different IP addresses such as in the screen shot below. - -![urls](https://user-images.githubusercontent.com/1761809/160294873-a61c21b8-e8ee-4cbf-bc41-05ae097a47bb.png) - -You'll notice that the IP addresses are different, but the rest of the URLs are identical. The part that's the same correlates to the IPFS CID of the current version of the TEA Party [front end](../z_glossary/front_end.md). The IP addresses are the IPs of the [hosting CML](../z_glossary/hosting_cml.md). In the screenshot above, you'll notice how there are three TEA mining machined (with [hosting CML](../z_glossary/hosting_cml.md) planted) currently hosting this TEA Party application. - -There's no **"domain name" or "server"** involved with TApps. As you can see, anyone (including yourself) can become a host and earn the TApp hosting fee. There's no centralized server involved with deploying a TApp. On the other word, if some super power does not like this application, there's no way for them to take this application offline. TApps say bye bye to cloud server hosting and instead utilize the TEA Project's decentralized hosting node architecture. - -## No censorship - -The code and data are running inside a hardware protected [enclave](../z_glossary/enclave.md). No one (including the developers and the hosting miners) can see what's actually inside. Therefore, there's no way for anyone to censor TApps. If any individual miner does not like a particular TApp, he can stop hosting it. But as long as other miners are willing to host that TApp, then it's still accessible and its content is readily available. - -## No centralized database -Not only is the hosting of TApps fully decentralized, the database is also fully decentralized as well. The database layer is probably not something you can see from the front end. But if you read the full developer documentation, you'll understand how the [state machine](../z_glossary/state_machine.md) and [orbitdb](../z_glossary/orbitdb.md) work together to store the application data. - -## Tokenomics driven -In web 2.0, end users sell their privacy to the tech giants in return for "free" application services. In Web3, because there's no centralized "operator" to steal your privacy for profit, there won't be any free lunch provided by the applications. Someone has to pay for the service as the miners and developers need to make a living. Some coming from the web 2.0 world might think this is bad, but this is actually how things should work. Because all the API call to the [public service](../z_glossary/public_service.md) need to be paid, all storage will need either RAM or hard drive space. These computing costs are eventually paid by end users. In a TApp like the TEA Party, users can see the price of posting message or sending private notifications. - -Screen Shot 2022-03-27 at 10 00 05 PM - -There might be some new business model that end users can earn "free" services in exchange of some work or data. We'll continue trying these models in future versions of the TEA Party. - -## How to Use TEA Party -Users can consult the [TEA Party user guide](https://teaproject.medium.com/tea-party-tapp-epoch-9-users-guide-2bd8ddd87daa) published during Epoch 9, (March, 2022). - -## TEA Party TApps Earn Tips -During the mining contest epochs, TEA Party-based TApps will earn tips every 1000 blocks during contest rounds. The amount of the consume action is as follows: - -- 10T per message. -- Maximum tip of 1000T per 1000 blocks. -- A minimum of 1T is tipped out every 1000 blocks (in case there are no messages during that block time). - -Keep in mind that this amount of TEA tipped out is used to buy the TApp's tokens which is then distributed proportionally to token holders and miners. \ No newline at end of file diff --git a/obsidian/_5_tapps/TEA-Browser-Wallet.md b/obsidian/_5_tapps/TEA-Browser-Wallet.md deleted file mode 100644 index faee5c3..0000000 --- a/obsidian/_5_tapps/TEA-Browser-Wallet.md +++ /dev/null @@ -1,30 +0,0 @@ -# TEA Browser Wallet -The **TEA Browser Wallet** is the main portal through which users will access the TEA Project network of TApps. In addition to the list of TApps, endusers can sign-in to the browser wallet to transact investment tokens as well as top-up funds to TEA's layer-2 (as well as withdraw back to Ethereum). - -There are 2 options for running the TEA browser wallet: - -1. **Remote.** You can access the remotely hosted wallet client at [wallet.teaproject.org](https://wallet.teaproject.org). - -2. **Local.** The TEA Project is decentralized, allowing you to run the browser wallet locally on your machine without the aid of any central servers. - -- To get started, you should first have Node.js installed on your computer. The [official repo](https://nodejs.org/en/download/) should be sufficient for most users, though [Linux](https://nodejs.org/en/download/package-manager/), [Windows](https://github.com/coreybutler/nvm-windows), and [Mac](https://formulae.brew.sh/formula/node) users can also install Node using a package manager. Just make sure that the Node version installed is greater than 14. - -- Visit https://github.com/tearust/tea-browser-wallet/ and download the repo: - -![](https://github.com/tearust/tea-docs/blob/main/res/Try_the_demo/Try_the_demo-Tea-Browser-Wallet-download.png) - -Unpack the zip archive. - -- Start the browser wallet. From your command line terminal, run the following two commands when in the downloaded **tea-browser-wallet-master** folder : - -`npm i` - -`npm start` - -![](https://github.com/tearust/tea-docs/blob/main/res/Try_the_demo/Try_the_demo-node_start.png) - -- You should now to be able to access the browser wallet using localhost with the given port in your web browser: - -![](https://github.com/tearust/tea-docs/blob/main/res/Try_the_demo/Try_the_demo-wallet-localhost.png) - -You can use either [localhost:3000](http://localhost:3000) or [127.0.0.1:3000](http://127.0.0.1:3000) \ No newline at end of file