Trsst is a system of social communications that supports the open web, protects freedom of speech, affords proof of authorship, protects privacy and anonymity, and allows content creators to be compensated for their work.
Existing means of social communications, particularly popular services like Twitter and Facebook, are lacking on all of these counts. In that the content generated on these services is largely unreachable except to members of these services, and that these services no longer support open web standards like RSS, they do not support the open web. In that these services are controlled by corporations, the shareholders and directors could at any time overturn any commitment or promise of privacy or anonymity. In that these corporations operate with license from and under the jurisdiction of a government, these governments have many times legally compelled them to do so. Most if not all governments today actively engage in covertly tracking the communications of their citizenry. And most bloggers today will readily acknowledge the difficulty of making money writing for the web, especially the social web.
Trsst is social. It supports the common use cases of web logging software, the common use cases of microblogging software, and the common use cases and idioms of social networking applications.
Trsst supports the open web. It works with existing web browsers, desktop and mobile, and no external applications or native software is required. Users can follow existing content feeds without modification, and existing feed readers can follow users' feeds. Private content is kept private, while public posts are search-indexable and open to the world without forced membership or specialized software.
Trsst supports freedom of speech. Creating content with Trsst affords both anonymity and proof of authorship. A user's blogchain provides proof against censorship in the form of message tampering or individual message suppression or omission. The syndicated network protects against censorship by network server blacklisting or keyword filtering.
Trsst protects privacy. It affords encrypted private communications between individuals and encrypted private publishing to groups of individuals. It allows anonymous authorship. Servers host only encrypted content that they are unable to read because only the user holds the decryption keys.
Trsst fosters mainstream adoption of digital currencies and compensates content creators for their created content. In Trsst, every user account is a digital wallet. Authors and individual pieces of content can receive secure and anonymous micro-payments of digital crypto-currency, enabling long-envisioned content monetization schemes where authors receive small payments each time their content is consumed, shared, or "liked". Trsst allows these payments to be made anonymously to an author, to a site, and on each individual piece of content where-ever it is syndicated or appears on the web.
Because revolutions are started on social networks like Twitter and Facebook, and dissidents, informants, confidential sources, journalists, and those they trust all rely on these services, our method will better preserve their causes, their freedom, their livelihood, and their lives.
A user is a person who reads or writes blog entries. Users create accounts to follow other users' accounts to read their entries, and some users create entries on their own accounts for other users to follow.
An account is a persona created by a user for the purpose of authoring blog entries. Entries belong to an account, and an account belongs to a user. A user can have multiple accounts, but a typical user will only need one. The relationship between an account and a user is hidden by default, preserving the user's anonymity.
A nickname is a optional human-readable text string used to describe an account. A nickname is required to be unique among all nicknames for all accounts managed by a server, such that an address of the form email@example.com and/or nickname.hostingprovider.com is globally unique. The globally unique form of the nickname becomes an alias for the account public key.
A tag is a short text string usually comprised of a single word and used to categorize entries. Often they are preceded with a hash symbol; for example: #cats, #dogs, and #alpacas. In RSS parlance, this is a category.
A mention is a reference to an account or nickname that is embedded in an entry. A user mentions an account in a blog entry to bring that entry to the another user's attention.
To follow is to subscribe to a feed of a user's blog entries. Users follow one or more other users to receive a stream of entries from all of those users.
A feed is a document retrieved over a network connection, usually over a web protocol and usually in an xml-based format, that contains header information about an account and one or more entries or summaries of entries from a blog.
A client is the software running on the user's computing device to read and write and store entries. A client can be a native software application, or a software script downloaded to and running in a user's web browser or other execution environment.
A server is taken to mean a single physical server, a collection of servers residing on a cloud infrastructure, or a company providing servers in either of those two contexts.
A syndication network is a federation of servers that all agree to adhere to protocols of sharing feeds such that users' entries are propagated across the network for efficient retrieval, fault-tolerance, and resistance to censorship or suppression.
A keypair in terms of public-key cryptography is the pair of a private key and its corresponding public key. Each user's account corresponds to a keypair, and the public key is the account's unique identifier. The keypair is generated as a valid payment address in a crypto-currency system such as Bitcoin. The account's private key is held by a user in secret and kept in a keystore.
A keystore is an encrypted file that contains all of a user's keypairs: one for each account, and possibly more that are directly associated with individual entries or additional crypto-currency payment addresses.
A blogchain is a chain of entries linked together such that each digitally-signed entry contains the digital signature of the entry that directly precedes it. In this way, the integrity of the chain can be validated, and any missing or modified entries can be identified. Entries created on an account are added to the blogchain for that account.
The operation of the system is described through individual use cases from the perspectives of the user and the server.
To begin using the system, the user obtains a client which creates a keystore. The client encrypts the keystore with a user-specified password which is subsequently used to access or modify the keystore.
The user next creates one or more accounts. For each account, the client generates a keypair, and stores it in the keystore. Each account's public key is the globally unique identifier for that account.
The keypair generation uses the same scheme as a crypto-currency key generation scheme, such that the public key of the keypair is a valid payment address for a crypto-currency such as Bitcoin.
The user may optionally attach personally identifying information to the account, such as a personal name, nickname, and/or url to an icon or image; or, the user may choose for this account remain anonymous. In either case, the publicly unique identifier is the public key of the account.
The user may create one or more entries on an account.
An entry consists of a globally unique identifier, a timestamp, and optional additional attributes including but not limited to:
In some cases, the globally unique identifier may be a valid payment address for a crypto-currency such as Bitcoin. In this manner, users can be compensated for specific pieces of content they generate, and the payment address will convey with the content where-ever it appears within the syndication network, or beyond.
In the common case, the user writes the short text summary, and optionally one or more mentions of other accounts to bring the entry to the attention of the users of those accounts, and optionally one or more tags to help categorize the content of the entry.
The user decides whether to post an entry publicly or privately.
In the default case, the user decides to post the entry publicly so it is visible to everyone. In this case, the client signs the entry using the account's private key and then adds the resulting message digest as an attribute on the entry. Other clients can use the account's public key to verify that the entry was created by that account, and that it was not modified since signing.
If an account has more than one entry, the message digest of the most recently created entry is included as an attribute on the newly created entry before its message digest is generated. In this way, each entry forms part of a blogchain with all other entries, and each entry can be used to verify the existence of the immediately previous entry, and to verify that no entries were tampered, deleted, or otherwise suppressed.
In some cases, the user decides to post an entry privately so that only the user of another account can read it. In this case, the entry is encrypted with the public key of the other user's account so that only the account owner can use their private key to decrypt it. The encrypted data is signed to generate another message digest in unencrypted form to be used with the next new entry.
If the content size exceeds a specified threshold, the entry is compressed with a known compression algorithm (such as gzip) before it is encrypted.
If the encrypted entry contains attachments, these attachments are compressed and encrypted using the same key and in the same manner but may be stored separately.
When the entry is encrypted, the intended recipient account will know about the entry only if it is following the authoring account. To bring an encrypted entry to the attention of the intended recipient account that is not a follower, the user may decide to add one or more mentions or tags to the entry in unencrypted form.
When a user wants their account to follow another account, it posts a public entry mentioning the target account with an attribute action verb such as "follow". The entry may contain multiple mentions to follow multiple accounts.
When a user wants their account to stop following an account, it posts a public entry mentioning the target account with an attribute action verb such as "unfollow". The entry may contain multiple mentions in order to stop following multiple accounts.
Some clients may allow users to follow accounts without posting public entries.
When a user's account is following one or more accounts, the client retains information about each account, including the account's home server if any, and periodically requests entries for all followed accounts from the user's home server if any, or the home server of each followed account if any, or from any server participating in the syndication network.
The client displays entries from the user's own accounts and from any remote accounts that are followed by the user's accounts. Clients have complete freedom and latitude to render entries in whatever manner desired: some clients may resemble Facebook or Twitter or Google Reader and others may resemble conventional web pages, threaded discussion forums, or even email clients.
When the client encounters an encrypted entry, it attempts to decrypt the entry using: its own private key (in which case the entry was a private message intended for the user's account) and every group public key previously received in previous private messages from the originating account, until either the message is decrypted or all keys have failed to decrypt the message.
When an entry contains attachments, the client may fetch each attachment and render it inline with the entry or otherwise may provide means for the user to fetch the attachment. If the entry was encrypted, the attachments are decrypted with the same key used to decrypt the entry.
When a user wants to post private entries to an account to be read by more than one other user's account, the user creates a "group" in their account. To create a group, the client generates a new keypair associated with this group in the keystore, and the user can associate descriptive information with the group, such as "Friends" or "Family".
When the user wants to add another user's account to a group, the client posts a private entry to their account encrypted for the target account and containing the public key of the group as the short text string or optionally as a separate specific attribute on the entry. In case the target account does not follow the user's account, the user may add a public mention of the target account as described above.
The client may also post a private entry to the group (see below) mentioning the newly added account with an attribute action verb such as "invite".
A user posts a private entry to a group by encrypting an entry with the group's key. The entry is otherwise created and treated as any other private entry. In this manner, all accounts that have the corresponding key at the time the entry was posted can decrypt and view the entry.
To remove accounts from a group, the client creates a new keypair for the group and stores it in keystore. Then, for each account that has not been removed, a private entry is posted, encrypted for the target account and containing the new public key of the group as the short text string.
The client may also post a private entry to the group using the new key and mentioning the removed accounts.
All future posts to the group are encrypted using the new key for the group. In this manner, new content intended for the group is no longer visible to accounts that were removed from the group. Previously existing entries will remain visible to the removed user unless the entries are edited and/or deleted (see "User edits an entry") causing those entries to be re-encrypted with the new key.
When a user deletes an entry, the client posts a new entry referencing the target entry and including the message digest of the deleted entry and the message digest of the entry immediately preceding the deleted entry. In this manner, clients can maintain and verify the integrity of a blogchain that includes deleted messages.
All attributes of the target entry are deleted except for the unique identifier and timestamp and a syndication preference that tells other servers on the syndication network to cease and desist redistribution of the previous entry and to delete any stored copies.
When a user edits an entry, the user may decide whether to preserve the the target entry, or delete it.
If the target entry is preserved, the client generates a new entry referencing the target entry and containing the attributes that are changed. In this manner, the change history of the particular entry is preserved and may be rendered appropriately in the client. The attributes themselves may contain a standard markup notation (such as diff notation) such that only the portions of the lengthy attribute values that are modified need be contained in the attribute values of the new entry.
If the target entry is deleted, the client modifies the target entry and posts another new entry referencing the deleted entry as described above (see "User deletes an entry").
Trsst encourages and supports standalone client nodes that publish entries to the syndication network. However, in practice, most users will contract with a server, subsequently known as their home server, to reliably store that user's keystore, entries, and attachments, as well as serve feeds, entries, and attachments, send notifications to the user and/or the user's client, and/or relay these items to and from other servers participating in the syndication network. The terms of the contract are negotiable between the user and the server, and servers should differentiate themselves based on cost, storage capacity, performance, and terms and conditions.
In the common case, the user downloads the client software from their home server and allows it to execute in a web browser on a computing device. The user may choose to use other kinds of client software including kinds that execute independently of a web browser. The user may choose to obtain the client software from a hosting provider other than their home server.
When a user has posted new entries to one or more of their accounts, the entries may be submitted to one or more servers. The client submits each entry to the user's home server, if any, and optionally to the home server of each account mentioned, and optionally to one or more other servers in the syndication network. See "Pushing a feed to a server" below.
When entries are transmitted between client and server or between server and server, the interchange format is called a feed. A feed contains a header with identifying information about the account and a body containing zero or more entries.
The header can contain attributes optionally including but not limited to:
This interchange format conforms to an existing standardized format such as RSS or Atom with standardized extensions to the format as needed.
All client-to-server and server-to-server communications are conducted over HTTPS. In this manner, all entries, including public ones, are encrypted and the entries cannot be filtered or suppressed by third-parties based on content.
Feeds can be pulled from a server, or pushed to a server.
A requestor -- either a client or a server -- requests a feed from a server by sending a network request containing the public key of an account and optional additional parameters to sort and/or filter the entries in the resulting feed. The server responds by generating and returning a feed containing entries for the specific account including header information for that account.
In some cases, requestors may request entries in a given time window; for example, all entries posted in the past two weeks, or all entries posted in July 2013. In the common case, requestors may request all entries for an account posted after the specific point in time when that client last fetched entries for that account. In this manner, requestors can efficiently request just the updates made to an account in order to keep their local copies of the account's metadata and entries synchronized with the rest of the syndicated network.
In some cases, requestors may request entries that match certain tags and/or mentions and/or verbs. In these cases, the resulting feed contains only the entries for that account that contain those tags and/or mentions and/or verbs. Some servers may allow the account identifier to be omitted in this cases, in which case the server returns all matching entries from all accounts who use that server as a home server, or more broadly, from all matching entries stored on that server regardless of home server.
In some cases, servers receiving requests may make requests to other servers to retrieve the entries needed to satisfy the original request. In this manner, entries from accounts whose home server has been blocked or otherwise deactivated or unreachable will continue to be distributed and accessible across the syndication network. The request will include the history of triggering requests such that a request does not create a cycle and search depth can be curtailed during high load conditions.
In all cases, requestors may combine request parameters such as account identifiers, time windows, tags, mentions, and/or verbs, with logical boolean operators, to achieve the desired outputs.
In all cases, servers may truncate or paginate responses as they see fit, and in such cases must communicate to the client that the results are incomplete.
A submitter -- either a client or a server -- submits a feed containing zero or more entries to a server. In the common case, a client is pushing newly created entries to its home server, but clients may also push directed entries to the home servers of mentioned accounts, and servers may also push selected entries to other servers as part of their participation in the syndication network.
When a server receives a feed, it may validate the feed's header and individual entries against the public key of the associated account. Feeds and entries that do not validate may be rejected. Servers may also reject entries for other reasons, including for example rejecting entries from accounts not followed by accounts hosted by this server, or rejecting entries from accounts not hosted on this server.
When a server accepts an entry, it stores the entry and optionally any attachments, and optionally submits the entry to the home server of each mentioned account, and optionally to one or more other servers in the syndication network. As an optimization, the two parties may collaborate to determine which party can most efficiently relay these entries to the home servers of mentioned parties or other servers in the network.
A server may decide how long to store entries and attachments based on factors including but not limited to: the syndication preference specified by the account and/or the entry, the size of the data, how frequently it is requested, how many of its users' accounts follow the account, and whether the accounts related to the entry are in contract with the server. Users may enter into contract with one or more servers to store the user's keystore and all the entries and attachments for its accounts and/or provide expedited syndication for those entries.