02/08/2019 - Flamingo Social Protocol: Introduction published @ https://medium.com/@lissajous/flamingo-social-protocol-introduction-152b492827e1
03/08/2019 - BitcoinTalk PRE-ANN posted starting the public discussion about the idea on Bitcointalk and on our discord @ https://discord.gg/qnxmHcM
Quote
Flamingo Social Protocol: Introduction
I’d like to start this article off with a big thanks to Satoshi Nakamoto and the cypherpunk community for creating viable decentralized replacements for monolithic actors. Thank you. You have given us more efficient, open, and fair systems by leveraging decentralized cryptography. You are an inspiration to freedom activists everywhere and history will forever be changed by what you’ve built. It is a hope that the Flamingo protocol will provide a viable option for the public to replace the social media companies who leak our otherwise private data to the highest bidder as a business model.
The goal of this paper is to be an introduction to the Flamingo protocol, a decentralized social network protocol for anyone in the globe to use and interact with their friends and followers on. This paper will answer some of the initial questions about the protocol and it precedes a higher technical level white paper. Hopefully it inspires some questions for the reader, too, and we’d love to have you share them with us on our discord. There is a lot of work that needs to be done. If you have an interest or passion for ideas that expand human freedom, or you desire to make tools that guarantee privacy, and you want to work to make Big Social obsolete, stop by and hang out.
A Regiment of Flamingos
The masternode protocol was chosen as the platform to build the Flamingo protocol on top of. It is an ideal candidate for a number of reasons, but mainly because there is a need to encourage the nodes storing the social data to be available 24/7. Masternode collateral is used to provide simple currency services, like enabling coin-joins, to give some privacy to end-users of the currency. A new function will be added to masternodes which will provide storage for data on the network. We will continue to refer to these as masternodes, but they will have noticeable differences for those accustomed to operating masternodes.
First, with 250,000 collateral and 5000 coins mined every minute Flamingo masternodes will have a relatively low collateral count compared to most masternode blockchains. For every masternode, there must be a 10GB partition dedicated for storage by that node. To put this into perspective, at the time we anticipate the network will start ‘accepting users’ (around 420,000 blocks from launch), the network should be able to serve a theoretical max of 84 TB of storage while adding about 288 GB to that total everyday. The storage requirements may change depending on community and network demand, but the coin collateral amount should never be changed, especially to try and react to temporary economic factors.
Another difference from traditional masternodes is that you can run as many Flamingo masternodes on a single daemon as you are capable of with your hardware. Typically only a single daemon will be necessary for all of your Flamingo protocol masternodes. There are legitimate concerns with other masternode networks having a concentration of masternodes on a single server, but our unique use case is not affected by them. With our low collateral amount, we are encouraging many operators to run multiple nodes on their Flamingo masternode servers.
The specifications and modifications were inspired by our use case for masternodes, not to make a quick profit. Often we hear comments about how the ‘collateral is too low’ and ‘what about ROI??’. The “desired” specifications of many users are often what turns many other people off to masternodes as they lead to a short-lived pump and dumps. It’s our opinion that having responsible masternode specifications which are structured to support our use case will allow for organic creation of economic rewards in the event of meaningful adoption. In other words, a fairly incentivized and sustainable model.
A Social Network
API/RPC calls will be added to the reference client to manage social data which users control the keys for. Social data includes the content of your posts, but also who your friends or followers are, and your pseudonyms. As there will no doubt be a demand for it, data can also be public. Data will also come with an expiration date after which the data will be removed from the network.
It’s very likely that the most common user interface for social data will be a small, possibly client-side, java script front end, which will be maintained alongside the core client. Instead of trying to add the full set of social features to a clunky qt wallet which will see little use for actual social networking, the reference client will be unchanged and mostly used by developers, miners, traders, and masternode operators.
Since we are specifically modifying the masternode protocol to serve our use case, it makes sense to allow people who want to host their own content to also do so. To that end, we will allow a special kind of masternode to join the network who will likely still require some collateral, but it will be a negligible amount compared to the 250,000 tokens mentioned above. They also will not get paid from the block reward like masternodes that have this 250,000 token collateral, but there’s much more to come on this topic later. It’s important enough to mention for the scope of this article.
Social data that is not public will be encrypted on the client side and then uploaded to the network. The normal user would basically load their profile from a synced node, and then fetch the data for the freshest ‘timeline’ from the masternode network. How that data is stored on the masternode network is a hot topic in our discord, so please stop by if it piques your interest.
Data will need to be stored redundantly to accommodate masternodes activating/deactivating without the data being completely lost. The level of redundancy will be the result of an equation that divides total masternode network capacity by total data to be stored. The result will be a useful indicator to show how the network is handling the load and will likely be the motivation for any discussion about the storage requirements of masternodes.
They aren’t going to build it
The large social media corporations know exactly what they are doing with our data, and it’s likely that the general public won’t shift easily from the status quo. Success will only come if the general public lets it, but building a trust-less platform for social media where the user is in complete control of their privacy is worth the risk of time. If you are interested in helping to build this tool and community, please join us: https://discord.gg/qnxmHcM
I’d like to start this article off with a big thanks to Satoshi Nakamoto and the cypherpunk community for creating viable decentralized replacements for monolithic actors. Thank you. You have given us more efficient, open, and fair systems by leveraging decentralized cryptography. You are an inspiration to freedom activists everywhere and history will forever be changed by what you’ve built. It is a hope that the Flamingo protocol will provide a viable option for the public to replace the social media companies who leak our otherwise private data to the highest bidder as a business model.
The goal of this paper is to be an introduction to the Flamingo protocol, a decentralized social network protocol for anyone in the globe to use and interact with their friends and followers on. This paper will answer some of the initial questions about the protocol and it precedes a higher technical level white paper. Hopefully it inspires some questions for the reader, too, and we’d love to have you share them with us on our discord. There is a lot of work that needs to be done. If you have an interest or passion for ideas that expand human freedom, or you desire to make tools that guarantee privacy, and you want to work to make Big Social obsolete, stop by and hang out.
A Regiment of Flamingos
The masternode protocol was chosen as the platform to build the Flamingo protocol on top of. It is an ideal candidate for a number of reasons, but mainly because there is a need to encourage the nodes storing the social data to be available 24/7. Masternode collateral is used to provide simple currency services, like enabling coin-joins, to give some privacy to end-users of the currency. A new function will be added to masternodes which will provide storage for data on the network. We will continue to refer to these as masternodes, but they will have noticeable differences for those accustomed to operating masternodes.
First, with 250,000 collateral and 5000 coins mined every minute Flamingo masternodes will have a relatively low collateral count compared to most masternode blockchains. For every masternode, there must be a 10GB partition dedicated for storage by that node. To put this into perspective, at the time we anticipate the network will start ‘accepting users’ (around 420,000 blocks from launch), the network should be able to serve a theoretical max of 84 TB of storage while adding about 288 GB to that total everyday. The storage requirements may change depending on community and network demand, but the coin collateral amount should never be changed, especially to try and react to temporary economic factors.
Another difference from traditional masternodes is that you can run as many Flamingo masternodes on a single daemon as you are capable of with your hardware. Typically only a single daemon will be necessary for all of your Flamingo protocol masternodes. There are legitimate concerns with other masternode networks having a concentration of masternodes on a single server, but our unique use case is not affected by them. With our low collateral amount, we are encouraging many operators to run multiple nodes on their Flamingo masternode servers.
The specifications and modifications were inspired by our use case for masternodes, not to make a quick profit. Often we hear comments about how the ‘collateral is too low’ and ‘what about ROI??’. The “desired” specifications of many users are often what turns many other people off to masternodes as they lead to a short-lived pump and dumps. It’s our opinion that having responsible masternode specifications which are structured to support our use case will allow for organic creation of economic rewards in the event of meaningful adoption. In other words, a fairly incentivized and sustainable model.
A Social Network
API/RPC calls will be added to the reference client to manage social data which users control the keys for. Social data includes the content of your posts, but also who your friends or followers are, and your pseudonyms. As there will no doubt be a demand for it, data can also be public. Data will also come with an expiration date after which the data will be removed from the network.
It’s very likely that the most common user interface for social data will be a small, possibly client-side, java script front end, which will be maintained alongside the core client. Instead of trying to add the full set of social features to a clunky qt wallet which will see little use for actual social networking, the reference client will be unchanged and mostly used by developers, miners, traders, and masternode operators.
Since we are specifically modifying the masternode protocol to serve our use case, it makes sense to allow people who want to host their own content to also do so. To that end, we will allow a special kind of masternode to join the network who will likely still require some collateral, but it will be a negligible amount compared to the 250,000 tokens mentioned above. They also will not get paid from the block reward like masternodes that have this 250,000 token collateral, but there’s much more to come on this topic later. It’s important enough to mention for the scope of this article.
Social data that is not public will be encrypted on the client side and then uploaded to the network. The normal user would basically load their profile from a synced node, and then fetch the data for the freshest ‘timeline’ from the masternode network. How that data is stored on the masternode network is a hot topic in our discord, so please stop by if it piques your interest.
Data will need to be stored redundantly to accommodate masternodes activating/deactivating without the data being completely lost. The level of redundancy will be the result of an equation that divides total masternode network capacity by total data to be stored. The result will be a useful indicator to show how the network is handling the load and will likely be the motivation for any discussion about the storage requirements of masternodes.
They aren’t going to build it
The large social media corporations know exactly what they are doing with our data, and it’s likely that the general public won’t shift easily from the status quo. Success will only come if the general public lets it, but building a trust-less platform for social media where the user is in complete control of their privacy is worth the risk of time. If you are interested in helping to build this tool and community, please join us: https://discord.gg/qnxmHcM
Coin Specs
Coin Type: PoW with masternodes
Algorithm: TBD (GPU)
Block Time: 1 minute
Block Reward: 5000
ICO: No
Pre-mine: No
Masternode Collateral: 250,000 - 2,500,000 (10 tiers)
Launch Date: TBD Join the discussion! https://discord.gg/qnxmHcM