[urbit] Fleshing out an approach to marked %post support for %eyre and %ford

[Jeremy Wall]

http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post

opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
***@marzhillstudios.com

[Anton Dyudin]

As an aside, in ford-ren %boil has been changed to accept an explicit
`coin` argument instead of a "virtual path"; this does not significantly
change any of the questions, which are already in those terms.

The coin format makes sense for (eventual) ford scry: I believe the planned
format is .^(%fr /=desk=/[~(rend co args)]/[desk]/{path}). The decoding
/from/ coin has to happen in the hook, but could contain arbitrary logic: I
can imagine a fuel-png, for example, that expects an image atom along with
the eyre query string / auth info / etc.

The latter, in turn, have to at least be consed by eyre onto whatever the
post body is translated to; though I suppose the translation part could be
moved to mar/mime++grow++coin. But I think the correct answer, for both
this and app webhooks that might care about headers, is something in
mar/httr that produces a (pair target-mark ,source-cask=[%mime mime]),
which is then further converted to the target mark.
In the stateless post case, this can be further cast to %coin and consed
with the auth data; via a gate stuck in a silk by eyre, so in a sense
involving both.

Post by Jeremy Wall
http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post
opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
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.

[Jeremy Wall]

Post by Anton Dyudin
As an aside, in ford-ren %boil has been changed to accept an explicit
`coin` argument instead of a "virtual path"; this does not significantly
change any of the questions, which are already in those terms.
The coin format makes sense for (eventual) ford scry: I believe the
planned format is .^(%fr /=desk=/[~(rend co args)]/[desk]/{path}). The
decoding /from/ coin has to

I do not know what ford scry is for. Right now it appears to be nothing?
What is it's purpose and how/why does it impact this?

Post by Anton Dyudin
happen in the hook, but could contain arbitrary logic: I can imagine a
fuel-png, for example, that expects an image atom along with the eyre query
string / auth info / etc.

So if I'm following you eyre needs to do the decode body -> encode to coin
part?

Post by Anton Dyudin
The latter, in turn, have to at least be consed by eyre onto whatever the
post body is translated to; though I suppose the translation part could be
moved to mar/mime++grow++coin. But I think the correct answer, for both
this and app webhooks that might care about headers, is something in
mar/httr that produces a (pair target-mark ,source-cask=[%mime mime]),
which is then further converted to the target mark.
In the stateless post case, this can be further cast to %coin and consed
with the auth data; via a gate stuck in a silk by eyre, so in a sense
involving both.

Are you suggesting that eyre provide a gate to decode the coin to correct
format here? Or am I misunderstanding?

I should note that my thoughts have not yet considered that app webook case
by which I assume you mean the poke-<mark> arms on a %gall app. Those seem
"okay" for now the way they are if a bit clumsy. But the clumsiness is more
caused by what the %gall machinery requires than the %eyre api. I've really
only considered the stateless hook case here.

Post by Anton Dyudin

Post by Jeremy Wall
http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post
opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
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.

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com
***@marzhillstudios.com

[Anton Dyudin]

Post by Jeremy Wall

Post by Anton Dyudin
As an aside, in ford-ren %boil has been changed to accept an explicit
`coin` argument instead of a "virtual path"; this does not significantly
change any of the questions, which are already in those terms.
The coin format makes sense for (eventual) ford scry: I believe the
planned format is .^(%fr /=desk=/[~(rend co args)]/[desk]/{path}). The
decoding /from/ coin has to

I do not know what ford scry is for. Right now it appears to be nothing?
What is it's purpose and how/why does it impact this?

Wait oops, .^(%fr /=desk=/[~(rend co args)]/[*mark*]/{path})

Right now it is unimplemented; the eventual plan is to be able to request
e.g. /fr/~zod/home/11/~/html/web/foo, where foo.md is a wile in ~zod's
/web, as data from hoon.

Post by Jeremy Wall

Post by Anton Dyudin
happen in the hook, but could contain arbitrary logic: I can imagine a
fuel-png, for example, that expects an image atom along with the eyre query
string / auth info / etc.

