First off, I’m very happy you published this. It’s very interesting and it
adds a lot to the discourse. I will now proceed to state why I think it’s a
bad idea. (Upon retreading your post, these amount to explanations of why
concerns c and a are perhaps more serious than you think.)
You haven’t actually solved the gamestate problem, just moved it back a
layer. The problem is that a report is fundamentally a declarative
statement of how things are, and you’re changing that to make it
imperative. This removes the generality of reports, since we have to define
exactly what each report is changing. Switch reports are easy. What about
asset reports? Do they “create, destroy, and transfer assets such that they
are in the manner described”? At that point, you may as well be saying “set
the assets so they are in the manner described”, which doesn’t seem like
much of an improvement over “set the gamestate such that it is in the
matter described”. I really fail to see how this is a particular
simplification? It seems like you’ve made things more complicated, not less
so.
Also, you’re still doing timeline manipulation. Specifically, if I’m
understanding you correctly, you’re causing a timeline divergence. There’s
the timeline where the action is ratified in the future and the timeline
where it isn’t ratified in the future. Worse, no one knows which timeline
we’re on until 4 days after the ratifiable action happens. That means that
any actions that depend on whether the ratifiable action succeeded or not
have indeterminate success. This means that any CFJs about those options
are indeterminate. At any given time, there will be no current summation of
what the game is. Instead, it will be in a superposition of multiple
possible states. This is, frankly, very hard to reason about. While you may
technically be right that it isn’t strictly any more complicated than the
current state of affairs, it would mean that there’s never a right answer
about how the game is at the current moment. It removes our ability to have
a shared idea of how things are now.
Now, onto your advantages.
A) How is “gamestate” poorly defined? I can define it right now. “The
summation of the states of all entities and attributes defined by the
rules.” That definition may have a bug in it, but if so it’s probably
something trivial. Also, how is this a rules simplification? You end up
replacing the ratification mechanics with a separate definition of how each
kind of report can be ratified, which makes things *more* complicated.
Currently, we ratify switches, assets, and the ruleset. I see no reason why
we might not add more classes of ratifiable things; I could certainly see
regulations being ratified. Also, you’re introducing a fiction that a
report is about setting things, when the primary purpose of a report is
description. That’s more confusing, not less so.
B) As explained above, you’re still dealing with multiple timelines. You’ve
just made it so we don’t even know which of those timelines we’re on at any
given time. To my mind, that makes the problem worse, not better.
C) I remain thoroughly unconvinced that this would not, at the very least,
require a high powered enabling rule to define how true future conditionals
work.
-Aris
On Sun, Jul 28, 2019 at 2:19 PM James Cook <jc...@cs.berkeley.edu> wrote:
> Two responses inline...
>
> On Sun, 28 Jul 2019 at 20:20, Kerim Aydin <ke...@uw.edu> wrote:
> > On 7/28/2019 1:03 PM, Aris Merchant wrote:
> > > That may be a reasonable point; I know that tends to be a weakness in
> > > my proposals, although I tried pretty hard not to do it in that one.
> > > Still, I'm not sure I see a much simpler codification of our existing
> > > precedents, especially given that it has to be safe. And I think those
> > > are good precedents which should darn well be codified. If anyone has
> > > simplifications though (including complete alternate approaches), I'd
> > > be happy to hear them. As soon as the safety concerns are dealt with,
> > > I'll see if I can come up with anything simpler myself.
> >
> > I thought playing with "timelines" was a really clever concept actually
> but
> > I got bogged down working my way through various things that work due to
> > precedents, to see if it codified them or changed them (sometimes
> "codifying
> > precedent" makes something rigid and brittle that was formerly flexible
> or
> > could be overturned, so that's the kind of thing I was looking for).
>
> I've been thinking about another option for implementing ratification,
> with the following three possible advantages:
> (a) No need to refer to a poorly-defined concept of "gamestate", and I
> suspect it would generally simplify the rules.
> (b) No multiple timelines. (Like the fixed history model of time
> travel.) I think this is an advantage unless you think the rules
> aren't complicated enough as it is.
> (c) Might not require any high-powered rules to make it work. It's
> just a new definition of "ratifiable action" that rules of whatever
> power could refer to as they please.
>
> I haven't yet tried to write it out, but hope to do so soon, and since
> it's come up, I'll give an outline of my idea:
>
> A "ratifiable" action takes effect at the time it is published, but
> only if at some point in the next N days it is ratified (or some
> similar condition involving the future).
>
> For example, we could make publishing an officer's report into a
> ratifiable action that flips all the listed switches to their listed
> values. Then, we could say the change happens immediately, so long as
> it is ratified in the future according to the usual self-ratifying
> rules.
>
> Between the time when a ratifiable action is published and when it is
> ratified (or some time limit for that runs out, etc) it it may be
> impossible to know whether the action had an effect. At the time the
> actual ratification happens, nothing actually changes, except our
> knowledge of the situation.
>
> Some disadvantages I can think of, and some responses to them:
>
> (a) The uncertainty about the gamestate mentioned in the previous
> paragraph may be undesirable. But, I think the current situation,
> where the gamestate is retroactively changed, is at least as
> confusing.
>
> (b) This may lead to paradoxes. But as with (a), I think we're already
> in that situation. Right now, I can find an action X that I can
> currently take, but that retroactively changes the past so I couldn't
> have taken X, that could be a paradox; twg tried to do this when we
> fixed dependent actions. The solution is to be careful about when we
> allow ratifiable actions.
>
> (c) I claimed we can get rid of references to "gamestate", and
> justified it by giving an example about switches and officer's reports
> where the word "gamestate" didn't come into it. But if we want to keep
> the ability to ratify an arbitrary document (e.g. ratification without
> objection), we'd need to keep the wording involving gamestate.
> Personally, I'm okay with removing the flexibility to ratify an
> arbitrary document, and replace it with a fast-track proposal process.
> Instead of ratifying {there are no spaceships}, you would simply
> fast-track a proposal: {destroy all spaceships}. If it's really
> important that it happen at the time it's originally published, you
> could turn it into a ratifiable action as outlined above, so as long
> as it's approved soon enough in the future, it takes effect when it's
> published.
>
> (d) Currently, it's possible to ratify a document listing an effective
> date before it was published. This new system would not allow that. Is
> that a big loss?
>
> > > Speaking of those safety concerns, I'm a tad peeved that several
> > > people voted against the proposal on the basis that "this might be
> > > dangerous", including you, and yet no one seems to be able to explain
> > > to me exactly what danger is involved so that I can mitigate it. Yes,
> > > it might be dangerous, that's a dangerous area of rule making, and
> > > it's quite fair to have high standards. That being said, I'd like to
> > > know exactly what the standards are so that I can meet them. At this
> > > point it feels like people are saying "there might be problems"
> > > without providing anything approaching a direction I can go in to
> > > persuade them otherwise.
>
> Sorry, I was mostly just scared by others' comments with that one. I
> didn't find time to do a second reading, and even if I did and found
> nothing wrong, I don't feel experienced enough to shrug off a concern
> from G. that it could seriously mess up the game.
>
>
> --
> - Falsifian
>
