Robin Sloan is one of the most interesting thinkers alive and he just released a specification for a new social media protocol. You can read his blog post or the RFC.

He asked for feedback, these are some fairly rough notes after thinking about it a bit. If you are interested in this, feel free to send me further thoughts and comments!

Key Expiry

I like the concept of key expiry, and I love that the expiry date is human-readable in the key and also serves as a non-trivial bit of abuse mitigation. Elegant! But I worry about the mechanics of having 50% of all keys expire at the same instant. I suppose responsible clients can rotate keys throughout the year, but if they don’t, there will be a rush of new PUTs on January 1, which seems potentially troublesome. And on the other side readers will lose half their boards overnight.

Difficulty Factor

Millions of PUTs on January 1 raises another question about race conditions with the difficulty factor. Imagine the following interaction:

  • Client: GET/
  • Server: difficulty factor is X
  • Client: computes <key> passing X
  • Client: PUT/<key>
  • Server: difficulty factor is now Y>X, <key> does not pass Y.

This seems to be wasteful of client compute (not a huge deal) but also be just kind of annoying to deal with as the author of a client. I haven’t done any calculations or simulations to see how realistic this is or boudn how big a problem it would be.

Actually this raises a potentially bigger problem: if I generate a key that just barely passes the difficulty factor for server X, and X accepts it, it might be the case (especially after the 5 minute buffer before propagation) that it doesn’t pass the difficulty factor for any other server! So servers would not necessarily come to agree on the list of keys, right? What is a server supposed to do when their propagation to another server is rejected?

The realm

If I understand correctly, the realm is defined by a single URL on the public internet, which provides a YAML list of servers. There should be a cool name for this document as the foundational component of the realm!

And then as a client or server or user, you need to trust whoever controls the content at that URL because they control the servers. This is great – so minimal!

A question: do servers have any obligation to use the latest list of servers in the realm when they propagate? I don’t see that in the spec, but it does seem sensible. I’m not sure if there’s any good way to chec/enforce it, though.

IIUC, all servers in the realm must respond to all PUT/s and GET/s, but not GET/<key>. I like the idea of being open to servers trying different schemes for access! If I’m writing a client, and I want to know which servers I can GET/<key> from, is there any way to do it besides googling? Perhaps the realm YAML could have more metadata about each server, at least a field for the server’s homepage/README?

Related, I’m interested in the idea of discovery here:

  • servers and clients find servers in the realm YAML – good, one canonical place for this.
  • users find clients offline – seems fine.
  • users find keys offline – seems fine to not have this built into the protocol.
    • clients may recommend keys to users – very natural.
    • servers must not enumerate keys – does this mean they cannot output any keys other than what were requested? no “key of the day”? no recommendations? I understand and like the spirit of this, but … are you imagining that the realm guardian just need to be on the lookout for this and enforce it? (and of course some won’t.) Are there other protocols that forbid sharing extra information like this?

If we are friends, and I want to share a key with you, I need to share with you both the realm and the key, right? Would it be helpful to have a single canonical way to do that?

Since all realms should implement the same key validation logic, a key that is valid in one realm is valid in all smaller realms – is this desirable? is there some way to incorporate the realm URL into the validation with a hash that prevents it?

Boards

I’m most out of my depth here, but is an “HTML fragment” well defined? If so are there easy ways to validate them in common programming languages?

And I see that clients should prevent resource loading and JS execution with a Content Security Policy – I don’t know anything about these, is there a particular CSP that clients should use? Is there enough flexiblity in CSPs that different clients could use different CSPs to fulfill this? Would it be easier to say exactly what the CSP needs to look like?