On Tue, Jun 20, 2023 at 2:02 PM juan via agora-discussion <
agora-discussion@agoranomic.org> wrote:

> 4st nomic via agora-discussion [2023-06-20 13:49]:
> > On Tue, Jun 20, 2023 at 1:34 PM juan via agora-discussion <
> > agora-discussion@agoranomic.org> wrote:
> > > Ok. I get it. What you are trying to do is set up some structure that
> > > tracks what events happen relating to some scope of values, all
> depending
> > > on that switch. So, in a sense, you are building a kind of dependency
> > > graph made up of transactions involving switches, assets, etc.
> >
> > […]
> >
> > Sure, that seems like an addition, but that makes 100% total sense to add
> > to the self-contained gamestate with retroactive capabilities. Like, use
> a
> > time crystal, remove an event you did. Or add one. Whatever. But mostly
> > just trying to go for yeah, that dependency graph aspect where one single
> > thing changes (EG unfathomability) and then that causes cascading changes
> > to everything that depended on it.
> >
> > So yes, maybe modelling it as a dependency graph might work better! There
> > are two sides to this: the real-time and the pseudo-time. The real-time
> > game (IE the rest of Agora) shouldn't change, so that officers duties and
> > roles and such are simply and easily determinable. The pseudo-time
> > gamestate is the one tracked by the Phantom (or whatever), and is the
> > complex game/minigame going on. That boundary is important, and is
> enforced
> > as power=3 (which I would like to retain if at all possible)
> >
> > (IMO making it too abstract makes it unusable or easily exploitable, when
> > it seems complicated enough as is. I am thinking if there is multiple
> > switches, maybe, but I really like having only one single thread of
> events
> > (one timeline). Maybe some of those events can't happen, or have
> different
> > effects, but at least there's only a single chronology (which simplifies
> > the understanding in that respect). That's just my opinion though,
> mostly I
> > just want to get something off the ground so that there is this one thing
> > you can change retroactively, and that changes more thing based on just
> > that one thing. One single weakness in the timeline.)
> >
> > Also, I'm thinking that maybe the goal is itself a CFJ PARADOX, so it
> > doesn't really need a win con, as the win con will come naturally? Maybe?
>
> I think that, as a general principle, if you want to contain things,
> they must be defined compositionally. That is, define some starting point
> (the switch) and a controlled and analyzable way to extend those. In
> this case, it means specifying exactly WHAT can be tainted, and how
> it behaves.
>
> What I would suggest is a way os specifying actinos that indicates
> what happens to different values as you do them/as they happen. One
> problem is that of reference, like the recent one with the recursion
> stone. So, if I say “I gain 3 potatoes by corruption” is that right?
> How do you restrict actions so only “I gain an Unfathomable amount of
> potatoes” works? And then… what is that amount? The amount at the
> time of announcing or at the time of reevaluating?
>
> So, the thing is: I believe you need to create some kind of token for
> events (documents, entities with certain properties, etc) and have
> clear rules on how to resolve references within them. And there are
> two kinds: references to tainted values (hard to encode) and
> references to untainted values (even harder! to what value are you
> refering?).
>
> --
> juan
>

Your ghost, and reversible actions, I love that interesting way to think
about it. It is a different game where you store potatoes in the past by
eating them and then thereby you have them in the future if you have the
time crystals. But it is not the same itch... however, you have a good
point... define it compositionally.

So here, instead, we just track the events as arbitrary computations. They
have a condition (to allow for branching), and a result, and an address (to
determine ordering). Since the condition and results are arbitrary (but at
power 1), this should allow for a lot. However, since they can be destroyed
easily (agoran consent) and created slightly harder (without 3 objections),
and the computation itself requires 3 support, it should be straightforward
to run.
----
Computations are tracked by The Dev. Computations have an address that is
any real number that is not the address of any other existing computation,
input, which is any text, and output, which is any text.
Once per week, any player CAN, with 3 support, run the program. In a timely
manner from when the program was run, The Dev SHALL publish the results of
the program. To get the results of the program, in ascending order of
address, for each computation, take the input as a statement. If the
statement is reasonably determinable to be unambiguously true, then the
output is rules text at power 1 for the rest of the run of the program. The
results of the program are evaluated at the time the program is run, even
if the publishing happens later. The Dev SHALL include each input
statement's truthiness in the published results of the program. The Dev
SHOULD ping any officers if it affect eir report. Any player CAN, without 3
objections, create a computation with any address that is not the address
of any other existing computation, any input, and any output. Any player
CAN, with Agoran consent, destroy a computation.

Add a computation with address 0. Its input is "True." Its output is
"Unfathomable is a switch with any value publicly announced by the player
who ran this program."

-- 
4ˢᵗ
Deputy (AKA FAKE) Herald
Uncertified Bad Idea Generator

Reply via email to