www.makeworld.space

Thoughts on the Spring '83 protocol draft

Jun 14th, 2022
by makeworld

Right this morning when I woke up, before I even had a glass of water, I started reading a blog post by Maya discussing a new protocol. I was immediately intrigued, and starting reading the original post, Specifying Spring ‘83. After reading through the blog post, I excitedly moved on to the actual spec draft. I was amazed. Possibly because it was the first thing my brain had processed all day, but still, I really loved the idea. What follows is some thoughts on the spec draft, to add to the ongoing discussion.

I am reviewing the spec from commit 1a37b2f, which is from June 10, 2022.

Design

Various protocol design comments below.

YAML

Please don’t use YAML for the peer list. YAML is not great. A simple JSON list would be better. A separate Markdown file can provide human-readable metadata if needed.

Key rotation

The key rotation scheme is definitely interesting. I like the idea of limiting the damage a leaked key can do, similar to TLS cert renewal. However I think the user experience of having to generate a new key every two years and tell all your friends about it is quite bad, and will make people wonder why they have to do this. I get the idea of culling old followers, but the reality is that this is a one-way protocol will no follow notifications, so the effect of this culling won’t be felt.

One solution is to have the majority of people not actually manage their own keys, but that doesn’t feel great either. I think it would probably be better to just let keys stick around with no expiry. This seems to have worked out okay for Scuttlebutt.

Server-to-server communication

First off, it’s not explicitly mentioned that one server sending a board to another triggers that server to send the board to others, etc. It seems obvious this is the case in retrospect, but I think it would be good to mention to make the gossip nature of this part of the protocol clear.

More importantly, I think there is a large issue with this push-only server communication. Imagine the following scenario:

  1. Bob publishes a new version of his board.
  2. Server A receives and stores this version.
  3. Alice can view Bob’s latest post using Server A, and all is well.
  4. Server A goes offline, perhaps for a day or two.
  5. Bob publishes a new version of his board. Server A never receives this update.
  6. Server A comes back online.
  7. Alice uses Server A, and thinks she is getting Bob’s latest post, but she is not.

Obviously it’s impossible to always have perfect consistency, and in the scenario described things would eventually work out, but I still think this is a problem. It is easily solved by speccing a server-to-server pull mechanism as well.

This could be something like:

On server start up and at every interval X, do a GET request for each key this server is aware of to two random servers in the realm.

X should be something long like several days.

This would require all servers to allow GET /<key> requests for anyone, which goes against a later part of the spec:

Servers are not obligated to provide this endpoint for all requesters; they might provide it only to users of a particular client, or only to users who have paid for access, or according to any other scheme.

I get the idea behind this, and so I’m not sure how to reconcile it with what I’ve said above. I lean towards requiring all servers to be open to everyone. This has the advantage of making all clients server-agnostic as well, if they want to be.

Finally, I’m no gossip protocol expert, but it seems like it would be easy for servers to be missed when only 5 are getting selected at random. It would be nice for someone who knows the math for these things to be able to explain the probability of servers being left behind.

Difficulty factor

The difficulty factor stuff is definitely cool. But I’m not sure if increasing difficulty only once most boards are used up makes sense. Without a single point-of-truth like a blockchain, this can introduce data races, as others have pointed out. Additionally, due to TTLs board will be disappearing all the time, so there would need to be literally millions of active users for the difficulty to become meaningful.

What if this difficulty factor was baked in from the start? Preventing spam from the inception of the protocol/realm seems better than only near the end. For example the spec could define a difficulty based on a numerical threshold, or keys needing to have X preceding zeros, etc. Whatever works in a way that doesn’t weaken Ed25519 (!!). That number would be picked to have a meaningful difficulty for modern computers, taking maybe 10 minutes or more.

Client -> Server interaction

I understand this is a draft, but I just thought I’d mention that the spec doesn’t explain how clients are supposed to talk to servers, beyond the APIs available.

For example, when a client user updates their board, what servers does that client send the new board to? Just its favourite one? A random selection from the realm list? Etc.

One section of the spec alludes to clients maintaining lists of trusted servers, so I expect details on all this are coming. Looking forward to hearing them!

If the signature is not valid, the client must drop the response and remove the server from its list of trustworthy peers.

“The agony and ecstasy of public key cryptography”

I love this section. Cryptography is beautiful magic, and I’m glad to see it used and appreciated here.

Nitpicks

Here are some small comments or questions I have about the spec. They don’t change my feelings overall.

Odds and ends

Here are few thoughts that popped into my head while reading, I couldn’t fit them into other sections.

Conclusion

I’m quite excited about this protocol, and will be following its development closely. As usual, I’d like to dive in over my head and start developing a client and server, but I will hold off this time, until the spec is a bit more finalized, and likely until Robin releases his software as well. I’ve got my hands full working on a secret DNS project for now anyway 😉. But I will definitely be participating when the time comes. Having a little space of HTML to share, with strict limits — it sounds like an awesome way to experiment and get creative. I look forward to it!