Past board validity

[royragsdale]

The board acceptance criteria for time state it will be rejected if "the element's datetime attribute contains a timestamp more than 22 days in the past" (1).

Recommendation: change this criteria to instead be pegged to the server's TTL, or fix the TTL for everyone at 22.

This is based on the observation from #10 that "a board must hold its place, with a timestamp, or it can trivially replaced by an old copy of itself." (https://github.com/robinsloan/spring-83/issues/10#issuecomment-1171472703) and the general attack vector that if there is a gap between board expiration (TTL) and PUT acceptance (past validity), an attacker could re-submit previous boards. @motevets captures it well here https://github.com/robinsloan/spring-83/issues/10#issuecomment-1171454259

Example (under the current spec):

• Say a server has a TTL of 7 days.
• A client posts a board (B0) on day 0, and a board (B5) on day 5.
  • An attacker saves B0.
• On day 12, B5 is expired due to TTL, nothing is "holding it's place"
• The attacker is now able to submit B0 at any point until day 22 (the past board validity point) and revive the old overwritten board without the knowledge or intent of the publisher

This violates the aspiration of predictability. "Predictable. This means boards holds their place, maintaining a steady presence."

It would seem that all servers in a realm then need to agree on a TTL as well, or else this is still be a gap.

Ideas:

1. Peg board PUT validity to the TTL (e.g rejected if older than the TTL), and realms share a TTL
2. Remove configurability of the TTL and just have it fixed at 22 days, similar to the board size, it's just an immutable fact of life in the springiverse

I think 2 is simpler, but probably am missing some of the intent of the TTL (beyond liveness and storage considerations) and why it might be desirable to have it be configurable.

p.s. why 22 ? it's a magic number, but what kind of magic?

[robinsloan]

This is a great recommendation. To clarify, the intent is 100% about storage considerations; in a world of board federation/circulation, the TTL is one of the few levers a server operator has to lighten the load.

That said, there are tradeoffs, as evidenced by the scenario you've outlined. It's possible I have been over-sensitive, in all my thinking, to compute and storage resources. Even a wildly popular Springiverse is a pretty compact digital object.

It might be appropriate to just fix the TTL; I'll think about this a bit more.

Oh, and, 22 is definitely a magic number -- gleaned from the byte limit, 2217, which feels like a nice resonance, and it happens to be three weeks and a day, a nice length of time. Anything less than 14 days felt too short, considering the protocol's spirit, and 28 days felt too clinical.

[royragsdale]

Absolutely, happy to noodle on this.

Thank you for the clarification. In this case, I think that simplifying and just having a fixed TTL of 22 is preferable. As with the difficulty factor, it would seem that a server moderator has plenty of ability to directly moderate storage considerations without resorting to an indirect measure like accelerated expiration.

Also, thank you for the explanation on the 22! A nice bit of resonance, kind of the minimum heartbeat frequency of the protocol.

[njbennett]

My instincts are based on versioned, centralized, and proprietary systems so they're somewhat suspect in this case but--

Since there's already some discussion of a "Spring84" protocol later, I'd strongly advocate for hardcoding the TTL to 22 for now. I expect the system's behavior at "wildly successful" scales to be surprising, and less configuration will make that system easier to reason about. A system that's easier to reason about will be easier to improve if & when it begins causing problems for individual server operators due to scale.

The main case where this isn't true is when a decision is locked in or hard to change, and I don't think this particular aspect of server behavior has that property. Changing the TTL on a running server is definitely client-impacting but that's true whether the server starts with the capability of changing its TTL or if that capability gets added later.

Could be wrong, though -- this is definitely at the edges of my professional expertise.

[makew0rld]

Personally I vote for the TTL to be realm-configurable. This solves any tricky issues with data races or attacks, but allow for different realms to have different interesting properties - one that's super fast paced, one where boards can last for months, etc.