Post by Glavos on Feb 13, 2016 9:07:01 GMT
||This document is intended to answer questions regarding GetGems High-level roadmap. We will take Gemz holder’s input on major features.||
How is GetGems different from social networks like WhatsApp or instant messengers like Telegram and Facebook Chat?
One of the fundamental differences between GetGems and social network applications like WhatsApp, Telegram or Facebook Chat is the reward model. GetGems promises to reward users according to their contribution. GetGems is how we, the users, are finally taking back social networks.
A social network’s value is measured by the number of active users. WhatsApp sold for $19 billion, with every active user valued at approximately $50. If you personally introduced 100 users to WhatsApp, and the model were fair (more on fairness below), you would have received significant compensation.
By introducing a new form of distributed cryptographic tokens, GetGems, we form an in-app economy. GetGems serve as the in-app token with which the app’s other added-value features can be utilized. These tokens represent a credit that can be used solely for the redemption of in-app features, such as sending an unsolicited messaging to other users. The tokens also serve as an anti-spam mechanism to ensure the health and friendliness of the network.
The GetGems app will include an in-app wallet, one feature of which will be the ability to purchase third-party offers directly within the app at the click of a button. This is a key advantage for advertisers.
Users are rewarded with actual gemz according to their contribution to the network. The more active users a user introduces to the network, the more gemz you receive. There are other ways to earn gemz, yet their supply always remains fixed and limited.
What is so revolutionary about the GetGems model?
For an analogy, consider the cryptocurrency revolution. Traditional currencies have always been controlled by a single entity—usually a government. Virtual currencies, such as bitcoin, on the other hand, are distributed by nature, preventing any central entity from assuming control.
GetGems brings the same revolution to social networks, thereby achieving social-network decentralization. The value of social networks is tied directly to the number of active users. In a fair model, if users bring the value to the network, they should also be rewarded according to their contribution.
Additionally, since the users of the network own the actual tokens that represent the value and utility of the system, the developers of the GetGems platform are naturally incentivized to operate according to the will of the community. This means that the GetGems community can choose the features they want to see simply by voting with their gemz. GetGems participants can, therefore, ensure that the platform is always responsive to the needs of its users, and not the other way around.
How does GetGems make bitcoin more accessible to the masses?
One of the biggest challenges of the cryptocurrency community is making bitcoin easily accessible to the masses. Bitcoin is gaining in popularity, but it is still out of reach for most of the general public. The majority of people may have heard of bitcoin, but they do not know what it is. Furthermore, most who do know consider it too complicated to use.
As of 2014, there are only about one million bitcoin users. This is less than 0.1% of the world’s Internet users. As a comparison, consider the mass adoption of social networks. How many Facebook users are there? Over 70% of the world’s Internet users are Facebook users. The barrier to opening a social network account, then, is significantly lower than the barrier to opening a cryptocurrency wallet.
GetGems helps bridge this gap. Joining the cryptocurrency world becomes as easy as opening a WhatsApp account. The entire process can be done directly from a mobile device, in under ten seconds.
The Gemz cryptographic token is powered by Counterparty. Once a GetGems account is created, it automatically includes a Counterparty wallet. Using the wallet is as simple as using the GetGems app. GetGems even makes trading easy. Sending gemz and bitcoins between users is as simple as sending an instant message.
The Daily Airdrop—How GetGems Rewards Users Who Contribute to the Network
The value of a social network is tied directly to the number of active users. The key concept behind GetGems is that the network rewards its users, thus, the value reward should be divided fairly between the users according to their contribution. How does this work?
This model is implemented using the daily airdrop. A percentage of all available gemz—30,000,000, or 30%—are reserved for distribution in daily airdrops. Every day, ~27,400 gemz are taken from the reserve and distributed directly to users according to a public and fair algorithm. The gemz are “dropped” into the users’ wallets, hence the term “airdrop.”
The goal of the airdrop is to reward users based on their contribution to the success of the network. Since we measure network value by the number of active users, the algorithm is designed to reward users who introduce other active users.
The Invitation System—Determining Who To Reward
The first part of the model is based on the invitation system. When each new GetGems account is created, the new user is asked to confirm which user invited him into the network.
This process is easy because the inviter’s username is usually prefilled, since it comes attached to the invitation link for downloading the GetGems app that users can share with their friends. A new user can override the invitation credit and give it to any user he wants. (See the section on presale perks find out what happens when the new user gives no invitation credit.)
From this point on, the system remembers the original inviter for every user in the network, and every user has an original inviter. This is a key point of the model.
Counting Active Users
The next part of the model involves determining the number of active users. Since airdrops occur every day, we only consider active users during the previous twenty-four hours.
An “active user” in a given a twenty-four-hour period is defined as one who has used the Gems app in that time period and who has performed several social activities within it (such as sending an instant message, trading gems, and so on). A user is marked as either “active” or “not active.” There is no regard to the actual amount of activity. It is important to note that this part of the algorithm is a probable target of attempted fraud. The algorithm employs various techniques to filter fraudulent users and avoid “activity spam.” (See the section about avoiding fraudulent activity and spam.)
After the system determines the daily list of active users, the algorithm checks for their original inviter, and then counts the total number of active users per original inviter.
For example, let’s assume user A invited users A1, A2 and A3, and user B invited users B1, B2, and B3. During the twenty-four-hour period, users A1, A2 and B3 were determined to be active. After counting the totals, user A has a count of 2 active users and user B has a count of 1.
Factoring It All In—The Contribution Score
The final part of the model involves calculating a contribution score for every user in the network. The number of gems in the airdrop is divided between users according to their contribution score.
For example, user A has a contribution score of 20 and user B has a contribution score of 5. If we had 100 gems in the airdrop, user A would receive 80 gems and user B would receive 20 gems.
The contribution score for a user is calculated according to two complementary factors:
The total number of new, active users that the user invited during the time period. This calculation is directly related to the active user counts (total of active users per original inviter).
The total number of gems that the user currently holds in his account. This means that users with a large amount of gems will be rewarded more generously than users without gems.
How does Gems enforce security and privacy?
Gems are not only a social network. It is also a cryptographic token. As such, Gems conforms to the strictest security guidelines in order to keep your data and your wallet safe.
The core security model of Gems is based on Counterparty. Since Counterparty is secure by nature, every action performed on a gems wallet conforms to the guidelines established by Counterparty and the bitcoin blockchain. All communication is encrypted, and access to the gems wallet requires a secure passphrase. (See Counterparty secure passphrases for more information: wiki.counterparty.io/w/Counterwallet)
The inherent stricter level of security benefits the instant messaging aspects of Gems as well. The Gems app assumes zero trust and even protects user data from the Gems cloud servers themselves. Every secure outgoing message is encrypted with a key that is unknown to the server, making the message recipient the only one who can decrypt it. This privacy model has become popular lately and has been adopted by other secure instant messengers, such as Telegram, to prevent any possibility of eavesdropping by third parties, including government agencies and corporations.
Another layer of security is enforced by locking each Gems account to a specific single mobile device. If you want to transfer your account to a different mobile device (after buying a new iPhone, for example), you will be required to input your secure passphrase. If your mobile device gets stolen, you can use your secure passphrase to remotely disconnect your Gems account from the stolen device, making Gems inaccessible to the thief.
There are two main concerns with a centralized system:
The first concern is anonymity and privacy of Gems users. Centralized systems are more prone to be monitored by external entities - for example, a government agency with a warrant for access to our servers. This concern is actually not specific to centralized systems and a good security policy assumes that all traffic is always being monitored by external entities - even if the network is completely decentralized.
The Gems network operates under this assumption. Secure messages via Gems are encrypted client-client. This means that these messages cannot be monitored by anyone except the two members of the conversation. This includes anyone listening in on the traffic transmitted by the mobile devices and this even includes the server itself. In other words, this means that the servers cannot decrypt the content of these messages. In any case, the encrypted messages are only held by the server in the short time until delivery, so history of the entire (encrypted) conversation is never stored anywhere except on the mobile device itself.
The second concern is robustness of the network and the ability to freely and openly scale the network in the hands of third parties. In the Gems ecosystem, this means third parties will be able to add their own server nodes. Since server nodes can't access the content of secure messages, there is no security concern with adding nodes. This can roughly be compared to how third-party routers in the Internet route your traffic to its destination.
The Gems message routing protocol is based on an open source framework (SignalR). It was designed to support multiple distributed nodes in order to support massive scale (a single server will never be able to support millions of users). We plan to open source the Gems message routing protocol and allow third parties to add new server nodes to the network. Mobile clients will be able to connect to these nodes and send messages through them just like with the original Gems servers.
How Are Messages Encrypted
Instant messages in Gems arrive in two flavors - standard and secret. Standard messages are the default type and provide a standard level of security. Secret messages are meant for highly confidential conversations and provide an extreme level of security and privacy. App users can switch between these two flavors for every chat conversation. Making a conversation secret is very easy, and only requires tapping on the "lock" icon inside the app.
Instant messages are encrypted on two levels. The first level of encryption is relevant for both standard and secret messages. For both types, all communications between the Gems mobile app and the Gems instant messaging cloud server are encrypted - this is also referred to as client-server encryption. Communications between the two are performed over SSL in a secure tunnel (HTTPS) with 256-bit keys. This prevents third parties from listening in. This also prevents man-in-the-middle attacks and makes sure the Gems app only communicates with the real server and not anyone impersonating it.
The second level of encryption is only relevant for secret messages. On top of the client-server encryption, secret messages also have client-client encryption. Every Gems app generates a unique random pair of 4096-bit public/private keys upon installation. The public key is propagated within the network, but the private key never leaves the device. The public/private pair is unique to a device. If the user transfers his Gems account to a new device, a new pair is created. The key pair is also expired and refreshed periodically to enhance security.
When user A sends a secret message to user B, it's encrypted using RSA 4096 with user B's public key. Once the message arrives at user B's device, it's decrypted with B's private key. Decryption can only take place on user B's device because only this device has access to the correct private key.
The benefit of client-client encryption is that it provides a zero-trust environment. The encrypted message cannot even be decrypted by the Gems server infrastructure. This means that even if the Gems servers have been compromised and hacked into, secret messages are still 100% private and can only be decrypted by their rightful recipient.
The drawback of secret messages is that they cannot appear in push notifications. Since push notifications are encrypted by Apple's/Google's infrastructure, they don't conform to zero trust policy. When a secret message is sent from user A to user B, the push notification user B receives contains the text "You've received a secret message from A" instead of showing the actual content of the message.