So if I'm following you eyre needs to do the decode body -> encode to coin
part?

Eyre needs to do the query string -> coin part, and the client needs to
decode the aggregate result. The decoding and re-encoding should happen in
the marks, since there isn't a closed number of cases; but at some point
the coin-encoded post data and eyre metadata need to be consed together.

Post by Jeremy Wall

Post by Anton Dyudin
The latter, in turn, have to at least be consed by eyre onto whatever the
post body is translated to; though I suppose the translation part could be
moved to mar/mime++grow++coin. But I think the correct answer, for both
this and app webhooks that might care about headers, is something in
mar/httr that produces a (pair target-mark ,source-cask=[%mime mime]),
which is then further converted to the target mark.
In the stateless post case, this can be further cast to %coin and consed
with the auth data; via a gate stuck in a silk by eyre, so in a sense
involving both.

Are you suggesting that eyre provide a gate to decode the coin to correct
format here? Or am I misunderstanding?
Zuse needs to provide the gate, or it could be in a library. Though it

doesn't strictly have to be "decoding" per se: post-`factor`, the coins are
executed as hoon, so the decode gate could be as simple as |=([bem=beam
png=my-custom-type eyre-data=*] png)
I should note that my thoughts have not yet considered that app webook case

Post by Jeremy Wall
by which I assume you mean the poke-<mark> arms on a %gall app. Those seem
"okay" for now the way they are if a bit clumsy. But the clumsiness is more
caused by what the %gall machinery requires than the %eyre api. I've really
only considered the stateless hook case here.

That is indeed what the webhooks do; they are not directly relevant to the
question here, except in that they would also benefit from the
httr->cay=cage->/mar/[p.cay]++grow++coin flow.

Post by Jeremy Wall

Post by Anton Dyudin

Post by Jeremy Wall
http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post
opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
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
For more options, visit https://groups.google.com/d/optout.

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com

[Jeremy Wall]

Post by Anton Dyudin

Post by Jeremy Wall

Post by Anton Dyudin
As an aside, in ford-ren %boil has been changed to accept an explicit
`coin` argument instead of a "virtual path"; this does not significantly
change any of the questions, which are already in those terms.
The coin format makes sense for (eventual) ford scry: I believe the
planned format is .^(%fr /=desk=/[~(rend co args)]/[desk]/{path}). The
decoding /from/ coin has to

I do not know what ford scry is for. Right now it appears to be nothing?
What is it's purpose and how/why does it impact this?

Wait oops, .^(%fr /=desk=/[~(rend co args)]/[*mark*]/{path})
Right now it is unimplemented; the eventual plan is to be able to request
e.g. /fr/~zod/home/11/~/html/web/foo, where foo.md is a wile in ~zod's
/web, as data from hoon.

Post by Jeremy Wall

Post by Anton Dyudin
happen in the hook, but could contain arbitrary logic: I can imagine a
fuel-png, for example, that expects an image atom along with the eyre query
string / auth info / etc.

So if I'm following you eyre needs to do the decode body -> encode to
coin part?

Eyre needs to do the query string -> coin part, and the client needs to
decode the aggregate result. The decoding and re-encoding should happen in
the marks, since there isn't a closed number of cases; but at some point
the coin-encoded post data and eyre metadata need to be consed together.

This aligns with my own suspicions then. the payload then would look
something like a coin encoded [p=mark q=tape] that is then consed together
with the rest of the eyre metadata.

Then the hook can call the appropriate fuel-<mark> gate to decode the
expected result.

Post by Anton Dyudin

Post by Jeremy Wall

Post by Anton Dyudin
The latter, in turn, have to at least be consed by eyre onto whatever
the post body is translated to; though I suppose the translation part could
be moved to mar/mime++grow++coin. But I think the correct answer, for both
this and app webhooks that might care about headers, is something in
mar/httr that produces a (pair target-mark ,source-cask=[%mime mime]),
which is then further converted to the target mark.
In the stateless post case, this can be further cast to %coin and consed
with the auth data; via a gate stuck in a silk by eyre, so in a sense
involving both.

