Fundamentally, freedom of speech is the idea that the government should not be able to prohibit, censor, or otherwise regulate what you can say.
There is a separate but related idea of a right to privacy: the idea that nobody but you and the intended recipient of a message should be able to read it. Perhaps the best known way to guarantee this with digital communications is to use end-to-end encryption, where only the sender and recipient have the keys to reveal the message.
With most centralized services like Twitter (run by private corporations), the right to privacy is not strongly guaranteed. Companies like Twitter can be (and have been) compelled by the government to provide access to this private content in response to subpoenas.
Similarly, private companies like Twitter can be (and have been) compelled by other forces (e.g. public opinion, advertisers) to regulate speech. This is because private corporations, unlike the government, have no obligation to protect your freedom of speech, and many reasons not to.
The key insight is to recognize that these things are separate concerns, and that they are best addressed separately. If you separate the concerns of widely publishing messages that should be readable by anyone from messages that should only be readable by some, it becomes clear: the best entity to provide privacy is a private corporation, and the best to provide publicity is the government.
At first, this is unintuitive, perhaps shocking. If the government were in charge of publishing, wouldn't that give them the direct ability to monitor and regulate your speech? Well, yes. But bear in mind that the government can already read all of your public tweets (that's what public means). Further, a government that is corrupt enough so as to allow unchecked violations of the rights of citizens is also already corrupt enough to compel corporations within its jurisdiction to do the same thing. And private corporations are already ripe to be compelled, as they ostensibly already are via public opinion and advertisers.
Now we've arrived at the fundamental proposal, namely that the government should provide the digital equivalent of a public forum: a place where people can share their thoughts, and see the thoughts of others.
Unlike solutions like Mastadon, this would remain available indefinitely as a service for tax payers, by tax dollars.
The solution that follows can conceivably support posting end-to-end encrypted messages. However, this is not recommended, as it would be equivalent to leaving your locked laptop in a cafe. Attackers might not be able to access it today, but they might in the future. Instead, it should be reserved for things that should be widely seen, consumed, and archived.
For the same reasons the federal government is separate from state governments, so too should the forum. Instead, each state government should run it's own, as well as determining who should be allowed to post to it and how they are authenticated.
It's easy to have your rights infringed by your own local government. Physically, we have remedies such as asylum and sanctuary for this. Likewise, it's very likely that some states will opt to allow access to people who are not citizens of that state.
It's feasible that some states could abuse this ability to e.g. give access to automated systems or foreign actors in order to spread misinformation. For this reason, it's critical that there is a chain of trust associated with each piece of content that can be audited.
The proposal is that each state should have its own unique digital certificate that it can use to sign the payloads of authenticated users. Users themselves would have their own public/private keypairs that would be used to sign their messages. States would independently decide how to authenticate each user.
Fundamentally, the proposed structure is a simple transaction log, similar in spirit to commits in the Git version control system. Each transaction is a dictionary with at least three required fields:
| Field | Value |
|---|---|
author |
Public key belonging to the author |
time |
UTC timestamp when submitted. Servers would just verify that this is close to the current time, and chronologically follows any other messages published to this server by the same author. |
signature[0] |
HMAC of the entire message, minus signature fields. Signed using the private key corresponding to author |
States will then sign this message (including the signature[0] field) and set the result in the signature[1] field.
Authors can include additional arbitrary entries to provide more advanced features. The requirement is that the size of the message (excluding signatures) shouldn't exceed e.g. 5 kB.
States would then provide a public API with at least four standard functions:
- An ability to subscribe to transactions made from any user as they made, in near realtime, and paginate the timeline
- An ability to paginate historical transactions for a given user (by public key)
- An ability to quickly retrieve the content of a message given a
signature[0]value - An ability to search for messages with partial or exact matches to some query by a given field
Messages are immutable, but features like editing and archiving (instead of deletion) can be implemented using extensions. States can stop serving messages that violate their laws, but there is no provision to delete every copy of the message that may exist (e.g. in caches, on other servers, or on clients).
It's not expected that users will typically interact directly with the state-run servers. Instead, it's envisioned that this will be facilitated by custom clients, akin to e-mail clients.
Similar to e-mail, clients and their providers will be responsible for connecting to the servers and collating messages to present. Unlike e-mail, all of the content is presumed public, and so there are numerous opportunities for optimizations such as caching. It's expected that providers will massage the data into data structures that can be efficiently traversed for their clients, e.g. via graph databases.
Client providers will sustain their operations by, for example, providing paid premium features such as storage for photos and videos, inserting sponsored ads or other promotions, content ranking, etc.
This proposal is meant to be the bare minimum, and to be arbitrarily extended to provide new features by clients agreeing on certain features. Some examples are provided for completeness and to demonstrate the extensibility, but may look different in practice:
Text content is trivial: a new field such as x-message can be included in the message with UTF-8 encoding. Clients would render this when present.
Replies can be supported via a new field such as x-reply-to whose value is the signature[0] of the target message. It would be the responsibility of the individual client/provider to maintain the list of replies to a given message in an efficient manner.
Photos and videos can be supported via a new field such as x-attachment. This would contain a list of one or more external resources (e.g. URLs) along with the expected digital signature of the resource.
Providers may optionally cache the resource on their own servers for their clients, provided that the signature remains the same.
Messages can include a new field such as x-about that references some external profile that contains data about the user. It's expected that this content would be hosted by the user's preferred client/provider, and point to another message signed by the author containing other fields such as x-about-name, x-about-location, x-about-url, etc.
This value should be provided in every message, but clients should use the most recent value known for a given author (by timestamp in a signed message) to prevent bad actors from preventing users from migrating to another client/provider.