# A Trust Metric Protocol on Urbit ## Column High quality social media content, tailored to your interests, through an algorithm you control. An exit from limbic capitalism, and a path towards sane socials. ### Column and Urbit Urbit is a clean slate, web3 native, personal server, with a baked-in, non-fungible, pseudonymous identity primative. The radical design of Urbit creates unique opportunities for Column integration: 1. **Distributed Reputation System** * A trust metric, or reputation system, is a protocol whereby one node in some social network can test or query the relative trust they might have with some other node in the social network. * Several Web2 products have attempted to trust metrics as part of their services, including Advogato, Friendster and LiveJournal. * While these products commonly worked and even enjoyed extended periods of widespread use and enjoyment, the centralized megagraph that resulted from calculating reputation amongst users resulted in a variety of issues: * Abuse - Central systems have centralized attack vectors - gaming reputation in a centralized system is a more tractable proposal than in a distributed system. * DevOps - Making the trust graph available to all users, all of the time requires the classical system of services and load balancers that increase operational costs. * Strong Identity - Pseudonymous, centralized systems, with no limit to the creation or transfer of user identities, are not a reliable identity substrate on which trust can be graphed. Unlike human identities, online identities are (in classical environments) highly fungible and transparently transferrable. * Urbit, as a substrate for a reputation system will address these failures: * Diffused Attack Surface - With each user maintaining their own graph of their understanding of the trust flow around them, attacks against the system as a whole are less viable. * Zero DevOps - Urbit users run their own server, store their own data, get updates on the fly as an affordance of the networking layer of the operating system with the mere committing of a change in the production, distribution environment of the software. * Non-Fungible Identity - Urbit is the pre-NFT, NFT. The associations of pseudonymous Urbit identity and real human being were initially recorded in a spreadsheet, however they're now stored on chain as an ERC token. Consequently, the transfer of ownership of an identify from this to that wallet is broadcast as a listenable event on the Ethereum network. With Urbit, there is no equivalent to selling a YouTube channel, or twitter account for cash while retaining the following; at minimum, users would be aware of the change of ownership and capable of rebasing their assumptions about the identity. 2. Data Permanence - Auto-Wayback-Machine * [The Dirty Delete](https://azdictionary.com/what-does-dirty-delete-mean/), or deleting or editing a post without acknowledgement of that event, is a meaningful event, when socials are associated with a trust system. * Twitter accounts like [Editing The Gray Lady](https://twitter.com/nyt_diff) prove out user desire to know how narratives from authoritative sources are modified after their initial promulgation. * With Urbit, readers could store Columnists posts locally, on their own personal server. The application itself would natively allow for diffs between an initial viewing of a post and a subsequent edit of the post with no additional overhead to the original poster or Column as a company (see: Zero DevOps). 3. Data Composability * Each urbit is a general, personal server. In addition to running Column, a given user's urbit may be running a note taking software, an audio recording program and an ipfs integrated photo-storage system. * Data stored by applications, on a given urbit, is available to other applications on that Urbit (according to a set of permissions set by the user). * As a result of the personal server architecture, on Urbit, inter-application data composibility friction is significantly reduced. * Column will take advantage of this data composibility to allow integration of _other urbit data_ into Column (including other social platforms, should they come to represent a signficant user base). ## Work Scope ### Overview Quartus will build a distributed Trust Metric "agent" (application), capable of handling both "simple" vertex metadata (tagged points) and "complex" vertex metadata (structures defined by applications utilizing the trust metric). The distributed Trust Metric agent will utilize Ford-Fulkerson method flow detection against simple data and store complex data for use by other applications attempting to utilize the system. This fundamental piece of technology will enable a distributed trust protocol for use in the Column ecosystem, and unlock pathways to re-basing the entire Column network on urbit. ### User Stories * Formalizing Trust * I can create more than one graph of trust, representing perhaps what I in fact believe, and what I might imagine others to believe (a predictive algorithm) * I can store my trust graph on my personal server * I can access trust graph information on my personal server, _in the context of other applications running on my personal server_. * I can store "simple" trust where appropriate or define additional metadata for "complex" trust vertices * Applying Trust (simple) * On startup, I am given 1000 points per tag, per graph of trust, which I can apply in any proportion over the users I'm aware of. * This application of points is an index of trust against that user for that tag, e.g. if I apply 10 points of trust to ~rabsef-bicrym in the tag of %hoon, and 20 points to ~lagrev-nocfep, I am indicating that I trust ~lagrev-nocfep roughly twice as much as ~rabsef-bicrym, in regards to their knowledge relating to %hoon. * I can rearrange my trust at will, within a tag, constrained only by the total number of points I give out (never exceeding a sum total of 1000, per tag, per graph). * I can query the Trust System, giving a user name and a tag type, and find the flow between my node and theirs, based on my existing knowledge of the trust graph. * Applying Trust (complex) * As a developer, I can define a vertex metadata type and reliably store that metadata in the Trust System for use, later, in my products lifecycle. * As a developer I can access the stored data between two nodes and process it in my app for some purpose. * Interacting with Trust * I can see my trust metric data alongside user actions in the native social graphs of Urbit (Groups). * I can add, remove, reapply my trust metric data in the native social graph application, or in a separate, purpose-built application. ### Deliverables * Trust System Urbit Application Code Repository * System Documentation * Unit Test Suite * Application Deployed and Available on Urbit Network * Rough Outline of Roadmap Towards Additional Column:Urbit Integration/Port ### Timeline * Month 1 * Initial product specification in full technical detail. * Wireframes of product UI/UX for review. * Month 2 * Intial product passing unit tests. * Identification of any outstanding technical debt and plan to resolve these points. * Initial UI functional UI/UX design available for review. * Month 3 * Product available for final pass review. * Repository available for full inspection. * Product deployed and available on network (assuming pass of final review).