Are you suggesting that eyre provide a gate to decode the coin to correct
format here? Or am I misunderstanding?
Zuse needs to provide the gate, or it could be in a library. Though it

doesn't strictly have to be "decoding" per se: post-`factor`, the coins are
executed as hoon, so the decode gate could be as simple as |=([bem=beam
png=my-custom-type eyre-data=*] png)
I should note that my thoughts have not yet considered that app webook

Post by Jeremy Wall
case by which I assume you mean the poke-<mark> arms on a %gall app. Those
seem "okay" for now the way they are if a bit clumsy. But the clumsiness is
more caused by what the %gall machinery requires than the %eyre api. I've
really only considered the stateless hook case here.

That is indeed what the webhooks do; they are not directly relevant to the
question here, except in that they would also benefit from the
httr->cay=cage->/mar/[p.cay]++grow++coin flow.

Post by Jeremy Wall

Post by Anton Dyudin

Post by Jeremy Wall
http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post
opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
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
For more options, visit https://groups.google.com/d/optout.

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com
***@marzhillstudios.com

[Anton Dyudin]

Passing the request body through as text and letting purely the hook deal
with it is a simpler option, yeah

Post by Jeremy Wall

Post by Anton Dyudin

Post by Jeremy Wall

Post by Anton Dyudin
As an aside, in ford-ren %boil has been changed to accept an explicit
`coin` argument instead of a "virtual path"; this does not significantly
change any of the questions, which are already in those terms.
The coin format makes sense for (eventual) ford scry: I believe the
planned format is .^(%fr /=desk=/[~(rend co args)]/[desk]/{path}). The
decoding /from/ coin has to

I do not know what ford scry is for. Right now it appears to be nothing?
What is it's purpose and how/why does it impact this?

Wait oops, .^(%fr /=desk=/[~(rend co args)]/[*mark*]/{path})
Right now it is unimplemented; the eventual plan is to be able to request
e.g. /fr/~zod/home/11/~/html/web/foo, where foo.md is a wile in ~zod's
/web, as data from hoon.

Post by Jeremy Wall

Post by Anton Dyudin
happen in the hook, but could contain arbitrary logic: I can imagine a
fuel-png, for example, that expects an image atom along with the eyre query
string / auth info / etc.

So if I'm following you eyre needs to do the decode body -> encode to
coin part?

Eyre needs to do the query string -> coin part, and the client needs to
decode the aggregate result. The decoding and re-encoding should happen in
the marks, since there isn't a closed number of cases; but at some point
the coin-encoded post data and eyre metadata need to be consed together.

This aligns with my own suspicions then. the payload then would look
something like a coin encoded [p=mark q=tape] that is then consed together
with the rest of the eyre metadata.
Then the hook can call the appropriate fuel-<mark> gate to decode the
expected result.

Post by Anton Dyudin

Post by Jeremy Wall

Post by Anton Dyudin
The latter, in turn, have to at least be consed by eyre onto whatever
the post body is translated to; though I suppose the translation part could
be moved to mar/mime++grow++coin. But I think the correct answer, for both
this and app webhooks that might care about headers, is something in
mar/httr that produces a (pair target-mark ,source-cask=[%mime mime]),
which is then further converted to the target mark.
In the stateless post case, this can be further cast to %coin and
consed with the auth data; via a gate stuck in a silk by eyre, so in a
sense involving both.

Are you suggesting that eyre provide a gate to decode the coin to
correct format here? Or am I misunderstanding?
Zuse needs to provide the gate, or it could be in a library. Though it

doesn't strictly have to be "decoding" per se: post-`factor`, the coins are
executed as hoon, so the decode gate could be as simple as |=([bem=beam
png=my-custom-type eyre-data=*] png)
I should note that my thoughts have not yet considered that app webook

Post by Jeremy Wall
case by which I assume you mean the poke-<mark> arms on a %gall app. Those
seem "okay" for now the way they are if a bit clumsy. But the clumsiness is
more caused by what the %gall machinery requires than the %eyre api. I've
really only considered the stateless hook case here.

