When we setup TwoScoreTwo, we envisioned the following:
- Blockchains will disintermediate web applications
- People who provide services will be the ones making the most gain
- People's identities will not be monetized
- Web communication and transactions will be secure and private
- A peer-to-peer web where large corporations will have less market power
The current state of communication over the web is a travesty. Compare web communications with the physical world: where intercepting and reading someone else's mail amounts to mail fraud, and where listening to someone's phone conversations and reading text messages requires court warrants. We have given away our privacy and security over to corporations who read and use our transactions to generate profit...and none of that profit is shared with the user.
So, how does one go about making our lives more private, more secure; while still retaining the freedom and speed that the web delivers?
We have a two part solution - the first is a fundamental rethink of the technology to one that is Privacy and Security first, and Decentralized. The second part consists of applications that use that technology backend to deliver services to users. Applications that do not monetize users in any way, reduce information asymmetry, and return gain to where it belongs - back to the producers and sellers.
So what does this mean to social networks - we believe that our two part solution will Make Social Better - by delivering on the promise of the web: Secure and Private person to person communications and transactions.
Our two part solution required us to unpackage and rebuild the technology backend to be decentralized, while retaining the ability for developers to provide user facing applications and generate revenue. Through multiple iterations, we thought through and rebuilt core parts of the technology to realize the privacy, security, and the decentrailzed-first approach: from the user facing layer all the way to the ledger.
After we developed foundational services for storage, sending, and receiving communications (same as transactions), we moved to working on the front end. Here we took an opinionated approach - regarding how identity is protected, methods for authentication, ways in which data transmittal occurs between the backend technology and frontend, and data protection protocols.
Our approach requires the following:
Transactions (includes communications) between one or more parties of the transaction must be kept private. Parties external to the private group for that transactions must not be able to access the content of the transaction and must not know who was party to the conversation.
Content must always be kept secure using cryptography. This applies to scenarios that includes: content at rest (in storage), being transmitted between parties, or accessed by one or more parties. It must not be possible to unlock content, if for any instance, the content is accessed by non-permissioned parties.
It must not be possible for one or more parties to dispute being party to a transaction. Content scenarios include authorship, receipt, transmittal, and view. Access scenario's include registration, login, paths, and resources.
Cryptographic artifacts for users such as keys and content passwords must be administered and managed by single authority trusted by the permissioned network. Discrete networks may use the same authority, in which case, the authority instances must be maintained separately.
It must be possible for a party in a transaction to verify that content being accessed is exactly the same as the counterparty(ies) claim. This would include scenarios where there is a single party in a transaction, where content is stored by the user, and then accessed at a later time.
Chain of Custody
It must be possible to view without dispute the totality of actions that have taken place for a transaction or content.
Roles and Permissions
It must be possible to define and set fine-grained roles and permissions for users. For instance, this includes access to specific routes, content, transactions, actions, and frequency of access. The roles and permissions will be distinct for discrete networks. It must not be possible to access multiple networks with the same credentials.
Selling or sharing of user data or content tracking data must be disallowed.
Applications must not act as payment or money transfer intermediaries. There are other methods available where money can be transferred between parties without injecting additional cost to the user.
Applications have the freedom to build innovative business models such as charging for value added services provided - that must be clearly stated, however, applications must not build intermediaries such as brokers, ordering services, and similar which can be replicated easily as peer-to-peer applications. Applications must embrace disintermediation-first as the guiding principle and build the business model around that core idea.
Our initial foray was in the B2B space - this was a mistake - given the varied demands of business prospects and the long sales cycle. We were unable to compete in feature bake-offs and grappled with questions of technology maturity from buyers who were unaware of distributed ledgers and permissioned networks. After a bruising two years that almost finished us off, we moved to focus on building out the technology and more recently the frontend applications serving end consumers.
We are now able to rapidly develop frontend secure and private applications on our technology backend - which we know intimately and evolve.