Spring '83 Working Group Darius Kazemi RRFFCC: DFK-1 Tiny Subversions Category: Informational 11 June 2022 Hi Robin, First time caller, long time listener. The Spring '83 protocol is a confluence of many things that interest me. Early RFCs and Jon Postel's work in particular are a huge inspiration to my work on federated social media protocols, and I love the idea of human- scale software and protocols generally. The whole thing seems re- ally cool. I have some experience reviewing RFCs, as I did a yearlong blog project where I wrote about each of the first 365 RFC documents. I also maintain a federated social media server, so I can bring the server operator's perspective to the mix. I am mostly point- ing out potential pain points here, so please assume that any- thing I'm not commenting on is an enthusiastic "wow this is cool!" WHY A DIFFICULTY FACTOR? The spec is not clear about why a difficulty factor is needed. According to the spec the difficulty factor is in place is to en- force the 10M board limit. The immediate question for the reader is: why do this with a difficulty factor and not simply require that the API returns an error code when COUNT(*) FROM BOARDS is 10M? I had to ponder for a bit why you went for this--is the purpose to prevent spam? It seems like the way it's set up, spammers would have an easy time publishing to a realm in its early days, which seems like a way to kill the value of a realm right from the start! Why MUST (in the RFC-2119 sense) it "cost" more to publish to an almost-full realm in the first place? The spec seems really per- missive in all other respects and it seems a bit out of place. I tried to come up with more reasoning and the best I could deter- mine is that it's a cheap way to maintain consensus about how best to use hard drive space between all servers that belong to the same realm. Basically every server operator in a realm agrees that this exponential difficulty is going to be the ONLY gating factor on what gets published (I will address this a bit more be- low too). This is a lot of speculation and head-scratching required of a reader. My ultimate ask here is that, regardless of whether I am right or not in my above assessment, you explain the WHY of the difficuty factor in more detail than we currently see in the spec. The current explanation, that it is to enforce the 10M board size, is trivially countered by the simple counting example of enforcement I provided earlier. PROTOCOL-LEVEL MODERATION IS NEEDED There needs to be, at the very least, a way to federate de-publi- cation and key revocation through the gossip protocol. If someone publishes something that violates, say, a code of conduct for a realm, there must be a way for this violation to federate and for servers to take some action. That action may also be specified in the Spring '83 spec, or maybe not. You could leave this up to the implementors of individual servers (as you rightly leave many other things) but I think it's a huge mistake to do so at LEAST at the key revocation level. The reason I think key revocation in particular MUST be federated is that a realm could consist of multiple different server *im- plementations*. As long as they all follow the spec, any given server could technically interoperate with any other server. There may be social reasons to have a realm of all one implemen- tation of server, but as far as I can tell the "spirit of '83" (so to speak) is pretty free-wheeling. Now consider: if different server implementations offer different ways to monitor and manage content violations, there needs to be *some* way on the protocol level for the consquences of those violations to be federated. A key revocation notification seems like the most atomic-level con- sequence and makes sense as the piece of this puzzle that is specified in the spec. One could imagine Spring '83 implementa- tions that have a warning system in place or whatever, but those would be implementation specific and outside the scope of Spring This also implies a means for reporting content that violates the social rules of what is allowed to be posted on a realm. The op- erators of a realm could simply say "contact us at [blah] if you see content that violates our policies", much like they coordi- nate the contents of the realm's YAML membership file. That's a brittle solution, though. I think it's brilliant for *joining* a realm, but is not going to cut it for content moderation. The op- erators could also implement their own API layers for reporting much like they would for say, paid subscriptions or whatever else they want to add. But it is worth considering: is key revocation the *only* message about the behavior of a publisher that you want to support on a specification level? Ultimately I think that a protocol that is concerned enough with hard drive space to implement cryptographic limitations for gain- ing the RIGHT to publish to a network of hard drives needs to give equal thought and weight to the potential LOSS of that right. I believe the minimum requirement here is federated key revocation, but I think there could be room for other moderation- focused messages in the spec, too.