That is indeed what the webhooks do; they are not directly relevant to
the question here, except in that they would also benefit from the
httr->cay=cage->/mar/[p.cay]++grow++coin flow.

Post by Jeremy Wall

Post by Anton Dyudin

Post by Jeremy Wall
http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post
opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
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
For more options, visit https://groups.google.com/d/optout.

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com

[Jeremy Wall]

After the massive refactor I am now pretty lost. I can't tell how %eyre or
%ford use the code in /ren to render page.

Is there an overview anywhere or some pointers for where to start looking
in the code for how that gets handled?

Post by Anton Dyudin
Passing the request body through as text and letting purely the hook deal
with it is a simpler option, yeah

Post by Jeremy Wall

Post by Anton Dyudin

Post by Jeremy Wall

Post by Anton Dyudin
As an aside, in ford-ren %boil has been changed to accept an explicit
`coin` argument instead of a "virtual path"; this does not significantly
change any of the questions, which are already in those terms.
The coin format makes sense for (eventual) ford scry: I believe the
planned format is .^(%fr /=desk=/[~(rend co args)]/[desk]/{path}). The
decoding /from/ coin has to

I do not know what ford scry is for. Right now it appears to be
nothing? What is it's purpose and how/why does it impact this?

Wait oops, .^(%fr /=desk=/[~(rend co args)]/[*mark*]/{path})
Right now it is unimplemented; the eventual plan is to be able to
request e.g. /fr/~zod/home/11/~/html/web/foo, where foo.md is a wile in
~zod's /web, as data from hoon.

Post by Jeremy Wall

Post by Anton Dyudin
happen in the hook, but could contain arbitrary logic: I can imagine a
fuel-png, for example, that expects an image atom along with the eyre query
string / auth info / etc.

So if I'm following you eyre needs to do the decode body -> encode to
coin part?

Eyre needs to do the query string -> coin part, and the client needs to
decode the aggregate result. The decoding and re-encoding should happen in
the marks, since there isn't a closed number of cases; but at some point
the coin-encoded post data and eyre metadata need to be consed together.

This aligns with my own suspicions then. the payload then would look
something like a coin encoded [p=mark q=tape] that is then consed together
with the rest of the eyre metadata.
Then the hook can call the appropriate fuel-<mark> gate to decode the
expected result.

Post by Anton Dyudin

Post by Jeremy Wall

Post by Anton Dyudin
The latter, in turn, have to at least be consed by eyre onto whatever
the post body is translated to; though I suppose the translation part could
be moved to mar/mime++grow++coin. But I think the correct answer, for both
this and app webhooks that might care about headers, is something in
mar/httr that produces a (pair target-mark ,source-cask=[%mime mime]),
which is then further converted to the target mark.
In the stateless post case, this can be further cast to %coin and
consed with the auth data; via a gate stuck in a silk by eyre, so in a
sense involving both.

Are you suggesting that eyre provide a gate to decode the coin to
correct format here? Or am I misunderstanding?
Zuse needs to provide the gate, or it could be in a library. Though it

doesn't strictly have to be "decoding" per se: post-`factor`, the coins are
executed as hoon, so the decode gate could be as simple as |=([bem=beam
png=my-custom-type eyre-data=*] png)
I should note that my thoughts have not yet considered that app webook

Post by Jeremy Wall
case by which I assume you mean the poke-<mark> arms on a %gall app. Those
seem "okay" for now the way they are if a bit clumsy. But the clumsiness is
more caused by what the %gall machinery requires than the %eyre api. I've
really only considered the stateless hook case here.

That is indeed what the webhooks do; they are not directly relevant to
the question here, except in that they would also benefit from the
httr->cay=cage->/mar/[p.cay]++grow++coin flow.

Post by Jeremy Wall

Post by Anton Dyudin

Post by Jeremy Wall
http://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/proposals/marked-post
opinions on those open questions at the bottom of that small (for the
moment) document are greatly appreciated.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
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,
For more options, visit https://groups.google.com/d/optout.

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com

--
Cabmold delenda est

--
Jeremy Wall
http://jeremy.marzhillstudios.com
***@marzhillstudios.com