[urbit] Breach

[Philip Monk]

We just performed a voluntary continuity breach. All the old backlog is
reloaded into urbit-meta, so conversation can begin right where it left
off. Anyhow, get rid of your old pier, git pull, make, and get back on the
network.

[c***@gmail.com]

Slightly concerned over snowballing urbit-meta logs. It already takes quite
a bit to replay the chatlog for a new pier, which would become a bigger
problem if we end up with a several month long gap between breaches again.
Is there a point where :talk cuts off the backlog, and only sends the past
couple weeks of chats instead?

Post by Philip Monk
We just performed a voluntary continuity breach. All the old backlog is
reloaded into urbit-meta, so conversation can begin right where it left
off. Anyhow, get rid of your old pier, git pull, make, and get back on the
network.

[yebyen]

I am in favor of this (the current situation, not a change) if only because
I think we don't have a command anymore to play backlog from a specific
date or for a span of time.

Also not least of which because on almost every system I use Urbit on for
other than toy purposes, playing the backlog happens mostly instantly and
is limited only by the speed of my tty. It will seem to pause periodically
to handle some event and then continue printing backlog at record speed.
(This does not make a lot of sense given what I know about Urbit as a
single-threaded process architecture, but...)

I assume it's possible there are some events _in the backlog_ that require
processing, and that's further argument against playing backlog only for
the past few weeks. There might be important state built up in the older,
more historical parts of the talk-chain (this is a deliberate etymological
reference I just made to a block-chain). I'm sure it would be possible to
cherry-pick the state-changing talk events and play them back separately,
but probably not without scanning the whole history of cards first to see
if any of them change any states.

~del

Post by c***@gmail.com
Slightly concerned over snowballing urbit-meta logs. It already takes
quite a bit to replay the chatlog for a new pier, which would become a
bigger problem if we end up with a several month long gap between breaches
again. Is there a point where :talk cuts off the backlog, and only sends
the past couple weeks of chats instead?

Post by Philip Monk
We just performed a voluntary continuity breach. All the old backlog is
reloaded into urbit-meta, so conversation can begin right where it left
off. Anyhow, get rid of your old pier, git pull, make, and get back on the
network.

[yebyen]

Post by yebyen
I assume it's possible there are some events _in the backlog_ that require
processing, and that's further argument against playing backlog only for
the past few weeks. There might be important state built up in the older,
more historical parts of the talk-chain (this is a deliberate etymological
reference I just made to a block-chain). I'm sure it would be possible to
cherry-pick the state-changing talk events and play them back separately,
but probably not without scanning the whole history of cards first to see
if any of them change any states.

... maybe this doesn't make sense given our new jamfile format. I'll wait
for the experts to weigh in though.

[Curtis Yarvin]

There are worse problems than the system being too stable! There are also
worse problems than it taking a little while to create and sync up a new
pier. After all, it's your urbit for a lifetime.

And if it becomes a real problem, it's not that hard to imagine ways to
mitigate it...

Post by c***@gmail.com
Slightly concerned over snowballing urbit-meta logs. It already takes
quite a bit to replay the chatlog for a new pier, which would become a
bigger problem if we end up with a several month long gap between breaches
again. Is there a point where :talk cuts off the backlog, and only sends
the past couple weeks of chats instead?

Post by Philip Monk
We just performed a voluntary continuity breach. All the old backlog is
reloaded into urbit-meta, so conversation can begin right where it left
off. Anyhow, get rid of your old pier, git pull, make, and get back on the
network.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.