clevinson/radicle-ramble.txt

## radicle-ramble.txt
16:11 <corlock_> in the prospective "rad-p2p" world, is it possible for a user to advance the statemachine of a
  radicle chain that is not theirs and just publish the result (prev chain head + some new radicle expression)
  to ipfs ?
16:11 <jameshaydon> yes it is
16:12 <jameshaydon> but it does depend on the `eval` in that chain. If the `eval` has required that all new inputs be
  signed with a private key that the user doesn't have, then they are unable to do this.
16:12 <corlock_> yes ofc
16:13 <corlock_> but technically teh user could still publish that as a new chain state
16:13 <corlock_> it would just be one that results in an error if the full chain is evaluated
16:13 <corlock_> righ t?
16:27 <jkarni_> corlock_: Anyone can publish anything to IPFS+IPNS if they have the appropriate IPNS keys - it could
  be a cat video
16:27 <corlock_> i was asking specifically about within our rad-p2p write pipeline
16:28 <jkarni_> corlock_: hm, I'm still a little unclear on the question, then...
16:34 <hxrts> if the state machine specifies updates be signed by parties A or B to advance, and then party C
  publishes an update without a signature from A or B, then the update would be invalid
16:42 <cloudhead> yup ^
16:43 <cloudhead> you can publish an invalid chain entry, but no one will be able to materialize a state from it
16:43 <cloudhead> so it's "off-protocol" so to speak
16:44 <cloudhead> only if the eval function of the previous entry allows the state transition of your "fork" is
  the forked chain valid
16:44 <cloudhead> corlock_: ^
16:48 <cloudhead> so in the case of a single-writer chain, only the owner would be able to create a fork
17:56 <corlock_> ja makes sense
18:23 <corlock_> from this point of view, my mental model benefits from thinking of the radicle ecosystem as a
  forest of "radicle trees" rather than chains with single owners. Where a "node" in this forest is simply a pair
  of {"some radicle expression", "pointer to previous node"}, and the concept of a "machine state" is resolved by
  starting with any leaf node (potentially resolved via an ipns pointer), following to the root, and then
18:23 <corlock_> evaluating from root back to leaf.
18:38 <cloudhead> yeah that makes sense more or less, however trees have branches and radicle state machines don't
  always
18:40 <cloudhead> I'm not sure the tree analogy is helpful because of that
18:40 <cloudhead> whether a particular rsm ends up looking like a tree, or a chain is a property of the rsm, not
  radicle
18:41 <cloudhead> does that make sense?
23:00 <corlock_> yes that makes sense. Still I find it clearer to describe chains as a special case of an rsm tree,
  where the eval restricts to only allow from one user, as opposed to thinking that rsm's are "chain-like" by default.
  Since the default radicle eval has no such restriction on input
	16:11 <corlock_> in the prospective "rad-p2p" world, is it possible for a user to advance the statemachine of a
	radicle chain that is not theirs and just publish the result (prev chain head + some new radicle expression)
	to ipfs ?
	16:11 <jameshaydon> yes it is
	16:12 <jameshaydon> but it does depend on the `eval` in that chain. If the `eval` has required that all new inputs be
	signed with a private key that the user doesn't have, then they are unable to do this.
	16:12 <corlock_> yes ofc
	16:13 <corlock_> but technically teh user could still publish that as a new chain state
	16:13 <corlock_> it would just be one that results in an error if the full chain is evaluated
	16:13 <corlock_> righ t?
	16:27 <jkarni_> corlock_: Anyone can publish anything to IPFS+IPNS if they have the appropriate IPNS keys - it could
	be a cat video
	16:27 <corlock_> i was asking specifically about within our rad-p2p write pipeline
	16:28 <jkarni_> corlock_: hm, I'm still a little unclear on the question, then...
	16:34 <hxrts> if the state machine specifies updates be signed by parties A or B to advance, and then party C
	publishes an update without a signature from A or B, then the update would be invalid
	16:42 <cloudhead> yup ^
	16:43 <cloudhead> you can publish an invalid chain entry, but no one will be able to materialize a state from it
	16:43 <cloudhead> so it's "off-protocol" so to speak
	16:44 <cloudhead> only if the eval function of the previous entry allows the state transition of your "fork" is
	the forked chain valid
	16:44 <cloudhead> corlock_: ^
	16:48 <cloudhead> so in the case of a single-writer chain, only the owner would be able to create a fork
	17:56 <corlock_> ja makes sense
	18:23 <corlock_> from this point of view, my mental model benefits from thinking of the radicle ecosystem as a
	forest of "radicle trees" rather than chains with single owners. Where a "node" in this forest is simply a pair
	of {"some radicle expression", "pointer to previous node"}, and the concept of a "machine state" is resolved by
	starting with any leaf node (potentially resolved via an ipns pointer), following to the root, and then
	18:23 <corlock_> evaluating from root back to leaf.
	18:38 <cloudhead> yeah that makes sense more or less, however trees have branches and radicle state machines don't
	always
	18:40 <cloudhead> I'm not sure the tree analogy is helpful because of that
	18:40 <cloudhead> whether a particular rsm ends up looking like a tree, or a chain is a property of the rsm, not
	radicle
	18:41 <cloudhead> does that make sense?
	23:00 <corlock_> yes that makes sense. Still I find it clearer to describe chains as a special case of an rsm tree,
	where the eval restricts to only allow from one user, as opposed to thinking that rsm's are "chain-like" by default.
	Since the default radicle eval has no such restriction on input