It's 2020: most people drink corporate coffee, shop at corporate malls, use corporate social/chat applications, and talk on corporate cellular telephones. To create a thriving independent culture for collaborative communication on the web we need to create a tool that will facilitate creative communication without bogging everyone down with implementation details or overly oppressive rules about how the platform should be used.
I'll call this "Solving The Schoolhouse Dilemma", in reference to the loft I used to live in. When the culture was good at The Schoolhouse, it was a creative space where people felt awesome about expressing their opinions and creating their creations. When the culture was bad at The Schoolhouse, the door was open to street level Bushwick and people were traveling from New Jersey on skateboards to drink the beer we'd purchased and then urinating on our bedroom doors instead of using the toilet.
We want this program to work as close to human memory as possible. After the party there is no party, and after a party at The Schoolhouse all we have is the memories. We want to be able to be selective about which memories we preserve on The ~Protocol. If every party is a bad party, we want the current maintainer of The Schoolhouse to be able to preserve as little of the conversation as they want to -- if the party is a great party then we want the current maintainer of The Schoolhouse to be able to preserve as much of the converstion as they want to. This doesn't mean that stuff doesn't get forgotten, it's just the boring stuff that no one remembered during the show.
Chat culture is also people culture, so I think The Schoolhouse metaphor for our ~Protocol can apply to a network.
Our aim is to develop a protocol that can allow creative communication, without terrifying everyone so that they run back to corporate communications services.
Let's take a few examples of how creative chat culture is failing on the Internet:
secure-scuttlebutt/bogbook are bogged down by append-only logs. Whether you're doing three-hop replication or selective per-click replication, you're still asking new participants to replicate a lot of information that they might not want to remember on their own instances. The append-only logs recall everything that ever happened, and sometimes we want to forget for practical, legal, or interpersonal reasons. ssb doesn't give curation tools at all, and bogbook only allows per-feed curation. We don't need to remember everything forever, instead we need a more flexible protocol that is also secure that will allow selective remembering.
ipfs/bittorrent/dat aren't great for chat clients, but are awesome for sharing large files.
and the failures of corporate social media are well documented: Jack's house is Jack's house, and while he takes no responsibility for what happens there, he also completely condones some users who are "acting out" while deliberately silencing massive groups of others without much explanation. We'll just say that corporate social media is "too big to fail" and thus becomes both a platform for "acting out" or worse, but there's the overwhelming financial incentive for the platform as a whole to continue so there's no way to stop it except to step away and do your own thing. We'll empathize with Jack here and say that he has created a problem that he is unable to solve, solve it for him, and then make it so simple that he can implement it himself for his future platform when he decides to leave the old platform himself.
other federated social networks are just Jack's house, but with Oauth instead of noauth. This means that your messages may be modified anywhere along any bridge between any network!
message boards that allow everyone to communicate without any authentication can be abused by DDoS attacks and outright abusive communicators -- forcing creative communication back onto corporate channels or outright silencing creative culture.
We want to make doing your own thing as easy and interoperable as possible while also providing security guarantees. To do this, we need to make this an afternoon implementation project instead of some big thing that will get us lots of green dots on MicrosoftCodeHub.
My solution is: a ~. Yup, a tilde.
You must bring:
First generate a public/private keypair and seperate it with a ~. We leave off the first ~ so that we know just by looking at the message that we shouldn't be pasting it into public. So your publickeypair may be:
Messages are base64 strings seperated by tildes:
When you unpack the signature, we recommend that you append it to the rest of the message using more tildes:
The reason we put
<msg> last is that msg may contain a tilde -- so we stop splitting tildes after the first four.
I think this would make the message format flexible enough that you could construct it yourself with available tools in any programming language, and also make it possible to communicate the messages using any protocol.
Now you're probably at this point saying: WHY TILDES? The reason is that we want these messages to exist on a single line of text within a string, so as to make it incredibly easy to send them across any protocol.
The message format is so simple that we only need to detect one tilde, to try and open the message (discarding the rest of the tildes if we want to). If there are four tildes then we can either assume the message is already open and verify it, or it's being communicated out of bounds and we only have access to verification tools via copy-and-paste.
This is how a sample message would look:
And with the signature opened this is how it will look:
And you might bring any hashing algorithm that you want to include this message in a database:
And then you might access this database using an application that iterates over the database.
You might render a page that contains all of the messages, or you might request only a few via communicating that you only want a certain sequence range.
How you use the ~Protocol is up to you. As far as we know it's compatible with all existing digital systems, and may be used over all networks.
If you want to use our example app please first type
npm install and then use the command
node bin 'Hello World'
To generate a new keypair and publish your first message. To decode a message try:
node bin ~QLWmGTLxkksUIuN4IJbyJNHTPaEFEQdJGCPIHpGAXGw=~n+rq7xWaB2iTdwCE66ko71iELgaOybPRN8cA3TwUU2NKNyciBZNmCMsDD7vJo7Kngo4rU0HOoRnpNR4j3joAAUhlbGxvIFdvcmxkfjE1ODExOTI2MDM2MzM=
nick@homeserver is hardcoded right now!